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
Code search indicates that it is used neither internally nor in any
addon. It should be safe to remove.
MozReview-Commit-ID: K3dBoydIwGk
--HG--
extra : rebase_source : 984aee342b0006af94eec1cd7fce123bccea4bd7
Code search indicates that this is not used internally, and the only
addon uses this is Breadcrumbs, which hasn't been updated since 2009,
thus it is already not compatible with current Firefox.
MozReview-Commit-ID: 1lUs7ceaaE1
--HG--
extra : rebase_source : 87060c33291ba415c6c70767c132c4a5b74d29fb
Since our platform support is Windows 7+, we can replace nsWin32Locale::GetXPLocale with LCIDToLocaleName.
LCIDToLocaleName has LOCALE_SYSTEM_DEFAULT and LOCALE_USER_DEFAULT, so we should it simply.
MozReview-Commit-ID: 7JhhXayIK7S
--HG--
extra : rebase_source : d6579e94b8471c73d03c1ac08cdb4b8ab072bed5
LocaleService serves two main functions. It is a central place for all code in the
engine to learn about locales, but it also does the language negotiation and selection.
The former is relevant in all processes, but the latter should only be performed
by the "main" process. In case of current Desktop Firefox, the parent process
is the one performing all the language negotiation, and content processes should
operate in the "client" mode.
In Fennec, there's a Java app on top of Gecko which should work as a "server"
and then all processes, including parent process of Gecko is merely a "client" for that.
This refactor finalizes this duality making it easily configurable to define in
which mode a given LocaleService operates.
The server-client model allows all clients to stay in sync with the server,
but operate transparently for all callers just returning the right values.
In order to initialize LocaleService in the client mode in child process with the
right locales I'm adding the list of app locales to the XPCOMInitData,
and then fire LocaleService::SetAppLocales in the child process initialization.
In order to keep the list up to date, I'm adding intl:app-locales-changed to
the list of observed topics, and when triggered, I send the updated list
to the child process, which updates LocaleService::SetAppLocales with the new
list.
MozReview-Commit-ID: K9X6berF3IO
--HG--
extra : rebase_source : ca5e502d064023fddfd63fe6fe5eccefce8dee52
clang's -Wcomma warning warns about suspicious use of the comma operator such as between two statements.
intl/uconv/util/nsUCSupport.cpp:552:34 [-Wcomma] possible misuse of comma operator here
MozReview-Commit-ID: Emk05qDJHbm
--HG--
extra : rebase_source : cfc7b16894f584f1e444e3296ab15c8d46f09698
extra : source : d61747509865b526772da48f94f9e1ba0548e6d3
StringBundle caches bundles, so when language chain changes we should
flush the cache to enable new strings to be loaded.
This also affects localized prefs like intl.accept_languages.
Then in HttpHandler we have to mark the value as dirty so that next
time it's called it actually recalculates using flushed string bundle
with the new locale.
MozReview-Commit-ID: DKWEDUli4yH
--HG--
extra : rebase_source : 75ecc4204deca066d7492d1494492a91685f36be
I'm adding a helper function mozILocaleService::GetRequestedLocale to simplify
most of the callsites that are looking for the first of the requested locales.
In most cases, I'm just matching the behavior of the code with reusing
LocaleService API instead of direct manipulation on the prefs.
That includes how I handle error case scenarios.
In case of sdk/l10n/locale.js I am reusing LocaleService heuristics over
the custom one from the file since the ones in LocaleService are just
more correct and unified accross the whole platform.
In case of FallbackEncoding I have to turn it into a nsIObserver to listen
to intl:requested-locales-changed.
MozReview-Commit-ID: 7rOr2CovLK
--HG--
extra : rebase_source : 883a91b249b6953b7872bfb9a8851e8be7257c7b
I'm adding a helper function mozILocaleService::GetRequestedLocale to simplify
most of the callsites that are looking for the first of the requested locales.
In most cases, I'm just matching the behavior of the code with reusing
LocaleService API instead of direct manipulation on the prefs.
That includes how I handle error case scenarios.
In case of sdk/l10n/locale.js I am reusing LocaleService heuristics over
the custom one from the file since the ones in LocaleService are just
more correct and unified accross the whole platform.
In case of FallbackEncoding I have to turn it into a nsIObserver to listen
to intl:requested-locales-changed.
MozReview-Commit-ID: 7rOr2CovLK
--HG--
extra : rebase_source : 2f166cf1746f389a035f7cf557edcadeacb10fa0
