Bug 888320 (datetime)

[meta] implement all time and date related input types

NEW
Assigned to

Status

()

Core
DOM
4 years ago
18 days ago

People

(Reporter: rexyrexy2, Assigned: jessica)

Tracking

(Depends on: 11 bugs, Blocks: 2 bugs, 6 keywords)

Trunk
dev-doc-needed, DevAdvocacy, feature, html5, inputmethod, meta
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [parity-edge][parity-chrome][DevRel:P1])

(Reporter)

Description

4 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

4 years ago
Depends on: 888316
(Reporter)

Updated

4 years ago
Depends on: 825294
(Reporter)

Updated

4 years ago
Depends on: 777279, 769352
(Reporter)

Updated

4 years ago
Depends on: 888324
(Reporter)

Updated

4 years ago
Depends on: 888328
(Reporter)

Updated

4 years ago
Depends on: 888331
(Reporter)

Updated

4 years ago
Depends on: 446510
(Reporter)

Updated

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

Updated

4 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

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

Sebastian

Updated

3 years ago
Blocks: 802882

Updated

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

Updated

3 years ago
Blocks: 1005268

Updated

3 years ago
Depends on: 888316

Updated

3 years ago
Depends on: 888324

Updated

3 years ago
Depends on: 888328

Updated

3 years ago
Depends on: 888331

Comment 6

3 years ago
Bug 805049 may help for implementation.
Depends on: 805049
relnote-firefox: --- → ?
Keywords: relnote
relnote-firefox: ? → ---

Comment 7

3 years ago
What's the latest on this implemented?

Updated

2 years ago
Duplicate of this bug: 1133293
Keywords: DevAdvocacy

Updated

2 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

a year 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

a year 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

a year 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

a year 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)
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.
(Assignee)

Comment 30

a year ago
(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
Blocks: 1273644
Duplicate of this bug: 773205
Depends on: 1069609
Flags: platform-rel?
platform-rel: --- → ?

Updated

a year ago
Depends on: 1283381
Depends on: 1280654
(Assignee)

Updated

a year ago
Depends on: 1286182
(Assignee)

Updated

11 months ago
Depends on: 1288591
Depends on: 1289272
I think the whiteboard should include `[parity-blink]` as Chrome on Desktop has support as well.

Updated

10 months ago
Whiteboard: [parity-edge][DevRel:P1] → [parity-edge][parity-chrome][DevRel:P1]
Alias: datetime
Depends on: 1301295
Depends on: 1301304
Depends on: 1301306
Depends on: 1301308
Depends on: 1301310
Depends on: 1301312
No longer depends on: 805049
(Assignee)

Updated

9 months ago
Depends on: 1306215
(Assignee)

Updated

9 months ago
Depends on: 1306216
(Assignee)

Updated

9 months ago
Depends on: 1306217
Depends on: 1307384
No longer depends on: 1307384
Depends on: 1309457

Comment 33

8 months 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.
(Assignee)

Updated

8 months ago
Depends on: 1310587
Depends on: 1310823
Depends on: 1310831
Depends on: 1314542
Depends on: 1314544
(Assignee)

Updated

7 months ago
Depends on: 1320225
(Assignee)

Updated

7 months ago
Depends on: 1320227
Duplicate of this bug: 1322329
Depends on: 1323674
Depends on: 1332266
platform-rel: ? → ---
Depends on: 1337234
No longer depends on: 1310823
Depends on: 1344642
Depends on: 1346085
Depends on: 1347069

Updated

3 months ago
Depends on: 1348052
Depends on: 1349106
Keywords: dev-doc-needed

Updated

a month ago
Depends on: 1366620
(Assignee)

Updated

28 days ago
No longer depends on: 1366620
Depends on: 1370086
No longer depends on: 1370086
You need to log in before you can comment on or make changes to this bug.