Implement UI for <input type="datetime-local">
Categories
(Core :: Layout: Form Controls, enhancement, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox93 | --- | fixed |
People
(Reporter: scottwu, Assigned: striptm, Mentored)
References
(Blocks 2 open bugs)
Details
(Keywords: dev-doc-complete)
Attachments
(5 files, 1 obsolete file)
No description provided.
|
||
Updated•8 years ago
|
|
|
||
Updated•8 years ago
|
|
||
Updated•7 years ago
|
|
|
||
Updated•7 years ago
|
|
||
Updated•5 years ago
|
| Comment hidden (spam) |
|
||
Comment 2•4 years ago
|
||
In order to do this, we need to tweak this condition so that you create the widget, then you need to change this code to handle datetime-local in the picker, by maybe combining the two or what not.
If someone is interested on taking this I'm happy to mentor and help with debugging and so on.
|
Assignee | |
Comment 3•3 years ago
|
||
|
||
Updated•3 years ago
|
|
|
Assignee | |
Comment 4•3 years ago
|
||
Depends on D100521
|
|
Assignee | |
Updated•3 years ago
|
|
|
Assignee | |
Comment 5•3 years ago
|
||
My proposal now would be to refactor toolkit/content/widgets/datetimebox.js
removing the classes DateInputImplWidget and TimeInputImplWidget and add logic to render date/time/datetime-local in DateTimeLocalInputImplWidget
|
|
||
Updated•3 years ago
|
|
|
Assignee | |
Comment 6•3 years ago
|
||
Depends on D100522
|
|
Assignee | |
Comment 7•3 years ago
|
||
Depends on D105959
|
|
Assignee | |
Comment 8•3 years ago
|
||
Depends on D110979
|
|
||
Comment 9•3 years ago
|
||
Hi fer, sorry for the lag getting to this. This looks great, though some things:
- The picker looks broken at least on Linux.
- Your changes seem to cause
toolkit/content/tests/browser/browser_datetime_datepicker.jsto fail one of the tests. You can run this with./mach mochitest toolkit/content/tests/browser/browser_datetime_datepicker.js.
This looks on the good track anyways. I've opened bug 1705946 to start landing your changes, and I'll try to look into the test failure and land the datetimebox.js refactoring next (though if you can dig into the test failure that'd be great as well of course).
|
|
||
Comment 10•3 years ago
|
||
Needs tests. This only shows the date picker for now (matches Safari).
Seems fine since we don't enable the time picker by default.
|
|
||
Updated•3 years ago
|
|
||
Updated•3 years ago
|
|
|
||
Updated•3 years ago
|
|
|
||
Updated•3 years ago
|
|
|
||
Updated•3 years ago
|
|
||
Comment 12•3 years ago
|
||
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/8aef29efdec2 Implement datetime-local UI. r=Gijs
|
|
||
Comment 13•3 years ago
|
||
Backout by abutkovits@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/6f71100cb98a Backed out changeset 8aef29efdec2 for causing failures in test_MozEditableElement_setUserInput.html. CLOSED TREE
|
|
||
Comment 14•3 years ago
|
||
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/6e763489ab1e Implement datetime-local UI. r=Gijs
|
|
||
Comment 15•3 years ago
|
||
Pushed by emilio@crisal.io: https://hg.mozilla.org/integration/autoland/rev/cb39252d466b Remove a bit from a reftest which doesn't apply to date/time/datetime-local inputs.
|
||
Comment 16•3 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/6e763489ab1e
https://hg.mozilla.org/mozilla-central/rev/cb39252d466b
|
||
Comment 17•3 years ago
|
||
Can this bug be reopened?
The current implementation as tested from Nightly (93.0a1) only permits picking a date, leaving the time as "--:--:--" and
This is not compliant with the specification:
- https://www.w3.org/wiki/Html/Elements/input/datetime-local
- https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/datetime-local
A partial implementation confuses attempts to polyfill a functioning datetime picker.
|
|
||
Comment 18•3 years ago
•
|
||
(In reply to TWC (Alt Email) from comment #17)
The current implementation as tested from Nightly (93.0a1) only permits picking a date, leaving the time as "--:--:--"
That matches Safari (and we don't ship a time picker for <input type=time> so it is consistent with that too).
This is not compliant with the specification:
Why? Neither of those links is a specification. The specification is this and it doesn't specify how the UI should look like, afaict.
Can this bug be reopened?
I filed bug 1726108 for this. Reopening this fixed bug would make tracking a mess.
|
|
||
Updated•3 years ago
|
|
||
Updated•3 years ago
|
Description
•