input date does not display using dateformat specified in the OS
Categories
(Core :: DOM: Forms, enhancement)
Tracking
()
People
(Reporter: mozilla, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(7 files)
Chromium
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Steps to reproduce:
Any HTML with an input type="date" will display the incorrect behaviour when you set the OS date format to something different than the default.
<input type="date">
My OS dateformat is yyyy-MM-dd, and I use Firefox English (British)
Actual results:
Firefox displays the input date with the date format dd/MM/yyyy regardless of the setting in the OS.
Expected results:
Firefox should have asked the OS for the correct format and display the input date with yyyy-MM-dd. Please note that both Edge and Chromium do this correctly and ask the OS for the right format as can be seen on this example page: https://html5tutorial.info/html5-date.php
Hi, bazzz.nl!
Thanks for your contribution!
I've been doing some research and I don´t know if this is expected behavior according to MDN references, anyway I'm not a dev and by the way you described the issue seems like it is not the common behavior. Probably the described issue is covered inside the following task https://bugzilla.mozilla.org/show_bug.cgi?id=888320. If that´'s not the case, please follow the thread below so you can add any more information.
I´ll add product and component to this one so devs can check it.
Regards,
(In reply to Seba S. from comment #1)
I've been doing some research and I don´t know if this is expected behavior according to MDN references, anyway I'm not a dev and by the way you described the issue seems like it is not the common behavior. Probably the described issue is covered inside the following task https://bugzilla.mozilla.org/show_bug.cgi?id=888320. If that´'s not the case, please follow the thread below so you can add any more information.
I´ll add product and component to this one so devs can check it.
Hello Seba S.
Thanks for adding the required information to have the devs check it out. I read the linked bug and this issue may or may not be there, I am unsure because that bug is rather long, specified rather broad and has been open for over 7 years. In my humble opinion if an issue is small, perhaps it is better to keep it in a small bug so it has a higher change of being understood by the devs and getting fixed?
Based on your suggestion of having a look at the MDN, I went there to have a look myself and found the following information in a yellow note on page https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date
The displayed date format will differ from the actual value — the displayed date is formatted based on the locale of the user's browser, but the parsed value is always formatted yyyy-mm-dd.
I have two comments based on this finding:
- Firefox does not behave according to this information because it does not base the dateformat on the locale of the user's browser, but on the selected language in the browser. Which to me seems strange or simple wrong, as one could prefer a certain language yet have another preference for dateformat, or even live in another country. I am Dutch, live in the Netherlands, prefer British English as browser language and prefer dateformat ISO8601. Surely the relation between one's preference for language and preference for dataformat is correlated at best, but perhaps unrelated at all. My wife is Italian, lives with me in the Netherlands (locale), prefers the browser in English (language) and prefers dates and times in Italian (datetime format). All three are unrelated.
- Firefox's biggest competitors (Chromium and Edge) seem to have found a similar issue as I describe in comment 1 because they both take the dateformat from the user's preference as set in the OS. Which to me seems correct. If one has a certain preference for dateformat they would have the same preference for every application they use. Therefore, it is logical to store this preference in a user profile on the OS level and every application can read it from there. It also makes sense that if the user changes their preference in the OS, all applications adapt accordingly. As said, both Chromium and Edge exhibit this behaviour, so I am sure I am not talking complete rubbish. :)
All three screenhots are made on the same computer with OS dateformat set to ISO8601, OS region set to Netherlands and Firefox browser language set to British English. As you see on the screenshot of Firefox it does not take ISO8601 dateformat, but comes up with a format that it believes matches my preference based on the chosen language. Which I believe is wrong.
|
||
Comment 7•4 years ago
|
||
Firefox 77 is going to add a checkbox in preferences to follow the international settings from your OS (bug 1379910), that should cover this bug.
|
||
Updated•4 years ago
|
|
|
||
Comment 8•4 years ago
•
|
||
I believe this is a WORKSFORME or WONTFIX, as it's working by design with Firefox en-GB and nl regional settings at OS level
https://firefox-source-docs.mozilla.org/intl/locale.html#regional-preferences
There are workarounds in about:config, and in preferences from 77
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 9•4 years ago
|
||
I believe this is a WORKSFORME or WONTFIX
I'm not sure yet, let's see deeper.
Bas, thank you for reporting this. I'll try to explain the situation a bit, but I'm also interested in understanding better your claim that other engines handle it differently.
Firefox should have asked the OS for the correct format and display the input date with yyyy-MM-dd.
The risk with that is that is fingerprintable. In other words, if we take your OS customizations and "alter" our behavior based on that the website can learn bits of identifiable information from it.
We're currently avoiding that by only using the OS provided information for the date and time formatting that happens within the user interface of the browser, but not with the widgets in websites.
Please note that both Edge and Chromium do this correctly and ask the OS for the right format as can be seen on this example page: https://html5tutorial.info/html5-date.php
I'd like to better understand your setup to verify that claim. When we designed the system, we worked together with engineers from other engines on how to make the system less fingerprintable, but their approach may have changed.
Alternatively, you may have a slightly different version of the browser locale which may lead to different result.
Can you answer several questions for me?
- Can you got to
about:supportin Firefox and copy/paste here the "Localization and Internationalization" section values? - Can you describe in more detail what do you mean by "when you set the OS date format to something different than the default."?
Windows has multiple settings related to customizations of date/time patterns. Which one did you manually change?
- Can you verify that Chrome and/or Edge will actually follow that customization - if you change it and reload the browser, check the result, and then change it again, reload and check if it changed?
I'm really curious about (3) especially, because if they do, then it may be something worth reporting to them as a potential fingerprint vector. I'd like to consult my colleagues working on those engines on what bits they expose (which customizations they expose) and if they consulted their privacy engineers on that design decision.
Arthur, are you aware of any privacy oriented changes in the spec related to exposing OS customizations via in-page widgets like date/time picker?
Am I correct that altering those bits would be readable by the website? I remember that was the case long time ago (via reading of dialog size I think?), but I also remember there was a conversation about ways to enable us to expose the date/time picker customization without letting the website read that information.
|
Reporter | |
Comment 10•4 years ago
|
||
|
|
Reporter | |
Comment 11•4 years ago
|
||
(In reply to Francesco Lodolo [:flod] from comment #8)
I believe this is a WORKSFORME or WONTFIX, as it's working by design with Firefox
en-GBandnlregional settings at OS level
https://firefox-source-docs.mozilla.org/intl/locale.html#regional-preferences
There are workarounds in about:config, and in preferences from 77Gecko 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.
Thanks for your reply. The reference to the design spec is a great addition and I appreciate your finding. However, I strongly oppose marking this bug as 'worksforme' or 'wontfix' for the reason that you specified unless you have tested that it works according to the spec and can demonstrate that. As according to me it does not work according to spec at all. My OS language is English and my Firefox language is English as well, so Firefox should look in the OS datetime preference according to the spec. Yet it does not. I will add are the screenshots to demonstrate my point.
|
|
Reporter | |
Comment 12•4 years ago
|
||
(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #9)
Can you answer several questions for me?
- Can you got to
about:supportin Firefox and copy/paste here the "Localization and Internationalization" section values?- Can you describe in more detail what do you mean by "when you set the OS date format to something different than the default."?
- Can you verify that Chrome and/or Edge will actually follow that customization - if you change it and reload the browser, check the result, and then change it again, reload and check if it changed?
1
Internationalisation & Localisation
Application Settings
Requested Locales ["en-GB","en-US","nl"]
Available Locales ["en-US","en-GB","nl"]
App Locales ["en-GB","en-US","nl"]
Regional Preferences ["en-150"]
Default Locale "en-US"
Operating System
System Locales ["en-150"]
Regional Preferences ["en-150"]
2
In my OS I have chosen
Language: English(Europe)
Region: Netherlands
Regional Format: English(Europe)
And then changed the short date format to yyyy-MM-dd, which is not the default for English(Europe)
3
Both Edge and Chromium follow my customisation as specified in point 2. I just tested it, and if you want I can add screenshots. If I undo my customisation and roll back to the default for English(Europe), which is dd/MM/yyyy, then Edge as well as Chromium display it such. Then, if I make my customisation again, Edge and Chromium display according to my earlier screenshots. To be completely frank, that is exactly what I would expect as an end user. If I change my preference on the OS level, I expect applications to follow. Which Edge and Chromium seem to do, yet Firefox stubbornly does not. :)
|
|
Reporter | |
Comment 13•4 years ago
|
||
|
|
Reporter | |
Comment 14•4 years ago
|
||
|
|
||
Comment 15•4 years ago
|
||
Thank you!
So, for the sake of the argument, I'd like to then focus on the short date format, which you manually set to yyyy-MM-dd pattern. I assume that if you were to change it to something even more custom, say yyyy # MM # dd Chrome and Edge would display that on https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date page, right?
If so, then we should verify that either:
a) this bit is not user fingerprintable
b) this bit is user fingerprintable in all browsers
c) this bit is user finderprintable in Firefox but not other browsers
And then, if:
a) hook OSPreferences into date/time format widgets (so, basically use mozIntl.DateTimeFormat instead of Intl.DateTimeFormat)
b) report to W3C and other vendors to discuss the options
c) file a bug to make the date/time widgets not fingerprintable irrelevant of content
I'm keeping the NI on Arthur in hopes he may know more about the situation.
Bas, thanks for the information. I think for now it is enough, and we need to investigate the fingerprinting ramifications of what we can do.
The good news is that we have all the hooks to expose either en-150 data (which is your regional locale), or/and the overrides you manually specified in your Windows settings.
The reason we don't do this now is laid out above. Let's see what the privacy expert says.
|
|
Reporter | |
Comment 16•4 years ago
|
||
(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #15)
So, for the sake of the argument, I'd like to then focus on the short date format, which you manually set to
yyyy-MM-ddpattern. I assume that if you were to change it to something even more custom, sayyyyy # MM # ddChrome and Edge would display that on https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date page, right?
Yes it does. Windows does not accept a pattern with a # in it, but I set it to something else ridiculous namely `yyyy-.-MM---dd' and see screenshot of Edge below.
|
|
Reporter | |
Comment 17•4 years ago
|
||
|
||
Comment 18•1 year ago
|
||
Clear a needinfo that is pending on an inactive user.
Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.
For more information, please visit auto_nag documentation.
|
|
Reporter | |
Comment 19•1 year ago
|
||
Hi all, I believe there is a minor confusion at play here. The bug was marked "need info" but not needing info from me. I already provided the requested info a while ago. As per the comment by Zibi Braniecki saying:
"Let's see what the privacy expert says."
it was waiting for info from those experts. Nevertheless, I honestly believe all the information is available to fix this bug. Perhaps the bug should be assigned to someone?
Description
•