I am trying to get the validation to work correctly in Firefox. It works fine in Chrome and Safari. In the simplest example in pure HTML, everything looks ok until I click the submit button a second time without leaving the input data.
<form onsubmit="javascript:return false;">
<input type="text" name="name" pattern=".{5,20}" required />
<button type="submit">Submit</button>
</form>
How to reproduce this (in Firefox):
Please click the submit button, and see that the validation shows up correctly. Please then click anywhere on the page (body or input, but not the button), and then click the submit button again to see the validation still shows correctly.
If you click the button again once the validation is showing it stopps working and never back until the page is refreshed.
I am looking for some workaround for this situation so that I am not leaving the user with the inability to submit the form without giving error message.
I tried calling reportValidity() but it also stops working at this point.
The properties input.validity and input.validationMessage have the correct values, but the error does not show.
I would appreciate any hints. Thanks.
Related
NOT a duplicate of HTML Form Button value is not posted in Safari and Chrome
I have a button that is used to submit a form when it is clicked.
<form method="post" action="<URL>" class="login_form" name="login_form" id"login_form">
... various inputs here ...
<button type="submit" name="signIn" class="cta">
<span class="arrow">Enter</span>
</button>
</form>
The button name is used server-side to determine what action is to be taken (value is not provided because it is not used by the server).
The problem is that sometimes the name is not posted to the server, while sometimes it is. The ratio is about 1miss/6hits.
Many other forms on my website have the same structure, but I found this behaviour only for this one.
It seems to happen only with Chrome.
I tried clicking the button right after the page is loaded and after having waited quite some time after the page is fully loaded. so it seems not to be tied to the rest of the page.
Is this a known bug or could this be caused by something else?
I encountered a similar issue and in my case it was due to a JavaScript that on Form-Submit disabled the Submit-Button (the intention of that is to prevent duplicate POSTs when users double-click).
Disabled form elements are not included in the formdata.
A better way to "disable" it for the intent of preventing double-clicks thus may be setting pointer-events: none or preventing the surplus submits in JS (preventDefault).
It may also explain that it worked "sometimes", as I imagine there is room for a race between gathering the formdata and the button becoming disabled.
In my experience, this kind of error occurs when there is a problem with the coding of the form itself, or some related javascript error. The fact that you have tracked this to a 1 per 6 chance of happening supports this reasoning. What I would suggest is to view your console output, turn on persistent logging, then submit your forms and test. If this is indeed the problem, there will be some sort of error message printed on the console, and you will be able to solve the problem from there.
I have a simple form. It contains an input of type "FILE" and a submit button. It is undergoing 508 compliance testing, and they have a problem.
If you tab to the FILE input and press the enter key, IE submits the form. It is my understanding that this is the correct behavior. I'm not doing any Javascript or anything to intentionally change the behavior of the keypress.
Our 508 testers disagree, and think that pressing enter in the FILE input should open the browse dialog. I haven't found anything conclusive, but I was hoping someone could clarify for me. Sample of the form is below.
<form id="upload_Form" METHOD="POST" ENCTYPE="multipart/form-data" action="" NAME="uploadForm">
<INPUT TYPE="FILE" NAME="filenames" id="filenames" title="Select File for Upload">
<input type="submit" value="Upload"/>
</form>
Actually, it's the matter of consensus. I personally think that using the enter key instead of space to trigger a browse dialog is a correct behavior in terms of accessibility — more intuitive for a regular user, let's say.
That's why WebKit is doing that, instead of submitting the form, when the upload input is focused.
A simple jQuery workaround as a fix for IE:
$(document).keypress(
function(event){
if (event.which == '13') {
event.preventDefault();
$('#upload-form').click();
}
});
Demo Fiddle
In the <input type="file"/> element, in modern browsers the focus goes to the button that invokes the file selection dialog. Hitting enter in that instance should invoke the dialog instead of submitting the form. IE, of course, does things their own way. I would be inclined to conform IE to standards rather than the other way around.
But more the point, why would you ever deliberately submit the form if that field hasn't been filled? It's a validation error at best.
I use this to detect enter:
<input type="submit" name=hiddenbutton value=enter style="display: none">
When this is placed before all other form elements, then I get the appropriate $_REQUEST[hiddenbutton]when enter was used to submit the form.
Except with Chrome and other Webkit-based browsers, which don't activate the first button when enter is pressed.
Is there a way to make it work on all browsers? (preferably with as little JavaScript as possible)
I would recomend adding a focus listener to make sure the user is not justdoing something completely different like typing in a word document, because some browsers will detect key clicks without focus
I am trying to build a simple login form in a chrome extension. In my popup.html, I have a few input fields that have their corresponding tabindex values set. The username field has the autofocus property set through HTML or $('#myelement').focus() (I've tried both methods).
For some reason, tabbing does not work on my form when I first click the button next to the omnibar to open the popup. The username field has focus, but pressing the tab key makes the cursor disappear. It only shows up again if I explicitly click one of the input fields and then tab over, but never when they popup first opens.
<input type="text" id="one" tabindex=1 autofocus />
<input type="text" id="two" tabindex=2 />
If I open popup.html in a web browser (and not the extension), I've noticed that the tabbing in my form works perfectly.
This is a regression, which has a bug filed here. Unfortunately it has been around for quite some time now, and there doesn't seem any progress on it.
There is no known scriptable workaround for this bug.
When I submit a form, I can see my browser's progress bar slowly increased, it takes 4-6s to submit a form.
It was a generic form like :
<form id="someid" name="someName" action="someAction.do">
...
</form>
I test it in IE8 and Firefox 3,both are very slow.
My network condition is fine, my server works great.
What could be the problem?
Your server-side code is slow.