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

Status: RESOLVED FIXED

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

Description

[arni2033]

Attachment: screenshot - -moz-ui-invalid should apply to input[type='number'] as soon as the user tries to submit the form.png

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

Comment 1

[Jonathan Watt [: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>

Comment 2

[arni2033]

(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.

Comment 3

[Boris Zbarsky [:bzbarsky]]

> 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...

Comment 4

[arni2033]

> (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.

Comment 5

[arni2033]

Sorry for bug spam, but in case of <input required/> I think the best option is to validate onfocus

Comment 6

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 7

[Jonathan Watt [:jwatt]]

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.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Attachment: Fix incorrect "is this control focused?" checks in form code

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.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: Fix incorrect "is this control focused?" checks in form code

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.

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

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.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/9451d5fcfaa4
Fix incorrect "is this control focused?" checks in form code.  r=smaug

Comment 12

[Boris Zbarsky [:bzbarsky]]

Right, but how do I then check for the red outline?  I guess I could WindowSnapshot or something...

Comment 13

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/9451d5fcfaa4