Error code: sec_error_expired_certificate page does not localise dates on Android

NEW
Unassigned

Status

()

3 years ago
3 years ago

People

(Reporter: moz_en-gb, Unassigned)

Tracking

45 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
Navigating to a site with expired security certificate on Android leads to surprise due to non-localised date format:

"towncentrecarparks.com uses an invalid security certificate. The certificate expired on 01/02/16 23:59[...]"

Everywhere but the USA, this means the 1st of February...

On desktop Firefox, the date is correctly localised.  But, I can't see how/where mobile formats dates to know whether this is a l10n issue (ie en-GB has a date-formatting string wrong) or an i18n issue. The particular tablet I saw this issue on is set for English (United Kingdom).

I don't know if you have sites with expired certs to test on, but if not,
https://towncentrecarparks.com/leeds/clarence-dock was the one I was trying to get to when I stumbled on this
This probably depends on shipping ICU. Which is several megabytes of data about date formats (and many other things) around the world.
Depends on: 1215247

Comment 2

3 years ago
The cert error page is mostly HTML and JS, but this bit of it actually doesn't appear to be implemented in HTML and JS.

Rather, the formatting of the overall string here is performed in security/manager/ssl/TransportSecurityInfo.cpp:AppendErrorTextTime, which uses that file's GetDateBoundary method to format the two dates, which uses "@mozilla.org/intl/datetimeformat;1"'s formatPRTime method, which probably turns into intl/locale/unix/nsDateTimeFormatUnix.cpp on Android.  That method selects the locale to use by consulting "@mozilla.org/intl/nslocaleservice;1" for the applicationLocale, then the .category (a locale tag, basically) off that.

So what sets the global applicationLocale, then?  Looks like something in intl/locale/nsLocaleService.cpp that may just be the value of the LANG environment variable, on Android.  Not 100% sure.

Anyway, that's more debugging than I have much reason to do here -- someone else should take over shepherding this into the right component.  Probably Core::Internationalization to initialize to the right thing, but I could be mistaken about that if Android's simply failing to do its own initialization somewhere.
No longer depends on: 1215247
(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #2)
> The cert error page is mostly HTML and JS, but this bit of it actually
> doesn't appear to be implemented in HTML and JS.
> 
> Rather, the formatting of the overall string here is performed in
> security/manager/ssl/TransportSecurityInfo.cpp:AppendErrorTextTime, which
> uses that file's GetDateBoundary method to format the two dates, which uses
> "@mozilla.org/intl/datetimeformat;1"'s formatPRTime method, which probably
> turns into intl/locale/unix/nsDateTimeFormatUnix.cpp on Android.  That
> method selects the locale to use by consulting
> "@mozilla.org/intl/nslocaleservice;1" for the applicationLocale, then the
> .category (a locale tag, basically) off that.
> 
> So what sets the global applicationLocale, then?  Looks like something in
> intl/locale/nsLocaleService.cpp that may just be the value of the LANG
> environment variable, on Android.  Not 100% sure.

Bionic (Android's libc) has no location data correctly.  so nsDateTimeFormatUnix.cpp doesn't work for localization well.

There is bug 943288 as related bug to replace with ICU.
s/location/localization/
You need to log in before you can comment on or make changes to this bug.