Presumably this depends on bug 1726107 as well, and all fixes that might be required for that.

When someone picks this up, they could also look at reopening the date picker when a different value is focussed on (on Android at least). Test cases are:

1. Open page with datetime-local input

2. Tap day/month/year value
   brings up date picker

3. Click cancel on date picker

4. Tap day/month/year value
   brings up date picker (currently does not)

5. Open page with datetime-local input

6. Tap hour/minute/am/pm value
   brings up date picker (currently does not)

7. Click cancel on date picker

8. Tap hour/value/am/pm value
   brings up date picker (currently does not)

9. Open page with datetime-local input

10. Tap day/month/year value
    brings up date picker

11. Click cancel on date picker

12. Tap hour/minute/am/pm value
    brings up time picker (currently does not)

13. Open page with datetime-local input

14. Tap hour/minute/am/pm value
    brings up date picker (currently does not)

15. Click cancel on date picker

16. Tap day/month/year value
    brings up date picker (currently does not)

Can you file a separate bug about that? That seems like a different issue altogether.

The datepicker will be added to the <input type="datetime-local"> with the patch for 1676068 - there will be a Calendar button (instead of the Reset one) and the picker will open on Space or Enter keypresses on any of the date fields.

Oh, I think I need to close the pref bug 1726108 that is a duplicate of this one in its nature.

To add a11y consideration from there:
The datepicker a11y bug 1676068 drastically improves the accessibility of spinner widgets that are included on the timepicker panel, thus it appears to be beneficial to show the timepicker that would, among other pros, communicate to a screen reader user what are the minimum and maximum allowed values for each spin button, etc. (the remaining a11y enhancements for the timepicker panel are tracked in the bug 1802201).

This change could increase the adoption of a default time inputs vs custom, rarely accessible ones.

Other browsers like Edge and Chrome (on both macOS and Win) have a timepicker showing by default.

When implemented, the MDN time appearance example may need an updated screenshot as well.

