888320 - (datetime) [meta] implement all time and date related input types

Status: NEW

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

Description

[rexyrexy2]

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).

Comment 5

[Sebastian Zartner [:sebo]]

This blocks the bug 802882.

Sebastian

Comment 6

[Florian Bender]

Bug 805049 may help for implementation.

Comment 7

[Scott Baker]

What's the latest on this implemented?

Comment 10

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hey Jessica, since you are working on it, I assign this to you. Let me know if you need any help.

Comment 11

[choarau]

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!

Comment 12

[Andre Klapper]

@choarau: Please read the last comment just before you added your comment. Thank you.

Comment 13

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(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.

Comment 14

[Tim Guan-tin Chien [:timdream] (please needinfo)]

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!

Comment 15

[:Gijs (he/him)]

(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.

Comment 16

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(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 :).

Comment 17

[:Gijs (he/him)]

(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... :-)

Comment 18

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(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 ...)

Comment 19

[Tim Guan-tin Chien [:timdream] (please needinfo)]

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!

Comment 20

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

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>.

Comment 21

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

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.

Comment 22

[Sebastian Zartner [:sebo]]

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

Comment 23

[Hsin-Yi Tsai (she/her) [:hsinyi]]

I've updated the assignee for bug 1069609.

Comment 24

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

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.

Comment 25

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

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. :)

Comment 26

[Neil Deakin]

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).

Comment 27

[:Felipe Gomes (needinfo for replies!)]

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.

Comment 28

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

We have similar setup to as what color have implemented already in bug 825294.

Comment 29

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

Well, the UI part there is native, I don't know what we use for color.

Comment 30

[Jessica Jong [:jessica] (inactive)]

(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.

Comment 32

[Michał Gołębiowski-Owczarek [:mgol]]

I think the whiteboard should include `[parity-blink]` as Chrome on Desktop has support as well.

Comment 33

[Djfe]

is someone still working on date in puts like datetime-local?
I would love to use it on my website someday in the future :)

Comment 34

[Sebastian Zartner [:sebo]]

(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

Comment 35

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

(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.

Comment 37

[709922234]

can i use js(`click()/focus()`) open picker?

Comment 38

[Jessica Jong [:jessica] (inactive)]

(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.

Comment 39

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

Well, it isn't clear whether click() should show the popup. Does it show up in other browsers?

Comment 40

[jtal04]

If not my children, I hope my grandchildren will be able to pick dates in FireFox.

Comment 41

[Jessica Jong [:jessica] (inactive)]

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

Comment 42

[o-zilla]

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!

Comment 43

[Sebastian Zartner [:sebo]]

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

Comment 44

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

(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.

Comment 45

[Sebastian Zartner [:sebo]]

(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

Comment 46

[m.kurz]

Support for "month", "week" and "datetime-local" would be really great! That is the only reason why we have to tell our customers to use Chrome or Edge, because these two browser do support that features... However I want to make them use Firefox of course ;)

Comment 47

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

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.

Comment 48

[Andrew Overholt [:overholt]]

Just a lack of time. Patches welcome :)

Comment 49

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Comment 50

[secretive.affairs]

Weighing in after having read all the comments on the issue: this needs a fix! Willing to undergo beta tests once a fix has been implemented.

Comment 51

[Alexandre Castro]

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.

Comment 52

[:Gijs (he/him)]

(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.

Comment 53

[diversscrap]

(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 ?

Comment 54

[Ron]

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.

Comment 55

[Emilio Cobos Álvarez (:emilio)]

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.

Comment 56

[nilskemail+github]

Safari TP 115 released Oct 22, 2020 now also supports date, time and datetime-local. month is still unsupported on MacOS and week is unsupported on MacOS and iOS. It would be nice if at least datetime-local would be implemented in the near future.

Comment 57

[Sven]

datetime-local – we miss you dearly on desktop Firefox! Your siblings date and time have done away with grisly and bug infested JavaScript in lotta places a great many moons ago. O brother, where art thou?

Comment 58

[diegosiao]

Please provide support to 'datetime-local' as it is widely used for web developers.

Firefox already support nicely the input type 'date', please start supporting 'datetime-local' WITHOUT the hour and minute picker, just for consistency with other browsers. The user can input the hour and minute values.

I am pretty sure that the experience would be acceptable for the majority of developers and certainly better than a plain input text.

In every form that uses 'datetime-local' I am having to alert users that:
-> 'This browser do not support this operation. Please, try again in Chrome, Edge or Safari'

You've been doing a great job and the Internet needs Firefox.

Thanks in advance.

Comment 59

[Sebastian Zartner [:sebo]]

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

Comment 60

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 61

[Sebastian Zartner [:sebo]]

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

Sebastian