This makes the code nicer. In particular, it removes many getter_Copies()
calls. The patch also converts a lot of nsCStrings to nsAutoCString, which will
avoid heap allocation in the common case.
The patch also renames PREF_CopyCharPref() as PREF_GetCStringPref(), because
it's actually getting a string, not a char, and that matches the existing
GetCString() and GetDefaultCString() methods. Correspondingly, it also renames
PREF_SetCharPref() as PREF_SetCStringPref().
The |aPrefName| arguments in nsIPrefBranch.idl remain as |string| because they
almost always involve passing in C string literals, and passing "foo" is much
nicer than passing NS_LITERAL_CSTRING("foo").
It's worth noting that early versions of this patch used |AUTF8String| instead
of |ACString|. But it turns out that libpref stores prefs internally as Latin1.
And |ACString| is compatible with Latin1 but |AUTF8String| isn't, because
non-ASCII Latin1 strings are not valid UTF-8!
MozReview-Commit-ID: D3f7a1Vl1oE
--HG--
extra : rebase_source : e6e4b15d6d210cfd93686f96400281f02bd1d06b
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.)
nsIURI.originCharset had two use cases:
1) Dealing with the spec-incompliant feature of escapes in the hash
(reference) part of the URL.
2) For UI display of non-UTF-8 URLs.
For hash part handling, we use the document charset instead. For pretty
display of query strings on legacy-encoded pages, we no longer care to them
(see bug 817374 comment 18).
Also, the URL Standard has no concept of "origin charset". This patch
removes nsIURI.originCharset for reducing complexity and spec compliance.
MozReview-Commit-ID: 3tHd0VCWSqF
--HG--
extra : rebase_source : b2caa01f75e5dd26078a7679fd7caa319a65af14
This patch does two things. The first is that it fixes the two tests mentioned in the title by saving a previously registered XULAppInfoFactory, unregistering it, registering the new factory, and then at the end of the test re-registering the factory which was registered before the test started. The second thing this patch does is remove the skipping conditions for these two tests so we can run them on linux64-jsdcov.
MozReview-Commit-ID: 71c1nrYvx1M
--HG--
extra : rebase_source : 818fc5e7fff8ff9985e42835928f26fc13387788
This patch first adds an argument to the 'do_get_file(...)' function call in 'test_chrome_bookmarks.js' that simply allows the 'chromefiles' folder to be non-existent if it does not exist. The 'CoverageUtils.jsm' file is then modified so that the import of 'osfile.jsm' does not interfere with any tests. So, it is now imported into the script after the test has completed. Two other tests have unwanted behaviour that cause code coverage collection to fail so they are also skipped through this patch.
MozReview-Commit-ID: H42HN1solkh
--HG--
extra : rebase_source : 82706778961cd5d7dee4f66eb691d8ec62bde365
In Fennec scenario, the package registration we should be monitoring for is different than "global".
OverrideLocalePackage handles the package overrides and gives us the right package name.
MozReview-Commit-ID: 44Nzd64CTq1
--HG--
extra : rebase_source : 848e98beae2222bce335f37ae87c60994ab6b0f9
Change mozilla::Smprintf and friends to return a UniquePtr, rather than
relying on manual memory management. (Though after this patch there are
still a handful of spots needing SmprintfFree.)
MozReview-Commit-ID: COa4nzIX5qa
--HG--
extra : rebase_source : ab4a11b4d2e758099bd0794d5c25d799a7e42680
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
The next patch moves nsCSSFontFaceRule into a separate header, which
somehow affects lots of header dependencies. I'm not completely sure
why this happens, though.
MozReview-Commit-ID: KuXbsaX0NUd
--HG--
extra : rebase_source : cef91018964b5488c5031df8aada90aa7fa0ad51
Zibi Braniecki
Sebastian Hengst
Nicholas Nethercote
Mithilan
Jonathan Kew
Chris Peterson
Chung-Sheng Fu
Masatoshi Kimura
Andrew McCreight
Sylvestre Ledru
Honza Bambas
Ryan VanderMeulen
Greg Mierzwinski
Mike Hommey
Wes Kocher
Andrea Marchesini
Tom Tromey
Zibi Braniecki
Xidorn Quan
Carsten "Tomcat" Book
Mark Banner
Florian Quèze
Joel Maher
Wei-Cheng Pan