1445207 - value of date input control not populated until after control has lost focus

Status: RESOLVED FIXED

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

Description

[Chris Barnes]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20180208173149

Steps to reproduce:

<input type='date' onkeyup="console.log('value=' + this.value)">


Actual results:

Nothing shows up for "value" in the console log until the control has lost and then regained focus. Even when the date is fully entered and is valid


Expected results:

The value of the control should be visible in the console log

Comment 1

[Justin [:JW_SoftvisionQA]]

could you please provide a test case for this?

Comment 2

[Chris Barnes]

(In reply to Justin [:JW_SoftvisionQA] from comment #1)
> could you please provide a test case for this?

1) Write an HTML5 page which contains: 

<input type='date' onkeyup="console.log('value=' + this.value)">

2) Open Firefox and press F12 then switch to console view
3) Open the page 
4) Start typing into the control, watching the console log as you do so

Notice that the value of the control does not show up in the console log until you click somewhere else on the page, click back on the control and press any key

I'm not sure how to strip it down any further for you ?

Thank you !

Comment 3

[Andrew Overholt [:overholt]]

I can confirm (data:text/html,<input type='date' onkeyup="console.log('value=' + this.value)">) but I don't get anything in Chrome until I type in a correctly-formatted date, either. Is this working differently elsewhere?

Comment 4

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

If this is about the intermediate state when the element doesn't yet have the whole date, the spec says:

https://html.spec.whatwg.org/multipage/input.html#date-state-(type=date)
"The value sanitization algorithm is as follows: If the value of the element is not a valid date string, then set it to the empty string instead."

Comment 5

[Chris Barnes]

(In reply to Olli Pettay [:smaug] (only webcomponents and event handling reviews, please) from comment #4)
> If this is about the intermediate state when the element doesn't yet have
> the whole date, the spec says:
> 
> https://html.spec.whatwg.org/multipage/input.html#date-state-(type=date)
> "The value sanitization algorithm is as follows: If the value of the element
> is not a valid date string, then set it to the empty string instead."

I did wonder about that part of the spec, but as per my report, this bug happens even when there is a fully formed and valid date in the control.

Comment 6

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

oh, I can now reproduce after all.

Comment 7

[Chris Barnes]

(In reply to Olli Pettay [:smaug] (only webcomponents and event handling reviews, please) from comment #6)
> oh, I can now reproduce after all.

Glad I'm not going nuts ! 

As an aside and a deeper question to the W3C spec, I have to say that whilst I can understand the thinking behind the sanitization which means that a date input control has no value except when valid, surely this is a departure from the existing paradigm for input controls ?  Maybe the spec needs a "rawValue" property for the date control ? (Seems like a hack....) hmmm

Comment 8

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

Attachment: date_time_change.diff

elem.blur(); change in tests is just to test .value handling while the element still has focus.
The code change is 3 lines in datetimebox.xml

remote: View your change here:
remote:   https://hg.mozilla.org/try/rev/d8680c7b39217088a6043889f9141ad3308329e1
remote: 
remote: Follow the progress of your build on Treeherder:
remote:   https://treeherder.mozilla.org/#/jobs?repo=try&revision=d8680c7b39217088a6043889f9141ad3308329e1
remote: recorded changegroup in replication log in 0.086s

Comment 9

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8961574 [details] [diff] [review]
date_time_change.diff

Review of attachment 8961574 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks!

::: dom/html/test/forms/test_input_date_key_events.html
@@ +195,5 @@
>      initialVal: "2016-01-01",
>      expectedVal: "2016-01-01"
>    },
> +  {
> +    // Incomplete value maps to empty .value.

Wouldn't hurt to add a partially complete date too, like 201801 or something.

::: dom/html/test/forms/test_input_datetime_input_change_events.html
@@ +67,5 @@
>      is(changeEvents[i], 1, "Change event should be dispatched (1).");
>      is(inputEvents[i], 1, "Input event should ne dispatched (1).");
>  
>      // Test that change and input events are fired when changing the value with
>      // the keyboard.

Can you add a comment here saying we expect one event per character in the string?

Comment 10

[Chris Barnes]

(In reply to Mike Conley (:mconley) (:⚙️) (Totally backlogged on reviews and needinfos) from comment #9)
> Comment on attachment 8961574 [details] [diff] [review]
> date_time_change.diff
> 
> Review of attachment 8961574 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Thanks!
> 
> ::: dom/html/test/forms/test_input_date_key_events.html
> @@ +195,5 @@
> >      initialVal: "2016-01-01",
> >      expectedVal: "2016-01-01"
> >    },
> > +  {
> > +    // Incomplete value maps to empty .value.
> 
> Wouldn't hurt to add a partially complete date too, like 201801 or something.
> 
> ::: dom/html/test/forms/test_input_datetime_input_change_events.html
> @@ +67,5 @@
> >      is(changeEvents[i], 1, "Change event should be dispatched (1).");
> >      is(inputEvents[i], 1, "Input event should ne dispatched (1).");
> >  
> >      // Test that change and input events are fired when changing the value with
> >      // the keyboard.
> 
> Can you add a comment here saying we expect one event per character in the
> string?

Liking the partially complete idea. But will that send you guys down a different fork than the W3C spec and webkit etc ?

Comment 11

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

(In reply to Mike Conley (:mconley) (:⚙️) (Totally backlogged on reviews and needinfos) from comment #9)

> > +  {
> > +    // Incomplete value maps to empty .value.
> 
> Wouldn't hurt to add a partially complete date too, like 201801 or something.
1111 is a partially complete date, no?


> 
> Liking the partially complete idea. But will that send you guys down a
> different fork than the W3C spec and webkit etc ?
What you mean with this?
You get .value == "" as long as the date isn't valid.

Comment 12

[Mike Conley (:mconley) (:⚙️)]

(In reply to Olli Pettay [:smaug] (only webcomponents and event handling reviews, please) from comment #11)
> > Wouldn't hurt to add a partially complete date too, like 201801 or something.
> 1111 is a partially complete date, no?
> 

Ha, yes it is! Whoops.

Comment 13

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

Attachment: date_time_change_2.diff

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/342633799d08
populate input type=date's .value when changing the value in the UI, r=mconley

Comment 15

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/342633799d08