In order to allow localizations to produce different string depending on the
platform, we need to add a Gecko-specific built-in function to the MessageContext.
I'm explicitly listing the variables which we pass, rather than just passing the value
in order to ensure we don't start returning values we didn't plan for in case
the AppConstants.platform gets updated.
MozReview-Commit-ID: 1KZ6bf6zIY2
--HG--
extra : rebase_source : ce75c2c32bfb29b10b6ddbcaf6a71e2bf4cd4315
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
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
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
This patch moves the destructor after the constructor, puts the
NS_IMPL_ISUPPORTS line in a more sensible spot, and moves the Get*() functions
before the Format*() functions in order to match the order in
nsIStringBundle.idl.
--HG--
extra : rebase_source : 54250432bd084acd628ab1834bd344687a2f961d
GetStringFromName() enters mReentrantMonitor(), and the other Get*() functions
go through GetStringFromName(). But none of the Format*() functions enter the
monitor.
This patch moves some repeated code from GetStringFromName() and
FormatStringFromName() into GetStringFromNameHelper(), including the monitor
entry. All the Get*() and Format*() functions now use
GetStringFromNameHelper(), which means they now all enter the monitor.
--HG--
extra : rebase_source : 5d4c1931fb374d7aa10d6851f5ad8c0c774ffa79
Similar to the previous patch, this patch changes GetStringFromID() to call
GetStringFromName(), but this time in nsExtensibleStringBundle.
--HG--
extra : rebase_source : 38b12f5f0010396b2606969fb0c7baef96debe21
GetStringFromIDHelper() is very similar to GetSringFromNameHelper(). This patch
removes the former, and changes GetStringFromID() to call GetStringFromName(),
similar to how FormatStringFromID() calls FormatStringFromName().
--HG--
extra : rebase_source : ca1d6abffde106d5409b71c8c181fd604fc974ce
nsStringBundle has two public methods GetStringFrom{ID,Name}() and two
very similar helper methods with the same name. It's easy to get confused
between the two -- indeed, it may be the reason for the data race that this bug
is about -- so this patch renames the helper functions by adding a "Helper"
suffix.
--HG--
extra : rebase_source : 75a15e91c50c4b50b2984377980785b64fcf8852
Most of the names passed to nsIStringBundle::{Get,Format}StringFromUTF8Name
have one of the two following forms:
- a 16-bit C string literal, which is then converted to an 8-bit string in
order for the lookup to occur;
- an 8-bit C string literal converted to a 16-bit string, which is then
converted back to an 8-bit string in order for the lookup to occur.
This patch introduces and uses alternative methods that can take an 8-bit C
string literal, which requires changing some signatures in other methods and
functions. It replaces all C++ uses of the old methods.
The patch also changes the existing {Get,Format}StringFromName() methods so
they take an AUTF8String argument for the name instead of a wstring, because
that's nicer for JS code.
Even though there is a method for C++ code and a different one for JS code,
|binaryname| is used so that the existing method names can be used for the
common case in both languages.
The change reduces the number of NS_ConvertUTF8toUTF16 and
NS_ConvertUTF16toUTF8 conversions while running Speedometer v2 from ~270,000 to
~160,000. (Most of these conversions involved the string
"deprecatedReferrerDirective" in nsCSPParser.cpp.)
--HG--
extra : rebase_source : 3bee57a501035f76a81230d95186f8c3f460ff8e
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
All the instances are converted as follows.
- nsSubstring --> nsAString
- nsCSubstring --> nsACString
--HG--
extra : rebase_source : cfd2238c52e3cb4d13e3bd5ddb80ba6584ab6d91
All the instances are converted as follows.
- nsAFlatString --> nsString
- nsAFlatCString --> nsCString
--HG--
extra : rebase_source : b37350642c58a85a08363df2e7c610873faa6e41
Move the class definition out of an unnamed namespace because it is in a header files included in multiple source files. clang treats the header file's class declaration in an unnamed namespace as distinct in each compilation unit and emits -Wunused-member-function warnings because the member function release() is used in some compilation units but not others.
intl/unicharutil/util/ICUUtils.h:25:17 [-Wunused-member-function] unused member function 'empty'
intl/unicharutil/util/ICUUtils.h:26:17 [-Wunused-member-function] unused member function 'release'
MozReview-Commit-ID: 7AgzzzRgni4
--HG--
extra : source : aeed73b6225ba4834a25de0ec9e23592de25c871
extra : intermediate-source : d0788a9eba9621e04f6be30771acac5707d4a7e1