(In reply to Anna Yeddi [:ayeddi] from comment #3)

The datepicker will be added to the <input type="datetime-local"> with the patch for 1676068 - there will be a Calendar button (instead of the Reset one) and the picker will open on Space or Enter keypresses on any of the date fields.

Hey Anna!
Is there an option to disable the Calendar button somehow? If not, are you thinking of implementing an option?

Cheers

(In reply to zookee1 from comment #6)

(In reply to Anna Yeddi [:ayeddi] from comment #3)

The datepicker will be added to the <input type="datetime-local"> with the patch for 1676068 - there will be a Calendar button (instead of the Reset one) and the picker will open on Space or Enter keypresses on any of the date fields.

Hey Anna!
Is there an option to disable the Calendar button somehow? If not, are you thinking of implementing an option?

Cheers

Hi Zookee1,

I was not thinking about it, because it would basically disable the datepicker to a mouse-only user altogether. The Calendar button does not appear now for read-only or disabled fields.

Could you share with me why would that be needed? Are you looking for a pref in about:config to toggle on an individual browser instance or something else? You can also file a new enhancement bug with some extra info in Layout: Form Controls and it can be discussed there too.

(In reply to Anna Yeddi [:ayeddi] from comment #7)

(In reply to zookee1 from comment #6)

(In reply to Anna Yeddi [:ayeddi] from comment #3)

The datepicker will be added to the <input type="datetime-local"> with the patch for 1676068 - there will be a Calendar button (instead of the Reset one) and the picker will open on Space or Enter keypresses on any of the date fields.

Hey Anna!
Is there an option to disable the Calendar button somehow? If not, are you thinking of implementing an option?

Cheers

Hi Zookee1,

I was not thinking about it, because it would basically disable the datepicker to a mouse-only user altogether. The Calendar button does not appear now for read-only or disabled fields.

Could you share with me why would that be needed? Are you looking for a pref in about:config to toggle on an individual browser instance or something else? You can also file a new enhancement bug with some extra info in Layout: Form Controls and it can be discussed there too.

Hey Anna :)
I was asking, since Firefox does not yet support a timepicker within <input type="datetime-local">, we'd like to polyfill it. We might as well polyfill the whole element for now, tho. I get your point, that without the calendar you'd lose accessibility, and I am 100% on your side here.

I am looking forward to seeing this element fully implemented at some point, especially since you all have been doing great work on Firefox overall.

Cheers

(In reply to zookee1 from comment #8)

(In reply to Anna Yeddi [:ayeddi] from comment #7)

(In reply to zookee1 from comment #6)

(In reply to Anna Yeddi [:ayeddi] from comment #3)

The datepicker will be added to the <input type="datetime-local"> with the patch for 1676068 - there will be a Calendar button (instead of the Reset one) and the picker will open on Space or Enter keypresses on any of the date fields.

Hey Anna!
Is there an option to disable the Calendar button somehow? If not, are you thinking of implementing an option?

Cheers

Hi Zookee1,

I was not thinking about it, because it would basically disable the datepicker to a mouse-only user altogether. The Calendar button does not appear now for read-only or disabled fields.

Could you share with me why would that be needed? Are you looking for a pref in about:config to toggle on an individual browser instance or something else? You can also file a new enhancement bug with some extra info in Layout: Form Controls and it can be discussed there too.

Hey Anna :)
I was asking, since Firefox does not yet support a timepicker within <input type="datetime-local">, we'd like to polyfill it. We might as well polyfill the whole element for now, tho. I get your point, that without the calendar you'd lose accessibility, and I am 100% on your side here.

I am looking forward to seeing this element fully implemented at some point, especially since you all have been doing great work on Firefox overall.

Cheers

:zookee1, Got you - thank you for the explanation and for nice words!

Now it is possible to show a timepicker by setting up pref dom.forms.datetime.timepicker to true but this only enables the time picker on an individual instance of the Firefox. The datepicker a11y enhancement did affect the timepicker and it should be now arguably more accessible (and dare I say usable). If you'd like time picker to be by default enabled to all time inputs, feel free to give the bug 17261070 an thumbs up :)

:Emilio, do you think that with the current appearance of the time picker look and feel, it could be re-enabled? I do not see any specific issues listed in the blocking bug 17261070.

It got turned off in bug 1315911, and there was no real context. Maybe Mike remembers what it was about? If it has improved, it might be worth running it through UX and get it enabled by default.

I honestly don't recall, but from what I can get from that bug, effort was being focused on the datepicker instead with the hopes of getting it out the door. It's possible that the work got broken in two (datepicker first, then timepicker), but various reorgs and churn resulted in us dropping that second part. That's just a guess though.

I suggest running timepicker through some accessibility and QA testing, and then determining if it's fit for purpose. If so, if the DOM folk feel good about it, I suggest we look at shipping it on by default.

(In reply to Mike Conley (:mconley) (:⚙️) from comment #11)

I honestly don't recall, but from what I can get from that bug, effort was being focused on the datepicker instead with the hopes of getting it out the door. It's possible that the work got broken in two (datepicker first, then timepicker), but various reorgs and churn resulted in us dropping that second part. That's just a guess though.

I suggest running timepicker through some accessibility and QA testing, and then determining if it's fit for purpose. If so, if the DOM folk feel good about it, I suggest we look at shipping it on by default.

The timepicker dialog was tested and the bug 1802201 includes the results. I just confirmed that it is still valid after the datepicker's bug 1676068 was fixed. I'd say that while there are few a11y concerns, they are not a show stoppers and, in general, the time picker is more or less usable with a keyboard alone and/or with a screen reader.

:Peter, or :Emilio (you are listed as a peer in the DOM governance too), would that be possible to request a QA testing for the time picker?

I can work on the a11y bug 1802201 while the datepicker's fixes are still fresh.

We're DOM peers but QA testing for the date picker seems more of UX stuff? Happy to sign off turning it on if QA and UX are happy with it tho. I'll try to get the QA request going.

I think we should probably enable it by default on nightly for now, get QA to test it before riding the trains.

I reached out to the Design Systems team to discuss the following re: time inputs:

1. Showing the time picker by default, and if so...
2. Showing a clock face as an image button on the right side of the <input type=date> that would toggle the time picker dialog, and if so...
3. Getting an icon, etc.

I'll post updates here once I have them. For now the bug to show a time picker on click on time inputs (when pref is on) is in progress for a on-click activation

I do think this issue is somehow stucked or forgotten...

moreover it is labelled as 'enhancement' while users would call it 'bug ' (at least on our helpdesk).

As for the latest version (113.0),
an <input type="datetime-local" />
is still displayed only as a date selector,
there is still no widget for time selector,

This bug is also referenced in MDM under: https://github.com/mdn/browser-compat-data/issues/16138

Is there any news ?

(In reply to mathieuv from comment #16)

I do think this issue is somehow stucked or forgotten...

moreover it is labelled as 'enhancement' while users would call it 'bug ' (at least on our helpdesk).

As for the latest version (113.0),
an <input type="datetime-local" />
is still displayed only as a date selector,
there is still no widget for time selector,

This bug is also referenced in MDM under: https://github.com/mdn/browser-compat-data/issues/16138

Is there any news ?

Hello mathieuv,

Thank you for following up on this bug! From the discussion that we had earlier (comments #10 and later), the next basic steps are (with updates):

1. Improve a11y of the picker - I am getting back on working on the bug 1802201 (as I just got back from the baby leave this week), it is mostly done but I need to write some tests for it
2. Get UX approval to have it enabled - got it before the leave, but with the UI as is, activated on click/Space anywhere on time sections of the input
3. enable the time picker by default in Nightly
4. get QA to test it in Nightly
5. Let it ride the trains to have it enabled in release

For 3-5 I'll check with Emilio and Mike when the a11y patch is landed.

As for the updates to the UI such as adding a clock button in the <input type=time> to open the time picker or/and embedding it into the date picker for <input type=datetime-local>, this would be an enhancement to be implemented later on (not by the Accessibility team, but with us, for sure)

Any updates on this? Would love to see this rolled out soon, this has been a frequent cause of frustration for me.

Thanks in advance!

Welcome to our Bugzilla, lola. Please note, however, that this is our workplace, so we try to limit bug comments to what is absolutely neccessary: relevant information regarding this bug, but not "I want this, too" posts, or "is there an update" questions. I understand that you're interested in this, but please keep in mind that we use our bugs as a knowledge store - and additional comments make it harder to understand the context quickly.

That being said, you can click the "follow" button on this bug, and all the bugs that are linked to this bug. If you do that, you will get updates via email as soon as there is an update.