Closed Bug 1209035 Opened 4 years ago Closed 2 years ago

:-moz-ui-invalid should apply to <input type="number"> as soon as the user tries to submit the form

Categories

(Core :: DOM: Core & HTML, defect, P4, minor)

defect

Tracking

()

RESOLVED FIXED
mozilla63
Tracking Status
firefox63 --- fixed

People

(Reporter: arni2033, Assigned: bzbarsky)

References

()

Details

Attachments

(2 files, 1 obsolete file)

STR:   (Win7_64, Nightly 44, 32bit, ID 20150926030216, new profile, safe mode)
1. Open the following "data:" url or click URL in the form above
>   data:text/html,<form><input autofocus required type="number"></form>
2. Press Enter to submit the form

Result:       :-moz-ui-invalid wasn't applied so element doesn't get red box-shadow
Expectations: :-moz-ui-invalid should be applied to <input type="number">s when user submits the form
Flags: needinfo?(jwatt)
Interestingly --moz-ui-invalid does apply immediately if the user submits using a submit button rather than hitting Enter in the number control.

data:text/html,<form><input autofocus required type="number"><input type=submit></form>
(In reply to Jonathan Watt [:jwatt] from comment #1)
> --moz-ui-invalid does apply immediately if the user submits using a submit button
I believe that's because :-moz-ui-invalid applies to invalid <input type="number">s when they lose focus: (1) Open my example, type "a" in input   (2) Press Tab to change focus

So now I see 2 issues (inconsistencies) here:
1) [this bug] <input number/> doesn't highlight with red unless it lost focus before, at least once
              Test my original example again and submit "a"   ->   :-moz-ui-invalid doesn't apply
2) <input required/> doesn't become invalid when it looses focus, if it's empty

Please tell if I should/shouldn't report issue (2) in separate bug.
> 2) <input required/> doesn't become invalid when it looses focus, if it's empty

It becomes invalid; what makes you think it doesn't?

It's not _drawn_ as invalid, unless it used to be nonempty before.  If it used to be empty and is still empty, it doesn't enter the ui-invalid state.  That seems to be expected, since the ui-invalid pseudoclass only applies to controls that have had their value modified or are in a form that attempted to submit.  Otherwise simply loading a form with validation requirements would flag every single thing as invalid...
> (In reply to Boris Zbarsky [:bz] from comment #3)
Yes, I meant ui-invalid isn't applied in that case (2).
Well, if it's "by design", I won't report this ofc. But I still find this design incomplete. If user switches between form controls with Tab key, it's always good to let him know that last control he interacted (which just lost focus) has invalid value.

This is just thinking aloud, not a "demand". But it won't flag every control as invalid on page load.
Sorry for bug spam, but in case of <input required/> I think the best option is to validate onfocus
> it's always good to let him know that last control he interacted (which just lost focus)
> has invalid value

Only if the user changed the value.  Otherwise tabbing through the form will have weird side effects that really confuse users.
Has STR: --- → yes
Seems like only the original bug reported in comment 0 is valid, and that that issue is fairly minor given that a little popup with the message "Please enter a number" is displayed.
Flags: needinfo?(jwatt)
Priority: -- → P4
For number controls, nsContentUtils::IsFocusedContent doesn't really do the
right thing, because the thing it thinks is focused is the anonymous text
element inside the number control.  As a result, we weren't properly updating
the state of the currently-focused number control when hitting enter in it to
submit the form.

The HTMLFormElement change is enough on its own to fix the bug.  The constraint
validation change is a just-in-case.

I haven't figured out a sane way to write a reftest for this, unfortunately:
the enter key press needs to look like a real user event to trigger the
submission behavior.
Attachment #8987674 - Flags: review?(bugs)
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
For number controls, nsContentUtils::IsFocusedContent doesn't really do the
right thing, because the thing it thinks is focused is the anonymous text
element inside the number control.  As a result, we weren't properly updating
the state of the currently-focused number control when hitting enter in it to
submit the form.

The HTMLFormElement change is enough on its own to fix the bug.  The constraint
validation change is a just-in-case.

I haven't figured out a sane way to write a reftest for this, unfortunately:
the enter key press needs to look like a real user event to trigger the
submission behavior.
Attachment #8987675 - Flags: review?(bugs)
Attachment #8987674 - Attachment is obsolete: true
Attachment #8987674 - Flags: review?(bugs)
Comment on attachment 8987675 [details] [diff] [review]
Fix incorrect "is this control focused?" checks in form code

I wouldn't use reftest for this but mochitest.
Attachment #8987675 - Flags: review?(bugs) → review+
Pushed by bzbarsky@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/9451d5fcfaa4
Fix incorrect "is this control focused?" checks in form code.  r=smaug
Right, but how do I then check for the red outline?  I guess I could WindowSnapshot or something...
https://hg.mozilla.org/mozilla-central/rev/9451d5fcfaa4
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
You need to log in before you can comment on or make changes to this bug.