Closed Bug 1445207 Opened 3 years ago Closed 2 years ago

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

Categories

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

58 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla61
Tracking Status
firefox61 --- fixed

People

(Reporter: chris, Assigned: smaug)

References

Details

Attachments

(2 files)

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
could you please provide a test case for this?
Component: Untriaged → DOM
Flags: needinfo?(chris)
Product: Firefox → Core
(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 !
Flags: needinfo?(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?
Flags: needinfo?(overholt)
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."
(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.
oh, I can now reproduce after all.
(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
Assignee: nobody → bugs
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
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
Attachment #8961574 - Flags: review?(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?
Attachment #8961574 - Flags: review?(mconley) → review+
(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 ?
Flags: needinfo?(chris)
(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.
(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.
Pushed by opettay@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/342633799d08
populate input type=date's .value when changing the value in the UI, r=mconley
https://hg.mozilla.org/mozilla-central/rev/342633799d08
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
QA Whiteboard: [good first verify]
Duplicate of this bug: 1420126
Component: DOM → DOM: Core & HTML
Regressions: 1567493
You need to log in before you can comment on or make changes to this bug.