1593337 - "Expired certificate" page doesn't use the Windows date format

Status: RESOLVED DUPLICATE of bug 1582356

(Firefox :: Security, defect, P2)

Description

[08xjcec48]

Attachment: date.png

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

Steps to reproduce:

Set the Windows and Firefox interfaces to en-US
Set the Windows regional format (date and time) to pt-BR

Actual results:

https://expired.badssl.com/ displays dates in the en-US format instead of using my custom system format.

Comment 2

[Francesco Lodolo [:flod]]

Sorry, after re-reading this is not a duplicate of that bug. What's the language you're using in Firefox?

This should also be relevant
https://firefox-source-docs.mozilla.org/intl/locale.html#regional-preferences

Comment 3

[08xjcec48]

Windows and Firefox language: en-US
Windows date: pt-BR

Comment 4

[Francesco Lodolo [:flod]]

If you create intl.regional_prefs.use_os_locales in about:config and set it to true, is the date formatted correctly?

Since browser and OS match, I would expect Firefox to look into the regional settings without that key.

Comment 5

[08xjcec48]

That setting was set to false, but even after setting it to true and restarting Firefox, the problem persists. This is what PowerShell outputs:

PS C:\Users\adm> Get-WinSystemLocale

LCID             Name             DisplayName
----             ----             -----------
1033             en-US            English (United States)

PS C:\Users\adm> Get-Culture

LCID             Name             DisplayName
----             ----             -----------
1046             pt-BR            Portuguese (Brazil)

Comment 6

[Simona Badau, Desktop QA]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0
Build ID: 20191103213857

I was able to reproduce this issue on my Windows 10 machine using "Romanian" (instead of the pt-Br one) as a regional format. I observed that the date of the "expired certificate page" does not respect the date of the set regional format on an en-US build but, if I open a ro locale build then, the date from the "expired certificate page" matches the set regional format. Not sure though what format should the page have, when the regional format and the localization of a build are different. Francesco, could you please advise on this matter?

Comment 7

[Francesco Lodolo [:flod]]

Someone should look in the code to see if we're using the right internationalization library. If we are, then it's a bug in Core::Internationalization.

Comment 8

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

Reported, can you copy&paste the bottom block of your about:support (about Internationalization settings)?

Comment 9

[08xjcec48]

Internationalization & Localization
Application Settings
Requested Locales ["en-US"]
Available Locales ["en-US"]
App Locales ["en-US"]
Regional Preferences ["pt-BR"]
Default Locale "en-US"
Operating System
System Locales ["en-US"]
Regional Preferences ["pt-BR"]

Comment 10

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

Thank you!

So, the code used to format that is: https://searchfox.org/mozilla-central/source/browser/base/content/aboutNetError.js#7

This is not the right API as explained here: https://firefox-source-docs.mozilla.org/intl/dataintl.html#services-intl

The tl;dr is that when we interact with unprivileged websites, we use public API that doesn't know what language the user selected in their OSPreferences, because we don't want to leak it due to fingerprinting.

When we interact with privileged documents, parts of Firefox UI, we have an API called "mozIntl" accessible via Services.intl which has the same DateTimeFormat API but allows for additional things, like, looking into OSPreferences.

Since this error page is part of Firefox UI, it should use mozIntl. But since it's not privileged, it may have to do a bit of dancing to call into privileged API for the formatted date, which I believe it should do.

It's a bug in the right component.

Comment 11

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

The priority flag is not set for this bug.
:wleung, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 12

[Wennie]

Hi J.C., please take a look at this bug. thanks!

Comment 13

[J.C. Jones [:jcj] (he/they)]

This looks like it would be a straightforward fix for someone on Ethan's team. Passing ni? to him for triage.

Comment 14

[Ethan Tseng [:ethan]]

Erica will look into how to fix this issue.

Comment 15

[Johann Hofmann [:johannh]]

This is a dupe of bug 1582356, which we consider a P5. Erica, feel free to re-assign yourself to that one (or to leave it, since IMO the priority is quite low).

Comment 16

[08xjcec48]

Correction: YOU are the one who considers it P5.