Having to add pagehide/pageshow listeners to the chrome event target is a
serious inconvience for the use cases of this bug. Dispatching to system group
listeners has approximately the same effect as the old code, but is much
easier for window-bound code to handle.
--HG--
extra : rebase_source : d67c14e9ba91772d8a9dd82481120b34bdb551e0
The test case in this patch fails without the proper fix in the first patch
in this patch series.
In this patch two new nsIDOMWindowUtils APIs are introduced to change the
system font settins in tests. Currently the APIs work only on GTK+ platform.
Also to work the test case properly we need to open a new XUL window because we
don't propagate font changes into descendant documents yet (bug 1478212).
MozReview-Commit-ID: 4OLxEkEuF8d
--HG--
extra : rebase_source : 683e64f07c4d8820e5499d8c15b90975618559b8
This is mostly self-explanatory. However, the patch also contains some minor
changes to frame scripts which expect to be able to call message manager
methods with a null target object, which stops working when they stop being
global objects.
MozReview-Commit-ID: HDT2RvK3F3L
--HG--
extra : rebase_source : bb3ce8861a261ff1bc28a28b3ff88ba0deaef552
After these patches, these objects will no longer be globals, which would make
their current names misleading. Parts 1a-1c give more appropriate names to the
bindings which will cease to be globals.
MozReview-Commit-ID: L8GolQaHnO5
--HG--
rename : dom/base/ProcessGlobal.cpp => dom/base/ContentProcessMessageManager.cpp
rename : dom/base/ProcessGlobal.h => dom/base/ContentProcessMessageManager.h
extra : rebase_source : c5db43ff4f56bc27c869a8051c8d2c000b3fe287
This adds the basic framework for defining IPC actors which are lazily
instantiated for the appropriate frame loaders based on DOM events, message
manager messages, and observers. Actual actors are defined in follow-up
commits.
MozReview-Commit-ID: Jb6CWWW7v3v
--HG--
extra : rebase_source : 6c465c492ef423616346d70047c4fd4b074af303
Browsers can switch at runtime from remote to non-remote and vice versa,
which on the C++ side is detected from a XBL binding change which causes
nsIRemoteBrowser to either be implemented or not. Custom Elements can't
change at runtime in the same way, so unifying on a single [implements]
will allow browser (both remote and non-remote) to be migrated to a single
Custom Element.
To keep current functionality, this updates Qi calls into nsIRemoteBrowser
to instead Qi into nsIBrowser and check isRemoteBrowser.
Differential Revision: https://phabricator.services.mozilla.com/D3346
--HG--
extra : moz-landing-system : lando
They'll be reopened, so there's no security benefit, but this causes Activity
Monitor to not report the processes as 'not responding'.
Differential Revision: https://phabricator.services.mozilla.com/D2855
--HG--
extra : moz-landing-system : lando
They'll be reopened, so there's no security benefit, but this causes Activity
Monitor to not report the processes as 'not responding'.
Differential Revision: https://phabricator.services.mozilla.com/D2855
--HG--
extra : moz-landing-system : lando
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant C++ functions are updated to take a typed enum. JavaScript
calls are unaffected but they will throw if the string argument does not
correspond to one of the known entries in the C++ enum. The existing whitelists
and blacklists of annotations are also generated from the YAML file and all
duplicate code related to them has been consolidated. Once written out to the
.extra file the annotations are converted in string form and are no different
than the existing ones.
All existing annotations have been included in the list (and some obsolete ones
have been removed) and all call sites have been updated including tests where
appropriate.
--HG--
extra : source : 4f6c43f2830701ec5552e08e3f1b06fe6d045860
Summary:
Only implemented by nsWebBrowser, only 2 methods used in TabChild.
Move methods to nsWebBrowser implementation and remove unused methods,
change names to something more obvious, and remove interface.
MozReview-Commit-ID: 4WwBrVWQEVy
Test Plan: Try run
Reviewers: nika
Tags: #secure-revision
Bug #: 1480645
Differential Revision: https://phabricator.services.mozilla.com/D2752
Summary:
We only use one branch of the property set method in
nsIWebBrowserSetup, in one place. Expose this setting in the C++ API
and remove the XPCOM interface.
This patch also exposes the nsWebBrowser.h header to the codebase,
meaning we can possibly start removing some uses of nsIWebBrowser
elsewhere.
MozReview-Commit-ID: G3gnRWJUx6M
Test Plan: Try run
Reviewers: nika
Tags: #secure-revision
Bug #: 1480643
Differential Revision: https://phabricator.services.mozilla.com/D2736
We originally thought that this would enable us to disconnect from the
windowserver local service (which is a significant sandbox escape risk),
however investigations revealed that that requires changes to WebGL and thus
will be handled separately.
This also corrects an incorrect usage of the (undocumented) APIs for closing
windowserver connections. If CGSSetDenyWindowServerConnections is called while
there are open connections it is a no-op, so it must be called after
disconnecting any open connections.
Differential Revision: https://phabricator.services.mozilla.com/D2478
--HG--
extra : moz-landing-system : lando
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant functions are updated to take a typed enum (in C++) and an
integer constant (in JavaScript). A JavaScript wrapper around the crash
reporter service is provided to hold the constants. The existing whitelists
and blacklists of annotations are also generated from the YAML file and the
existing duplicate code has been consolidated. Once written out to the .extra
file the annotations are converted in string form and are no different than
the existing ones.
All existing annotations have been included (and some obsolete ones removed)
and all call sites have been updated including tests.
--HG--
extra : rebase_source : b4f0d4bf83c64851028c271d3fab3ebcb6fbcd3e
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant functions are updated to take a typed enum (in C++) and an
integer constant (in JavaScript). A JavaScript wrapper around the crash
reporter service is provided to hold the constants. The existing whitelists
and blacklists of annotations are also generated from the YAML file and the
existing duplicate code has been consolidated. Once written out to the .extra
file the annotations are converted in string form and are no different than
the existing ones.
All existing annotations have been included (and some obsolete ones removed)
and all call sites have been updated including tests.
--HG--
extra : rebase_source : f0e8d229581ac5c0daa0e0454cb258746108e28d
I generally tried to preserve the behavior of consumers where they treated an
exception from getInterface(Ci.nsIContentFrameMessageManager) as a signal to use
some sort of fallback.
I did change the behavior of consumers that walked up to the root same-type
docshell before getting the message manager to just get it directly from the
docshell they have. Please review those parts carefully, and let me know if you
want me to ask some subject area experts to review those.
I generally tried to preserve the behavior of consumers where they treated an
exception from getInterface(Ci.nsIContentFrameMessageManager) as a signal to use
some sort of fallback.
I did change the behavior of consumers that walked up to the root same-type
docshell before getting the message manager to just get it directly from the
docshell they have. Please review those parts carefully, and let me know if you
want me to ask some subject area experts to review those.
Fairly straightforward. This should allow us to enable our
forcepaint telemetry again without an added cost, since it's
just piggybacking on the existing content process BHR.
MozReview-Commit-ID: 83l9xnPfc9u
--HG--
extra : rebase_source : d53f1e9adfff1d9bf3610be634f9ece08a2ec154
This new id is added in the PerformanceInfo data and helps consumers distinguish
counters.
MozReview-Commit-ID: 7kEmqJcVggM
--HG--
extra : rebase_source : 40cca4c937f846db93ec1315036ad1bac04bc762
To not leave dangling BrowsingContexts due to crashing child processes
we need to detach all BrowsingContexts owned by a specific process
when that process goes away.
--HG--
extra : histedit_source : a737dd272224ae2595e8851813f3f9a66a2e01f2
Have BrowsingContext keep its own cache to enable caching of
BrowsingContexts, especially in the parent process.
This isn't really optimal, since it effectively duplicates the
cache in the child process. BFcache keeps a list of strong pointers to
the list of cached nsDocShells, where each nsDocShell in turn keeps a
reciprocated strong pointer to its BrowsingContext, which in turn is
held in the BrowsingContexts list of cached contexts. Ideally these
caches should be merged.
--HG--
extra : histedit_source : 094370f6d54d83728e8433ec5c47003086146476
Add BrowsingContext to allow the tree structure of docshells to exist
in several processes simultaneously. This is a first step towards
allowing a tree structure preserving separation of docshells across
processes.
--HG--
extra : histedit_source : d3c7f6ab4b9ae76f170c126d669ebd570e52f348
- Access nsISSLStatus directly as a member of nsITransportSecurityInfo
and nsISecureBrowserUI. This is part of a larger effort to consolidate
nsISSLStatus and nsITransportSecurityInfo.
- The TabParent implementation of GetSecInfo will always return null.
- Removed unnecessary QueryInterface calls
- Style adherence updates
MozReview-Commit-ID: Dzy6t2zYljL
--HG--
extra : rebase_source : 9c400bed3c9d29a186fc987c9bd0ffceb37bfd94
- Access nsISSLStatus directly as a member of nsITransportSecurityInfo
and nsISecureBrowserUI. This is part of a larger effort to consolidate
nsISSLStatus and nsITransportSecurityInfo.
- The TabParent implementation of GetSecInfo will always return null.
- Removed unnecessary QueryInterface calls
- Style adherence updates
MozReview-Commit-ID: Dzy6t2zYljL
--HG--
extra : rebase_source : fbfbcf7608efbfb35c9be4018ff0f4e70b2768d2
We were previously failing to send blobs to new content processes, which was a
problem for those processes. But we were also attempting to extract blobs for
new entries that we were serializing after we'd extracted their structured
clone data, and their blob array had been thrown away (which was a problem for
all processes).
This patch fixes both problems.
MozReview-Commit-ID: 3qbAmUTA85g
--HG--
extra : rebase_source : 87ed9356aa23ae83762a887cf12ba1f466e7bf61
The stack object might be a CCW and we want to make it impossible to get a CCW's global. Now the caller has to supply a same-compartment global object, so we no longer rely on getting the CCW's global.
Right now consumers can't know when the parent process has finished talking
to the permission manager. It would be nice to enable consumers to depend
on the status of the asynchronous task using a promise.
Right now consumers can't know when the parent process has finished talking
to the permission manager. It would be nice to enable consumers to depend
on the status of the asynchronous task using a promise.
At the moment this isn't actually async because we immediately require
the pid and block on launch anyway. It also crashes the entire browser
on otherwise recoverable launch errors, because code that wants the pid
isn't set up to handle that operation failing.
MozReview-Commit-ID: 5favGu34QCv
--HG--
extra : rebase_source : 3c81c53e1eb8ead353ef3477ed3ceea0f5edcbbe
With the parent sending a snapshot of its preference state at content process
startup, we're guaranteed to have the full set of built-in preferences in the
shared map at initialization time, so there's no need to load them again.
This also applies to static preference default values, so we skip setting
those, as well.
However, we do need to make sure that we update static preference cache
entries whose default values don't match the value in the shared map, since
they may have been changed by user preference files. In order to deal with
that, we iterate over all preferences in the map, and dispatch callbacks for
any that have user values.
MozReview-Commit-ID: DlRUbg7Qor3
--HG--
extra : intermediate-source : 7f4cc96fae1212cb2220770ac7311b9cc51af744
extra : absorb_source : 7c71a5994c26c2a1e34b291947a49ac5b3d633cb
extra : source : dc7ec17179d1961d91b897cec9f409786363ec9e
extra : histedit_source : f7c7a935e72af65446c2abc502744a066a6e2ae5%2C5cd3235724af3e5f22b772de171cea735ec4c047
This adds an additional file descriptor to the set sent at content process
startup, for the read-only preference map that we share between all content
processes. This forms the base set of preferences. The other preferences FD
contains changes that the content process will need to apply on top of the
snapshot.
MozReview-Commit-ID: 6hc0HIxFmHg
--HG--
extra : intermediate-source : 46a6f9d0773ba2d756d8801cee79bfa994165d44
extra : absorb_source : a725a095946946797fd4f3abe6461e810b15d899
extra : source : e3bbc87b71af2f2ce1fa8bdf2cf26857c071ba5e
extra : histedit_source : 958212e804df7f9e1be6af182e73edc956b9a576
This is based on the SharedStringMap that's currently used for shared memory
string bundles.
When the parent process is ready to launch its first content process, it
creates a snapshot of the current state of the preference database, maps that
as read-only, and shares it with each content process. Look-ups in the
snapshotted map are done entirely using data in the shared memory region. It
doesn't require any additional per-process state data.
MozReview-Commit-ID: BdTUhak7dmS
--HG--
extra : intermediate-source : 434106f1b75e3ba900912f261bd22a1b7f5c931d
extra : absorb_source : 647ad37590448ad3c1eb8eb512bf671f262fa96e
extra : source : 68bb03c63b3cee1d47cbddfd3abf919f5783c04b
extra : histedit_source : 2228a9f8395929f5072a3c5ebda6ae3221e4a62d
With the parent sending a snapshot of its preference state at content process
startup, we're guaranteed to have the full set of built-in preferences in the
shared map at initialization time, so there's no need to load them again.
This also applies to static preference default values, so we skip setting
those, as well.
However, we do need to make sure that we update static preference cache
entries whose default values don't match the value in the shared map, since
they may have been changed by user preference files. In order to deal with
that, we iterate over all preferences in the map, and dispatch callbacks for
any that have user values.
MozReview-Commit-ID: DlRUbg7Qor3
--HG--
extra : source : dc7ec17179d1961d91b897cec9f409786363ec9e
extra : histedit_source : 285a99038c6731fed427cd8bc783b65f56e34ebb
This adds an additional file descriptor to the set sent at content process
startup, for the read-only preference map that we share between all content
processes. This forms the base set of preferences. The other preferences FD
contains changes that the content process will need to apply on top of the
snapshot.
MozReview-Commit-ID: 6hc0HIxFmHg
--HG--
extra : source : e3bbc87b71af2f2ce1fa8bdf2cf26857c071ba5e
extra : histedit_source : dc1c7c8015e0443eed218f826fda9f5b38b3e062%2C4cfa2f90104ca3e907607d884ac86f73ad4995bf
This is based on the SharedStringMap that's currently used for shared memory
string bundles.
When the parent process is ready to launch its first content process, it
creates a snapshot of the current state of the preference database, maps that
as read-only, and shares it with each content process. Look-ups in the
snapshotted map are done entirely using data in the shared memory region. It
doesn't require any additional per-process state data.
MozReview-Commit-ID: BdTUhak7dmS
--HG--
extra : source : 68bb03c63b3cee1d47cbddfd3abf919f5783c04b
LSBUtils closes a file descriptor twice, once with fclose and then again with
close. It also does this on a background thread, during startup, which means
it tends to race with main thread code which opens files.
This patch fixes that, and also removes a work-around for the issue in the
MemMapSnapshot code.
MozReview-Commit-ID: JdDHt9ayFEl
--HG--
extra : rebase_source : 2000ede41108d6312734d8df7db98272b33528fa
extra : amend_source : 1443a596fab3e3126a22d44787adaf5e12e4587c
With the parent sending a snapshot of its preference state at content process
startup, we're guaranteed to have the full set of built-in preferences in the
shared map at initialization time, so there's no need to load them again.
This also applies to static preference default values, so we skip setting
those, as well.
However, we do need to make sure that we update static preference cache
entries whose default values don't match the value in the shared map, since
they may have been changed by user preference files. In order to deal with
that, we iterate over all preferences in the map, and dispatch callbacks for
any that have user values.
MozReview-Commit-ID: DlRUbg7Qor3
--HG--
extra : rebase_source : 93cad19e27d3aaf5d4cad358cdebd6d80b76f668
extra : absorb_source : 06cb8911c92b66f8863b5e184d88b923cdbd6adc
Kris Maglione
Hiroyuki Ikezoe
Margareta Eliza Balazs
Brian Grinstead
Brian Hackett
Daniel Varga
Ting-Yu Lin
Alex Gaynor
Adrian Wielgosik
Cosmin Sabou
Gabriele Svelto
Kyle Machulis
Jan de Mooij
Noemi Erli
Dorel Luca
Coroiu Cristina
Boris Zbarsky
Csoregi Natalia
Kartikaya Gupta
Zibi Braniecki
Doug Thayer
Tarek Ziadé
Andreas Farre
Blake Kaplan
Dipen Patel
Andreea Pavel
Bogdan Tara
Ehsan Akhgari
Jed Davis
Haik Aftandilian
Gurzau Raul
Andrea Marchesini
Brindusan Cristian