Bug 888320 (datetime)

[meta] implement all time and date related input types

NEW
Unassigned

Status

()

enhancement
P2
normal
6 years ago
a month ago

People

(Reporter: rexyrexy2, Unassigned)

Tracking

(Depends on 14 bugs, Blocks 1 bug, 8 keywords)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [DevRel:P1])

Reporter

Description

6 years ago
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).
Reporter

Updated

6 years ago
Depends on: 888316
Reporter

Updated

6 years ago
Depends on: 825294
Reporter

Updated

6 years ago
Depends on: 777279, 769352
Reporter

Updated

6 years ago
Depends on: 888324
Reporter

Updated

6 years ago
Depends on: 888328
Reporter

Updated

6 years ago
Depends on: 888331
Reporter

Updated

6 years ago
Depends on: 446510
Reporter

Updated

6 years ago
Keywords: html5, inputmethod
Component: Developer Tools → DOM
Product: Firefox → Core

Updated

5 years ago
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
Duplicate of this bug: 888328
Duplicate of this bug: 888331
Duplicate of this bug: 888316
Duplicate of this bug: 888324

Updated

5 years ago
Keywords: feature
This blocks the bug 802882.

Sebastian

Updated

5 years ago
Blocks: html5test

Updated

5 years ago
No longer depends on: 888316, 888324, 888328, 888331

Updated

5 years ago
Blocks: 1005268

Updated

5 years ago
Depends on: 888316

Updated

5 years ago
Depends on: 888324

Updated

5 years ago
Depends on: 888328

Updated

5 years ago
Depends on: 888331

Comment 6

5 years ago
Bug 805049 may help for implementation.
Depends on: 805049

Comment 7

5 years ago
What's the latest on this implemented?
Duplicate of this bug: 1133293

Updated

4 years ago
Whiteboard: [parity-edge]
Duplicate of this bug: 1267878
Hey Jessica, since you are working on it, I assign this to you. Let me know if you need any help.
Assignee: nobody → jjong

Comment 11

3 years ago
notechnicalvalue
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

3 years ago
@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)

Comment 15

3 years ago
(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)

Comment 17

3 years ago
(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)

Comment 26

3 years ago
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: 773205

Updated

3 years ago
Duplicate of this bug: 773205

Updated

3 years ago
Depends on: 1069609
Flags: platform-rel?
platform-rel: --- → ?

Updated

3 years ago
Depends on: 1283381
I think the whiteboard should include `[parity-blink]` as Chrome on Desktop has support as well.

Updated

3 years ago
Whiteboard: [parity-edge][DevRel:P1] → [parity-edge][parity-chrome][DevRel:P1]
No longer depends on: 805049
No longer depends on: 1307384

Comment 33

3 years ago
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
Duplicate of this bug: 1322329
Depends on: 1332266
platform-rel: ? → ---
No longer depends on: 1310823

Updated

2 years ago
Depends on: 1348052

Updated

2 years ago
Depends on: 1366620
No longer depends on: 1366620
Depends on: 1370086
No longer depends on: 1370086

Comment 37

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

Updated

2 years ago
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?

Updated

2 years ago
No longer depends on: 1379571
Comment hidden (advocacy, metoo)
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

Comment 42

2 years ago
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

Updated

a year ago
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)
Comment hidden (advocacy)
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.)
Whiteboard: [parity-edge][parity-chrome][DevRel:P1] → [DevRel:P1]

Updated

11 months ago
Priority: -- → P2

Updated

7 months ago
Depends on: 1498787
Depends on: 1502390
Depends on: 1420126
Depends on: 1425218
Depends on: 1532923
Component: DOM → DOM: Core & HTML
Product: Core → Core
Comment hidden (metoo)
Type: defect → enhancement
You need to log in before you can comment on or make changes to this bug.