Moves IsDevelopmentBuild(), GetRepoDir(), and GetObjectDir() out of
SandboxSettings because they also need to be used by ExtensionProtocolHandler
to do security checks on developer builds as a result of how developer builds
rely on symlinks to the repo dir from system extension directories.
Remove the Linux-implementation of GetRepoDir() and GetObjectDir()
because the Linux content sandbox implementation and the
ExtensionProtocolHandler checks don't need them.
MozReview-Commit-ID: KwBFUnh6Cml
--HG--
extra : rebase_source : 3529a18ea802699ff968b798a7c560613469809b
Without this patch, all remote process types share a process name of
"Web Content". With this patch, specific names are added for "file",
"extension", and "webLargeAllocationTypes", with the default of "web"
left as the default "Web Content".
This patch also eliminates undocumented b2g-era legacy logic that had a
notion of whether it's acceptable to override the process name. In the
b2g era, I believe processes were named based on the "app" that was
running. It would have made sense to have the process initially named
the preallocated process, then to change the process to its app name
when specialized, trying to make it hard/impossible for the process to
rename itself so it couldn't masquerade as another app if it became
compromised.
--HG--
extra : source : c76be2df2c2855ddf2fafc323ddb2898dd65eba4
Instead of synchronously checking the blocklist, package each plugin's
blocklist state with it when sending the information to the content
process. Whenever the blocklist is changed, just resend the whole
plugin list.
MozReview-Commit-ID: 1AX1EDdTRqb
--HG--
extra : rebase_source : 95d30f23eaede357bfb03757a7d9a6cc62e2adf9
MozReview-Commit-ID: A1lCqvbQYAF
There is no clean API-based solution to this, so instead I went grovelling
through the DCOM wire protocol and was able to write a function that converts
handler OBJREFs into standard OBJREFs.
See also:
https://msdn.microsoft.com/en-us/library/cc226801
--HG--
extra : rebase_source : a650055c4adda3a1d99262e47f2b463074c6b935
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
Bevis Tseng
Stone Shih
Michael Layzell
Haik Aftandilian
Jan Varga
Andrew Sutherland
Amy Chung
Sebastian Hengst
Chun-Min Chang
Marco Castelluccio
Kyle Machulis
Nicholas Nethercote
Bill McCloskey
Milan Sreckovic
Andrew Osmond
Wes Kocher
Aaron Klotz
Ryan VanderMeulen
Peter Van der Beken
Markus Stange
Andrea Marchesini
Phil Ringnalda
Kris Maglione
David Anderson
Gerald Squelart
Carsten "Tomcat" Book
Zibi Braniecki