Closed
Bug 1445207
Opened 7 years ago
Closed 7 years ago
value of date input control not populated until after control has lost focus
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
FIXED
mozilla61
Tracking | Status | |
---|---|---|
firefox61 | --- | fixed |
People
(Reporter: chris, Assigned: smaug)
References
Details
Attachments
(2 files)
(deleted),
patch
|
mconley
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
Details | Diff | Splinter Review |
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•7 years ago
|
||
could you please provide a test case for this?
Component: Untriaged → DOM
Flags: needinfo?(chris)
Product: Firefox → Core
Reporter | ||
Comment 2•7 years ago
|
||
(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)
Comment 3•7 years ago
|
||
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)
Assignee | ||
Comment 4•7 years ago
|
||
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."
Reporter | ||
Comment 5•7 years ago
|
||
(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.
Assignee | ||
Comment 6•7 years ago
|
||
oh, I can now reproduce after all.
Reporter | ||
Comment 7•7 years ago
|
||
(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 | ||
Updated•7 years ago
|
Assignee: nobody → bugs
Assignee | ||
Updated•7 years ago
|
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Assignee | ||
Comment 8•7 years ago
|
||
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 9•7 years ago
|
||
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+
Reporter | ||
Comment 10•7 years ago
|
||
(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)
Assignee | ||
Comment 11•7 years ago
|
||
(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•7 years ago
|
||
(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.
Assignee | ||
Comment 13•7 years ago
|
||
Comment 14•7 years ago
|
||
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
Comment 15•7 years ago
|
||
bugherder |
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
status-firefox61:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
Updated•6 years ago
|
QA Whiteboard: [good first verify]
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•