1705310 - Displayed time typed HTML input doesn't respect system locale

Status: RESOLVED WONTFIX

(Core :: Internationalization, defect)

Description

[jcunews]

Attachment: JSBin screenshot

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:87.0) Gecko/20100101 Firefox/87.0

Steps to reproduce:

Make sure the OS/system locale's time format is set to 24-hours.

Open a HTML document which contains a time typed HTML input element.

Below JSBin code shows the problem.

https://jsbin.com/guhegohilu/edit?html,output

Actual results:

The time typed HTML input element shows the time using 12-hours format, instead of 24-hours format.

This applies to at least these platforms: Windows, Mac, Linux, Android.

JSBin screenshot (online source; same as attached):

https://i.imgur.com/FYTbIyr.png

Expected results:

The time typed HTML input element shows the time using 24-hours format according to the system locale's time format setting.

FYI, Chromium and MSIE respect the system locale's time format setting.

And below MDN article also states that the displayed time format of time typed HTML input element is based on the system locale.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/time#firefox

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Mirko Brodesser (:mbrodesser-Igalia), offline until April 25h]

Reproducible on Ubuntu 20.04 for instance when setting the language to German.

Reproducible on Ubuntu 20.04 for instance when setting the OS language to German and Firefox's language to German ("de-de").

Comment 3

[Emilio Cobos Álvarez (:emilio)]

This is supposed to work (here is the code). It seems our decision is fully locale-based rather than system-settings based though?

This is definitely not layout code :)

Comment 4

[Mirko Brodesser (:mbrodesser-Igalia), offline until April 25h]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)

This is supposed to work (here is the code). It seems our decision is fully locale-based rather than system-settings based though?

Apparently, it's more complicated:

For that reason, by default, Gecko will only look into OS Preferences if the language portion of the locale of the OS and Firefox match. That means that if Windows is in “en-AU” and Firefox is in “en-US” Gecko will look into Windows Regional Preferences, but if Windows is in “de-CH” and Firefox is in “fr-FR” it won’t.

Comment 5

[Mirko Brodesser (:mbrodesser-Igalia), offline until April 25h]

With

$ locale
LANG=en_US.UTF-8
LANGUAGE=en
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=de_DE.UTF-8
LC_TIME=de_DE.UTF-8

and flipping intl.regional_prefs.use_os_locales to true this works as expected.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

(In reply to Mirko Brodesser (:mbrodesser) from comment #4)
So I guess this is up to the i18n team to decide whether it should work.

Comment 7

[Zibi Braniecki [:zbraniecki][:gandalf]]

As documented in the link in comment 4 this is a privacy/quality tradeoff that every browser makes. For reference, Apple is switching to follow our model.

I consider this bug to work-as-expected, unless there's something else we should evaluate.

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Well, the time input format I think is not web-exposed in any way, so we could react to OS settings there, if we wanted to. If that's not desirable for some reason let's close as WONTFIX then.

Comment 9

[Zibi Braniecki [:zbraniecki][:gandalf]]

Well, the time input format I think is not web-exposed in any way,

There are some considerations for fingerprinting - I think there are ways to read the modal size which may change depending on locale used in it. I don't remember the details, but I remember that the boundary between web content and UI widgets had to consider that.

so we could react to OS settings there, if we wanted to.

We do if it matches languages. The issue is that we don't have the level of granularity of "if your OS is de-DE and your Firefox is en-US than only take OS hourCycle, but not numerical system or calendar".

We could add it and hourCycle is a great candidate due to high number of users who like to customize it, but I don't think we have cycles to work on that anytime soon. I'd suggest to WONTFIX and if someone wants to open a bug to fine-tune the locale matching to allow for hourCycle to be followed always from the OS, we could (I'd like that person to provide design for how to extend it, and how users would control it).

Comment 10

[Emilio Cobos Álvarez (:emilio)]

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #9)

There are some considerations for fingerprinting - I think there are ways to read the modal size which may change depending on locale used in it. I don't remember the details, but I remember that the boundary between web content and UI widgets had to consider that.

Yeah, that's totally fair, I hadn't realized this, but it's totally possible to guesstimate the setting based on input width, which you can control.

We could add it and hourCycle is a great candidate due to high number of users who like to customize it, but I don't think we have cycles to work on that anytime soon. I'd suggest to WONTFIX and if someone wants to open a bug to fine-tune the locale matching to allow for hourCycle to be followed always from the OS, we could (I'd like that person to provide design for how to extend it, and how users would control it).

Sounds good.