Open Bug 888320 (datetime) Opened 11 years ago Updated 1 years ago

[meta] implement all time and date related input types

Categories

(Core :: DOM: Core & HTML, enhancement, P2)

Product:
Core
Component:
DOM: Core & HTML
Type:
enhancement

Tracking

()

People

(Reporter: rexyrexy2, Unassigned)

References

(Depends on 12 open bugs)

Details

(8 keywords, Whiteboard: [DevRel:P1])

This bug is for use as a tracker for the overall progress on the implementation of all date and time related inputs (week, month, etc).
Depends on: 888316
Depends on: 825294
Depends on: 777279, 769352
Depends on: 888324
Depends on: 888328
Depends on: 888331
Depends on: 446510
Keywords: html5, inputmethod
Component: Developer Tools → DOM
Product: Firefox → Core
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: meta, relnote
OS: Windows 7 → All
Hardware: x86_64 → All
Summary: implement all time and date related input types → [meta] implement all time and date related input types
Version: 23 Branch → Trunk
Keywords: feature
This blocks the bug 802882. Sebastian
Blocks: html5test
No longer depends on: 888316, 888324, 888328, 888331
Blocks: 1005268
Depends on: 888316
Depends on: 888324
Depends on: 888328
Depends on: 888331
Bug 805049 may help for implementation.
Depends on: 805049
What's the latest on this implemented?
Whiteboard: [parity-edge]
Hey Jessica, since you are working on it, I assign this to you. Let me know if you need any help.
Assignee: nobody → jjong
Hello, Is someone really working on this ? It's been so long I'd lost all hope this would be fixed one day. Thanks a lot!
@choarau: Please read the last comment just before you added your comment. Thank you.
Whiteboard: [parity-edge] → [parity-edge][DevRel:P1]
(In reply to choarau from comment #11) > Hello, > > Is someone really working on this ? It's been so long I'd lost all hope this > would be fixed one day. > > Thanks a lot! Yes, the team is actively moving this feature forward. Current status: UX folks are working on the UI spec for this feature. Jessica (the assignee) is studying the platform work. This feature requires front-end developers' help in xul/html element and we are working with program managers to work out the front-end resource issue.
Hi Gijs, There was a decision made to implement a new picker in HTML inside a XUL panel, anchored on the <input> element on the content web page. I was asked by Hsin-Yi and Jessica on the feasibility of this approach, since there isn't any previous examples (at least isn't any I could find; all XUL panels anchors on the chrome UI). Would you be able to answer this question? Preferably maybe point us to the future reviewer of the patch as well. Thanks!
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #14) > Hi Gijs, > > There was a decision made to implement a new picker in HTML inside a XUL > panel, anchored on the <input> element on the content web page. I was asked > by Hsin-Yi and Jessica on the feasibility of this approach, since there > isn't any previous examples (at least isn't any I could find; all XUL panels > anchors on the chrome UI). Would you be able to answer this question? You can't display XUL panels in the content process. This is also why e.g. <select> dropdowns are implemented in the parent process. The anchoring itself shouldn't be tooooo much of a problem - e.g. form validation and <select> dropdowns (in e10s) are XUL and 'anchor' on items in HTML pages. It's not really clear to me why you'd want to use a XUL panel to contain the HTML. Why not just do it entirely in HTML in the content process? If we're going to do the XUL panel in the parent process and enable showing it using IPC, I'd be worried about making sure this works correctly in all <browser>s, not just in the one in Firefox's main <tabbrowser>. Then again, I don't know how that got solved for <select> dropdowns. > Preferably maybe point us to the future reviewer of the patch as well. Neil Deakin or Felipe Gomez. It'd probably be a good idea to discuss the approach with them - they'd know more about the current workings of <select> than I do. Diving into some of the dependencies of bug 1154677 can probably get you a lead on how it works. Finally, it seems prudent to do the actual guts of the implementation in a separate bug from this one.
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(timdream)
(In reply to :Gijs Kruitbosch from comment #15) > (In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment > #14) > You can't display XUL panels in the content process. This is also why e.g. > <select> dropdowns are implemented in the parent process. > > The anchoring itself shouldn't be tooooo much of a problem - e.g. form > validation and <select> dropdowns (in e10s) are XUL and 'anchor' on items in > HTML pages. > > It's not really clear to me why you'd want to use a XUL panel to contain the > HTML. Why not just do it entirely in HTML in the content process? Do we have access to XUL panel styles, if this is entirely implemented in content process with HTML? If so that would be greeeeeat! (Noted that I am only being shown an UX proposal with a illustration of XUL Panel; the final spec might not be using that at all.) > If we're going to do the XUL panel in the parent process and enable showing > it using IPC, I'd be worried about making sure this works correctly in all > <browser>s, not just in the one in Firefox's main <tabbrowser>. Then again, > I don't know how that got solved for <select> dropdowns. If the answer to the previous question is an yes, we would not need to worry about IPC dance and how <select> solved that right? Bug 1154677 looks like a lot of work... > > Preferably maybe point us to the future reviewer of the patch as well. > > Neil Deakin or Felipe Gomez. It'd probably be a good idea to discuss the > approach with them - they'd know more about the current workings of <select> > than I do. Diving into some of the dependencies of bug 1154677 can probably > get you a lead on how it works. > > Finally, it seems prudent to do the actual guts of the implementation in a > separate bug from this one. Yes, definitely. There isn't any implementation bugs filed yet so I ended up having the conversation w/ you on this on. Better than e-mail inboxes :).
Flags: needinfo?(timdream) → needinfo?(gijskruitbosch+bugs)
(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #16) > (In reply to :Gijs Kruitbosch from comment #15) > > (In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment > > #14) > > You can't display XUL panels in the content process. This is also why e.g. > > <select> dropdowns are implemented in the parent process. > > > > The anchoring itself shouldn't be tooooo much of a problem - e.g. form > > validation and <select> dropdowns (in e10s) are XUL and 'anchor' on items in > > HTML pages. > > > > It's not really clear to me why you'd want to use a XUL panel to contain the > > HTML. Why not just do it entirely in HTML in the content process? > > Do we have access to XUL panel styles, if this is entirely implemented in > content process with HTML? If so that would be greeeeeat! Access in the sense that you could potentially use some of the stylesheets: yes. But if the style rules are specific to XUL panel elements I don't really know what that gets you... > > If we're going to do the XUL panel in the parent process and enable showing > > it using IPC, I'd be worried about making sure this works correctly in all > > <browser>s, not just in the one in Firefox's main <tabbrowser>. Then again, > > I don't know how that got solved for <select> dropdowns. > > If the answer to the previous question is an yes, we would not need to worry > about IPC dance and how <select> solved that right? Maybe. As I said earlier, you can't show XUL panels in the content process itself. The best you could do would be to have anonymous HTML content in the same document and use "regular" css to ensure it appears on top of the existing web content. I don't know what bugs that gets you... Generally, I'm a little confused because: (In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #14) > There was a decision made to implement a new picker in HTML inside a XUL > panel sounded like you had an implementation strategy, but the questions make it sound like you don't. If you don't, I am not the best person to adjudicate which implementation strategy makes sense - try either of the aforementioned folks, or maybe Mike Conley... :-)
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to :Gijs Kruitbosch from comment #17) > (In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment > #14) > > There was a decision made to implement a new picker in HTML inside a XUL > > panel > > sounded like you had an implementation strategy, but the questions make it > sound like you don't. If you don't, I am not the best person to adjudicate > which implementation strategy makes sense - try either of the aforementioned > folks, or maybe Mike Conley... :-) Oops. Sorry about the confusing sentence construction. We had a implementation proposal that needs validation: generally since it's a new UI we want to do it in HTML, *but* we don't know the best strategy for that chrome XHTML be anchored/embedded in the content document. Perhaps we are looking at two approaches now depend on the actual visual? 1. If the date UI to show should be appeared inside a XUL panel, do it via IPC and render the UI in chrome process. 2. If the date UI can be entirely done in HTML including the container, do it entirely in content process as anno content under <input>. (As I write this down, it reads to me like (1) could be the path with fewer bugs since all complexities are constrained inside IPC etc., but for (2) it's an uncharted territory in layout behavior ...)
Hi, Neil, Felipe, or Mike, Please read comment 14 to comment 18. We want to implement a date/time picker in xHTML and Jessica would like to know the right approach before start working. TL;DR is that we don't know if we are reaching the correct conclusion in comment 18, whether any of you can be the reviewer of such patch, and your preferred approach. Would you like to shed some light here? It would be great if there are some early feedback :) Thanks!
Flags: needinfo?(mconley)
Flags: needinfo?(felipc)
Flags: needinfo?(enndeakin)
Showing the UI in the child process sounds way harder approach than doing some IPC and showing a popup in the parent process (in the cases we want to show some popup). IPC approach is after all what is being done with <select size=1> and <input type=file> and <input type=color>.
We can have the contents of the popup implemented in HTML, but the actual popup showing functionality would be provided by XUL APIs, since HTML doesn't have a way to show such popups.
Olli, to me it looks like the different related issues got mixed up and it's unclear what's the scope of this and the blocking bugs. According to the [meta] keyword in the summary and the actual implementation is happening in other bugs (i.e. bug 825294 for desktop and bug 446510 for mobile [already fixed]). Obviously the discussion about XUL vs. HTML vs. native OS widgets should have happened in bug 825294, though was decided in favor of using *native widgets* in bug 825294 (and already started to implement). Now comment 14 says that it was decided to implement this in HTML instead (which I'd prefer btw.) According to comment 11 Hsin-Yi wrote that "UX folks are working on the UI spec for this feature.", though bug 1069609 is still unassigned. So, can you please clarify all this? Sebastian
Flags: needinfo?(bugs)
I've updated the assignee for bug 1069609.
sebo, as far as I know, it isn't clear yet what kind of UI will be used eventually. It depends on the UI we want to have and also on whether the platforms we run on provide good UI, or do we need to write it ourselves. Just normal iterative process what software engineering so often tends to be. The IPC bits from bug 825294 can be certainly used with whatever the UI will look like.
Flags: needinfo?(bugs)
I concur with smaug that having the content process send some kind of message to populate a panel in the parent process. Also going to echo that the contents of the popup can be HTML, though the popup container itself will have to be XUL for now. It might make sense to do this in a similar way to how we do <select> popups. Namely, that the platform DOM code, when it detects that the user wants to show the popup, sends a chrome-only event, which one of our framescripts can catch. When the framescript catches it, it uses its message manager to communicate to the parent window which will open and position the popup properly. When the popup is dismissed, the result is then messaged back down to the child. The SelectContentHelper.jsm and SelectParentHelper.jsm modules show us doing this with the mozshowdropdown event that we bolted onto the <select> dropdown stuff. I'm certain we could improve upon that implementation, however, so I wouldn't use it as a template. :)
Flags: needinfo?(mconley)
I think we'll want to have some more generic mechanism that given an element to anchor a popup to, opens a popup defined in the parent process and handles the lifetime management while open and sending responses back to the child process. We currently have the select popup and the invalid form popup that want to do this and I suspect we may others in the future (maybe addons).
Flags: needinfo?(enndeakin)
It's been mentioned briefly here, but I'd like to double mention to take a look too at <input type=color> to see how it works. It's not anchored to the element (although it should be imo), but it's an example to be based on. And as Gijs mentioned, the anchoring is probably the easier part. If you go through the JS route, there's functionality in BrowserUtils to convert coordinates from the content to absolute screen coordinates in the parent.
Flags: needinfo?(felipc)
We have similar setup to as what color have implemented already in bug 825294.
Well, the UI part there is native, I don't know what we use for color.
(In reply to Olli Pettay [:smaug] from comment #29) > Well, the UI part there is native, I don't know what we use for color. Seems that color uses native as well. Discussion was made in Bug 547004. Thanks for all the input and feedback. We do have a conclusion on using IPC and let parent render the popup, the popup can be HTML, but we can use XUL APIs to show the popup. Currently, input 'color' and 'file' are not anchored to the element, they are handled in HTMLInputElement. For 'select', it is described in comment 25. I think we'll move forward by doing something similar to 'select'. After having a draft, maybe we can consider how to have a more generic mechanism for this.
Depends on: 1069609
Flags: platform-rel?
platform-rel: --- → ?
Depends on: 1283381
I think the whiteboard should include `[parity-blink]` as Chrome on Desktop has support as well.
Whiteboard: [parity-edge][DevRel:P1] → [parity-edge][parity-chrome][DevRel:P1]
No longer depends on: 805049
No longer depends on: 1307384
is someone still working on date in puts like datetime-local? I would love to use it on my website someday in the future :)
(In reply to Djfe from comment #33) > is someone still working on date in puts like datetime-local? Yes, just follow the bugs that are blocking this meta-bug (you can find them in the "Depends on" section). The one related to <input type="dateime-local"> is bug 888331. The one that's currently being worked on is <input type="time">, see bug 1288591 and bug 1283384. Sebastian
(In reply to Sebastian Zartner [:sebo] from comment #34) > Yes, just follow the bugs that are blocking this meta-bug (you can find them > in the "Depends on" section). The one related to <input > type="dateime-local"> is bug 888331. The one that's currently being worked > on is <input type="time">, see bug 1288591 and bug 1283384. > > Sebastian Correct. To add some more info: The current plan is to enable time type and then date type. After these two are done, there will be clearer plan about what to work on next.
Depends on: 1310823
Depends on: 1310831
Depends on: 1332266
platform-rel: ? → ---
No longer depends on: 1310823
Depends on: 1348052
Depends on: 1366620
No longer depends on: 1366620
Depends on: 1370086
No longer depends on: 1370086
can i use js(`click()/focus()`) open picker?
Depends on: 1379571
(In reply to 709922234 from comment #37) > can i use js(`click()/focus()`) open picker? No, not for now. For now, we listen to click event in the inner text component and not in the input element itself. Maybe it'd be fixed with Bug 1371111.
Well, it isn't clear whether click() should show the popup. Does it show up in other browsers?
No longer depends on: 1379571
For those who are following this bug, I'd like to let you know that we're going to support input type="date" and type="time" in Firefox v57. The rest of the date/time input types, that is "month", "week" and "datetime-local", are backlogged for now. See the browser compat data here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#Browser_compatibility
Depends on: 1418061
Is it possible to finish this? The most difficult part should have been already done, shouldn't it? I'm deeply missing datetime-local, as it could greatly simplify datetime handling on the server-side. Thanks for your consideration!
Assignee: jessi3py → nobody
Depends on: 1446342
Wesley, what's the reason the types "month", "week", and "datetime-local" were backlogged? And is it already planned to pick up the work again? Like o-zilla, I assume there is at least a big need for "datetime-local". Sebastian
Flags: needinfo?(whuang)
(In reply to Sebastian Zartner [:sebo] from comment #43) > Wesley, what's the reason the types "month", "week", and "datetime-local" > were backlogged? And is it already planned to pick up the work again? Like > o-zilla, I assume there is at least a big need for "datetime-local". > > Sebastian The date and time types were considered as the higher priority ones when we got the dev resource to ship in Firefox57. The rest types were backlogged because of the limited resource/time at that time. I transitioned my focus to other project so I don't know the latest plan of this backlog. Maybe best for DOM or Product team to answer.
Flags: needinfo?(whuang)
(In reply to Wesley Huang [:wesley_huang] (EPM) (NI me) from comment #44) > (In reply to Sebastian Zartner [:sebo] from comment #43) > > Wesley, what's the reason the types "month", "week", and "datetime-local" > > were backlogged? And is it already planned to pick up the work again? Like > > o-zilla, I assume there is at least a big need for "datetime-local". > > > > Sebastian > The date and time types were considered as the higher priority ones when we > got the dev resource to ship in Firefox57. > The rest types were backlogged because of the limited resource/time at that > time. > I transitioned my focus to other project so I don't know the latest plan of > this backlog. Thank you for the info! > Maybe best for DOM or Product team to answer. Ok, so I redirect the question to Smaug, as being one of the DOM peers who is following this bug. Sebastian
Flags: needinfo?(bugs)
More a question to overholt. I do agree we definitely should support all the time/date types supported in other browsers too. Just right now we do not have the resources, I think, but hopefully we'll have rather soon. Good thing is that the implementation of time and date added all the infrastructure needed for other types too.
Flags: needinfo?(bugs) → needinfo?(overholt)
Just a lack of time. Patches welcome :)
Flags: needinfo?(overholt)
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-chrome, parity-edge
Whiteboard: [parity-edge][parity-chrome][DevRel:P1] → [DevRel:P1]
Priority: -- → P2
Depends on: 1498787
Depends on: 1502390
Depends on: 1532923
Component: DOM → DOM: Core & HTML
Type: defect → enhancement

There appears to be a bug in the current implementation (tried on 67.0, 67.0b12 and 68.0b5 on mac os 10.14.5). If firefox interface is set to portuguese the weekdays appear in full intead of abreviated. This breaks the layout making text overlap and scrollbars to appear. In 68b5 scrollbars are gone but weekdays are still not abreviated and overlap.
Screenshot: https://fimdomeio.com/p/bugzilla/date-input-firefox-68.0b5.png
Also tested in english, french and german and all appear to be ok, only portuguese is broken.

(In reply to Alexandre Castro from comment #51)

There appears to be a bug in the current implementation (tried on 67.0, 67.0b12 and 68.0b5 on mac os 10.14.5). If firefox interface is set to portuguese the weekdays appear in full intead of abreviated. This breaks the layout making text overlap and scrollbars to appear. In 68b5 scrollbars are gone but weekdays are still not abreviated and overlap.
Screenshot: https://fimdomeio.com/p/bugzilla/date-input-firefox-68.0b5.png
Also tested in english, french and german and all appear to be ok, only portuguese is broken.

Please file a new bug with these details.

Flags: needinfo?(alexandre)

(In reply to Wesley Huang [:wesley_huang] (EPM) (NI me) from comment #44)

(In reply to Sebastian Zartner [:sebo] from comment #43)

Wesley, what's the reason the types "month", "week", and "datetime-local"
were backlogged? And is it already planned to pick up the work again? Like
o-zilla, I assume there is at least a big need for "datetime-local".

Sebastian

The date and time types were considered as the higher priority ones when we
got the dev resource to ship in Firefox57.
The rest types were backlogged because of the limited resource/time at that
time.
I transitioned my focus to other project so I don't know the latest plan of
this backlog.
Maybe best for DOM or Product team to answer.

Are types "month", "week" and "datetime-local" still backlogged ?

Since the Firefox input types "date" and "time" work, could the "datetime-local" be quickly implemented as a combo of those?

What I'm describing is what the Edge (non-Chromium) browser does:

  • When selecting the date part, the "date" renders
  • When selecting the time part, the "time" renders

Having consistency of implementation of input types across browsers would be a nice plus for us web developers.

Flags: needinfo?(jstutte)

Please, when requesting more information from people, do state the information you expect to get.

Regarding the question above re. datetime-local, I commented on bug 1283388 comment 2 with instructions, and I'm happy to mentor if somebody wants to take it.

Flags: needinfo?(jstutte)
Depends on: 1283382

For the implementation of datetime-local, you may want to follow bug 1283388 (which Emilio already mentioned in the last comment).

And please only comment when you have implementation specific information because comments on this bug will be posted to a huge group of people following it.

Sebastian

Severity: normal → S3

Redirect a needinfo that is pending on an inactive user to the triage owner.
:sefeng, since the bug has high priority, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(alexandre) → needinfo?(sefeng)

After being told by Gijs, Alexandre filed bug 1555275 which was then marked as a duplicate of bug 1418061.

Sebastian

Flags: needinfo?(sefeng)
You need to log in before you can comment on or make changes to this bug.