[Webkit-unassigned] [Bug 40908] unable to set focus to non-displayed elements with "required" attribute on submit

Sun Jun 27 11:04:52 PDT 2010

https://bugs.webkit.org/show_bug.cgi?id=40908

--- Comment #6 from Aryeh Gregor <Simetrical+webkit at gmail.com>  2010-06-27 11:04:51 PST ---
Failure shouldn't be silent -- that's bug 40747.  With proper UI, I don't think you'd have seen so many complaints to WebKit.  It should fail with a clear error.  The error should give enough info for the user to figure out how to fix it if that makes sense, otherwise it should report a page error and give enough info for the author to fix it.  I'm far from being a UI person, but maybe something like:

1) If the current value was actually set by the user (not the default value or a script): Report the same error as usual.  Since the user set the value in the first place, they can probably figure out how to change it -- maybe it's a set of controls that got collapsed.  At worst, they can refresh.  So for <label>Volume: <input type=number step=1 min=1 max=10></label>, maybe like "You entered '11' for 'Volume:', but it must be between 1 and 10."  (This shouldn't come up much if the error is reported onchange, which seems best anyway.)

2) If the current value is default, or was set by a script: Let's say <input required name="foo" style="display:none">.  Then report something like "The page has an error and won't let you submit.  Tell the author that the input 'foo' is required, but cannot be displayed."

This is not ideal, but then, the page is buggy, and ignoring the requirements if the input's not visible isn't sane.  In this test case, Opera fails silently:

data:text/html,<!doctype html>
<form action=about:blank>
<input required name=foo style=display:none>
<button type=submit>Submit</button>
</form>

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.