This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
Behavior change: Certain unpaired high surrogates will result in
the text being considered RTL where that wasn't the case before.
MozReview-Commit-ID: JL7wiRjhslC
--HG--
extra : rebase_source : ecd521a97be8908bb839aca02d624d86d5b0337f
Remove the headers included for "backwards compatibility" and just include them
where required.
--HG--
extra : source : e2beba7e6875120ebbbcadf24bcbcb5b86411a94
extra : amend_source : 11f07a27431cd468511f0bd45afe36150c6e342c
Remove the headers included for "backwards compatibility" and just include them
where required.
--HG--
extra : rebase_source : 03e703a81ed4b80f4f116ff36d8787464ce5acba
This removes an unnecessary level of indirection by replacing all
nsStringGlue.h instances with just nsString.h.
--HG--
extra : rebase_source : 340989240af4018f3ebfd92826ae11b0cb46d019
This patch moves us from using an old pref `general.useragent.locale`combined
with `intl.locale.matchOS` for retrieving user requested locale, to use a new
preference `intl.locale.requested` which stores a list of well-formed BCP47
language tags. If set to empty, the OS locales are used. If not set at all,
default locale is used.
We are also adding a piece of code to migrate from old to new system.
MozReview-Commit-ID: 854yQ1kC6Ee
--HG--
extra : rebase_source : c4a7171bc026f857f7878ee83d973ec01b536a84
We don't check error of unum_open, so we should check it. Because
unum_setAttribute doesn't have UErrorCode parameter.
MozReview-Commit-ID: 3j7jeiKbdG
--HG--
extra : rebase_source : 61d0daf8f14f1a36623967d9d63648a8a88e25ae
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
HasRTLChars() appears in profile of attachment 8848015 after landing the patches
for bug 1391538 because the landing made text in <input> or <textarea> always
treated as non-single byte characters. Therefore, HasRTLChars() is now called
by nsTextFragment::SetTo() a lot in editors.
HasRTLChar() checks if it's in an RTL character for each character until it
becomes true. However, if character is less than the minimum RTL character,
U+0590, it works faster at least for Western languages.
MozReview-Commit-ID: 4YecxQWUcmK
--HG--
extra : rebase_source : 172be670795f0e2155d4bd5044ee37f652367734
These are all easy cases where an nsXPIDLCString local variable is set via
getter_Copies() and then is only used in ways that nsCStrings can also be used
(i.e. no null checks or implicit conversions to |char*|).
In every case the patch trivially replaces the nsXPIDLCString with an
nsCString. (Also, there are a couple of unused nsXPIDLCString variables that
the patch simply removes.)
This patch introduces a new registry for localization resources to replace
ChromeRegistry. It uses asynchronous I/O and iterators to generate
permutations of possible sources of language resources for use in the new
Localization API.
In the initial form the API handles packages resources and has API for
interacting with the AddonsManager which will report language packs.
MozReview-Commit-ID: LfERDYMROh
--HG--
extra : rebase_source : 68a664c2c59a82b4dfcae66542c315a00ddae565
This patch lands the core of the new localization API:
* Parser for the Fluent syntax called "FTL"
* Resolver for the Fluent logic
* MessageContext class which is a central class for storing and operating
on Fluent messages.
MozReview-Commit-ID: E7nKGsLOCJe
--HG--
extra : rebase_source : 893178263744ef6cf6e64c135d28e10a53b61a19
This patch introduces a new registry for localization resources to replace
ChromeRegistry. It uses asynchronous I/O and iterators to generate
permutations of possible sources of language resources for use in the new
Localization API.
In the initial form the API handles packages resources and has API for
interacting with the AddonsManager which will report language packs.
MozReview-Commit-ID: LfERDYMROh
--HG--
extra : rebase_source : a6e5b790142e5afb1ce750478190e5ad87012f8d
This patch lands the core of the new localization API:
* Parser for the Fluent syntax called "FTL"
* Resolver for the Fluent logic
* MessageContext class which is a central class for storing and operating
on Fluent messages.
MozReview-Commit-ID: E7nKGsLOCJe
--HG--
extra : rebase_source : 9bb4c7b155c8b9bd8923534b69f643a6e85bb8af
This removes about 2/3 of the occurrences of nsXPIDLString in the tree. The
places where nsXPIDLStrings are null-checked are replaced with |rv| checks.
The patch also removes a couple of unused declarations from
nsIStringBundle.idl.
Note that nsStringBundle::GetStringFromNameHelper() was merged into
GetStringFromName(), because they both would have had the same signature.
--HG--
extra : rebase_source : ac40bc31c2a4997f2db0bd5069cc008757a2df6d
Zibi Braniecki
Cosmin Sabou
Jonathan Kew
Kris Maglione
Brindusan Cristian
André Bargull
Dorel Luca
Henri Sivonen
Andreea Pavel
Francesco Lodolo (:flod)
Gurzau Raul
Florian Quèze
Masatoshi Kimura
Eric Rahm
Csoregi Natalia
Sylvestre Ledru
Bogdan Tara
Makoto Kato
Dylan Roeh
Chris Manchester
Nika Layzell
Sebastian Hengst
Nick Alexander
Nicholas Nethercote
Wes Kocher
Chris Peterson
Mantaroh Yoshinaga
Phil Ringnalda
Mats Palmgren
Emilio Cobos Álvarez
Masayuki Nakano
Simon Lindholm
Carsten "Tomcat" Book
Kirk Steuber