On Windows 7, there is yy/mm/dd'('ddd')' as short date format of Japanese.
When selecting this, ddd isn't converted to day of the week correctly.
FindInReadable will update start position iterator even if not found. So when
using FindInReadable again, we have to reset start position iterator.
MozReview-Commit-ID: AoS1Txq3Twc
--HG--
extra : rebase_source : 2f02189d0288e833debb2d4ca47efbca632924e5
Add BrowserLocaleManager.refreshLocales, a native function which calls OSPreferences::Refresh, and BrowserLocaleManager.getLocale, which returns the current locale string. Use these in place of observing modification of the intl.locale.os pref.
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
This patch merges nsAtom into nsIAtom. For the moment, both names can be used
interchangeably due to a typedef. The patch also devirtualizes nsIAtom, by
making it not inherit from nsISupports, removing NS_DECL_NSIATOM, and dropping
the use of NS_IMETHOD_. It also removes nsIAtom's IIDs.
These changes trigger knock-on changes throughout the codebase, changing the
types of lots of things as follows.
- nsCOMPtr<nsIAtom> --> RefPtr<nsIAtom>
- nsCOMArray<nsIAtom> --> nsTArray<RefPtr<nsIAtom>>
- Count() --> Length()
- ObjectAt() --> ElementAt()
- AppendObject() --> AppendElement()
- RemoveObjectAt() --> RemoveElementAt()
- ns*Hashtable<nsISupportsHashKey, ...> -->
ns*Hashtable<nsRefPtrHashKey<nsIAtom>, ...>
- nsInterfaceHashtable<T, nsIAtom> --> nsRefPtrHashtable<T, nsIAtom>
- This requires adding a Get() method to nsRefPtrHashtable that it lacks but
nsInterfaceHashtable has.
- nsCOMPtr<nsIMutableArray> --> nsTArray<RefPtr<nsIAtom>>
- nsArrayBase::Create() --> nsTArray()
- GetLength() --> Length()
- do_QueryElementAt() --> operator[]
The patch also has some changes to Rust code that manipulates nsIAtom.
MozReview-Commit-ID: DykOl8aEnUJ
--HG--
extra : rebase_source : 254404e318e94b4c93ec8d4081ff0f0fda8aa7d1
The NS_LITERAL_CSTRING macro creates a temporary nsLiteralCString to encapsulate the string literal and its length, but AssignLiteral() can determine the string literal's length at compile-time without nsLiteralCString.
MozReview-Commit-ID: KXJM13VRTB7
--HG--
extra : rebase_source : 3e50b1b3f23248d668d15310554559c39ff792f7
extra : source : 74f5e05877d50a79ec1e5330c227d2ce576a2d90
Add additional logic to our language negotation to do apply likelySubtags when a direct match is not available.
Currently, if the user specifies the locale with region, and we do not have a direct for that region, we pick all locales for the same language and other regions in no order.
The example of where it returns suboptimal results:
1) Requested locale "en-CA"
2) Available locales ["en-ZA", "en-GB", "en-US"]
3) Negotiated locales ["en-ZA", "en-GB", "en-US"]
This would not happen, if the user requested a generic "de", "en" etc.:
1) Requested locale "en"
2) Available locales ["en-ZA", "en-GB", "en-US"]
3) Negotiated locales ["en-US", "en-ZA", "en-GB"]
because after not finding a direct match, we would use likelySubtags to extend "en" to "en-Latn-US" and then find the priority match in "en-US".
This patch extends this logic to "en-US" or "de-LU" by adding a step which strips the region tag and then applies likelySubtag on the result.
This means that in absence of direct match the following fallbacks would happen:
"de-LU" -> "de-DE"
"es-CL" -> "es-ES"
"en-CA" -> "en-US"
This does not affect languages that use multiple scripts, so ar, sr and zh are not affected.
MozReview-Commit-ID: BR1WrgXSf6a
--HG--
extra : rebase_source : abc205c4f993680ab0cd0c8b8c016543d5462d01
By the time the LocaleService destructor is called, by definition sInstance
has been cleared and its preference observers have been removed, since both
are strong references. In practice, this doesn't seem to cause trouble, but it
does lead to worrying warnings at shutdown in debug builds, which are annoying
red herrings when debugging other issues.
MozReview-Commit-ID: IalOigr2GWN
--HG--
extra : rebase_source : f86a8e81b91c639dedaca85e5bc3b53d54e01645
extra : histedit_source : 643b76de0d29ca4890ac4dd4175259989a63688e
Until Firefox 54, font fallback uses user locale. Example, OS is Windows 10 JA with JA UI, Firefox uses JA font for fallback even if Firefox is US version.
But since we changed some locale code on Firefox 55 development cycle, there were some regressions such as bug 1346674. So we changed fallback locale to system locale (instead of Firefox UX locale) for font selection by bug 1348259.
It isn't good for old compatibility, so we should use user locale for font fallback like Firefox 54. Now we can get user locale by OSPreferences::GetRegionalPrefsLocales, use it for font fallback
MozReview-Commit-ID: 7qwDDeU1ZPt
--HG--
extra : rebase_source : 3a307dd239bea516e117961a944b714bc43a993c
This should be the only callee affected, given
gfxPlatformFontList::GetFontPrefLangFor already uses case-insensitive string
comparison.
This makes it also consistent with the rest of the functions in the file, which
lowercase their inputs as well.
MozReview-Commit-ID: 4fNUBdpayHL
--HG--
extra : rebase_source : d669f5da2a1ed06f6348fc6b86eb379b514ddcf3
Original issue is that Microsoft Dynamics CRM uses invalid lang attribute in <xsl:sort>.
<xsl:sort order="descending"
select="@displayname[$sortColumnName='displayname'] |
@name[$sortColumnName='name'] |
exslt:node-set($FriendlyTypeNames)/types/type[@xmlName=current()/@datatype and $sortColumnName='datatype']"
lang="$languageName"/>
Our XSLT implementation detects "$languageName" as locale name, then use it to nsICollation.
Until Gecko 54 for Windows, even if using invalid locale name for nsICollation, it uses platform locale as fallback. But from 55, we use same implementation as macOS's to use ICU. So this issue occurs. ICU implementation doesn't use fallback locale if it is invalid.
We should use fallback locale if locale is invalid. Most code for fallback locale such as FallbackEncoding uses application locale, so use it.
MozReview-Commit-ID: EKYkZG7Hnz0
--HG--
extra : rebase_source : fec89c67317d7df041f3b237122fb7e20e32fe1b
Introduce a separate API for retrieving locale set from the host environment
used for regional preferences localization.
MozReview-Commit-ID: 3597QstZjS3
--HG--
extra : rebase_source : 2ac30ba2f2c9bd1ed308cfe7be88f6add4f0f5ae
In scenarios where users use OS in one locale set and the App in another,
users should be able to chose which locale set to follow for regional
preferences. This method should be used over getAppLocales for all cases
where the locales are used to format regional preferences related
items like calendars, dates, units etc.
MozReview-Commit-ID: OOBYIZCKXE
--HG--
extra : rebase_source : be1b96728ff85b6c3e96a2a08db737c3e247cbbc
It's silly to use prmem.h within Firefox code given that in our configuration
its functions are just wrappers for malloc() et al. (Indeed, in some places we
mix PR_Malloc() with free(), or malloc() with PR_Free().)
This patch removes all uses, except for the places where we need to use
PR_Free() to free something allocated by another NSPR function; in those cases
I've added a comment explaining which function did the allocation.
--HG--
extra : rebase_source : 0f781bca68b5bf3c4c191e09e277dfc8becffa09
