This patch changes a few things about how nsFrameLoader is created, specifically
around the ChangeRemoteness API.
1. The private 'nsFrameLoader::nsFrameLoader' constructor has been simplified to
only have one overload, shared by the different `::Create` static methods.
2. The creation static method used by `ChangeRemoteness` has changed name to
`::Recreate`, as the signature is becoming more like the old method.
3. The `mNetworkCreated` bit is preserved when doing a `ChangeRemoteness`, as a
remoteness change shouldn't be affecting that property.
4. Unused fields are removed from the ChangeRemoteness API.
5. The `remoteType` attribute is now mandatory in the ChangeRemoteness API,
which simplifies the logic and makes it harder to accidentally misuse.
Differential Revision: https://phabricator.services.mozilla.com/D44893
--HG--
extra : moz-landing-system : lando
Note that the areas are clipped out by all ancestor scroll ports and
their coordinate systems are the screen coordinate. So that we can tell
arbitrary elements in out-of-process iframes are scrolled out or not with
this area and the transform matrix of the iframe on screen coodinate.
Differential Revision: https://phabricator.services.mozilla.com/D44420
--HG--
extra : moz-landing-system : lando
The CommonCreateWindow code requires having a BrowserHost for the tab that's
creating the window, which it tries to get from the requestor's BrowserParent.
For remote BrowserParents, though, there is no BrowserHost, so we need to get
it from the top-level embedder instead.
Differential Revision: https://phabricator.services.mozilla.com/D45172
--HG--
extra : moz-landing-system : lando
The test originally assumed that the BrowsingContext for the crashing
frame would get destroyed and replaced with a new one. Having read through
some of bug 1563619 though, it looks as if we preserve the BrowsingContext
after the subframe crashes, so I've modified the test to skip that check.
It also looks like we have to wait until the WindowGlobalParent is created
asynchronously from the about:blank load that's initiated in the content
process before we can query the subframe for its current location, so
I've added a waitForCondition for that.
Differential Revision: https://phabricator.services.mozilla.com/D43814
--HG--
extra : moz-landing-system : lando
The test originally assumed that the BrowsingContext for the crashing
frame would get destroyed and replaced with a new one. Having read through
some of bug 1563619 though, it looks as if we preserve the BrowsingContext
after the subframe crashes, so I've modified the test to skip that check.
It also looks like we have to wait until the WindowGlobalParent is created
asynchronously from the about:blank load that's initiated in the content
process before we can query the subframe for its current location, so
I've added a waitForCondition for that.
Differential Revision: https://phabricator.services.mozilla.com/D43814
--HG--
extra : moz-landing-system : lando
This class allows to encapsulate all the information required in order to create a new HttpChannel object following a redirect.
Differential Revision: https://phabricator.services.mozilla.com/D40959
We currently handler this correctly for the opener stored on the outer window,
but not on the BrowsingContext.
Differential Revision: https://phabricator.services.mozilla.com/D43691
--HG--
extra : moz-landing-system : lando
Now that there is an {IPDL}ParamTraits implementation for nsIPrincipal* and
nsIContentSecurityPolicy*, we need not manually transform it to/from a
PrincipalInfo/CSPInfo ourselves.
Differential Revision: https://phabricator.services.mozilla.com/D36637
--HG--
extra : moz-landing-system : lando
The members of nsIWebProgressListener2 were added to BrowserChild (then
TabChild) in commit 1028814583232487b52b9c20d47e3b38dc1c288a, but the interface
was never added to the interface map.
Differential Revision: https://phabricator.services.mozilla.com/D35134
--HG--
extra : moz-landing-system : lando
This is the last message that WebProgressChild was sending to the
RemoteWebProgress in the parent process, so we can remove the module entirely.
Differential Revision: https://phabricator.services.mozilla.com/D35091
--HG--
extra : moz-landing-system : lando
Now that there is an {IPDL}ParamTraits implementation for nsIPrincipal* and
nsIContentSecurityPolicy*, we need not manually transform it to/form a
PrincipalInfo/CSPInfo ourselves.
Differential Revision: https://phabricator.services.mozilla.com/D36637
--HG--
extra : moz-landing-system : lando
The members of nsIWebProgressListener2 were added to BrowserChild (then
TabChild) in commit 1028814583232487b52b9c20d47e3b38dc1c288a, but the interface
was never added to the interface map.
Differential Revision: https://phabricator.services.mozilla.com/D35134
--HG--
extra : moz-landing-system : lando
This is the last message that WebProgressChild was sending to the
RemoteWebProgress in the parent process, so we can remove the module entirely.
Differential Revision: https://phabricator.services.mozilla.com/D35091
--HG--
extra : moz-landing-system : lando
Chrome flags need to be set both on the `window` and the `browser` object.
Right now we only set them on the `browser` objects and that could lead to
unintended consequences. This patch sets the flags to the `window` accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D43523
--HG--
extra : moz-landing-system : lando
Now that there is an {IPDL}ParamTraits implementation for nsIPrincipal* and
nsIContentSecurityPolicy*, we need not manually transform it to/form a
PrincipalInfo/CSPInfo ourselves.
Differential Revision: https://phabricator.services.mozilla.com/D36637
--HG--
extra : moz-landing-system : lando
The members of nsIWebProgressListener2 were added to BrowserChild (then
TabChild) in commit 1028814583232487b52b9c20d47e3b38dc1c288a, but the interface
was never added to the interface map.
Differential Revision: https://phabricator.services.mozilla.com/D35134
--HG--
extra : moz-landing-system : lando
This is the last message that WebProgressChild was sending to the
RemoteWebProgress in the parent process, so we can remove the module entirely.
Differential Revision: https://phabricator.services.mozilla.com/D35091
--HG--
extra : moz-landing-system : lando
ReferrerPolicy gets tossed back and forth as a uint32_t and
ReferrerPolicy enum in header file. Expose ReferrerPolicyValues from
webidl file and use consistently in native code.
Differential Revision: https://phabricator.services.mozilla.com/D41954
--HG--
extra : moz-landing-system : lando
The JSWindowActor constructor is called before the actor is fully initialized,
which means it can't do things like send messages or access its content
window. This patch adds a new callback which can do those things immediately
after the actor is created.
Differential Revision: https://phabricator.services.mozilla.com/D42178
--HG--
extra : rebase_source : ba17cacb00d8fc74f84c5d34f64addcc3e6d3f8b
extra : source : ac3da20c687971c412d1164f08b17e0cccc5fbd5
This patch also includes some spot fixes for the storage principal
support on the XUL browser element.
Differential Revision: https://phabricator.services.mozilla.com/D42203
--HG--
extra : moz-landing-system : lando
When contents notify IME or requests something to IME, they need to use
an `nsIWidget` instance which may have focus if active, and handles
native keyboard/IME events since that knows correct native IME context.
Currently, such widget exactly matches with the result of
`nsPresContext::GetRootWidget()`. However, this is unclear for most developers.
Therefore, this patch creates a wrapper method of it named
`nsPresContext::GetTextInputHandlingWidget()`. Then, also adds
`BrowserParent::GetTextInputHandlingWidget()` wraps it. Finally, makes
`IMEStateManager` call `GetTextInputHandlingWidget()` of them.
Differential Revision: https://phabricator.services.mozilla.com/D42301
--HG--
extra : moz-landing-system : lando
There was a strange bug when converting SharedStringMap to use shared
memory: on Android, some tests would fail because a pref wasn't set or
there was something wrong with an expected error message. The root
cause was that mapping ashmem with MAP_PRIVATE results in all zeroes
(see bug 1525803), but that was read as a valid SharedStringMap with
length 0.
To prevent any possible future issues like that, this patch adds a
nonzero magic number to the header. It fits into padding on 64-bit and
the cost of setting and checking it should be essentially free.
Depends on D26744
Differential Revision: https://phabricator.services.mozilla.com/D26745
--HG--
extra : moz-landing-system : lando
This will allow these heuristics to be used on mobile.
This depends on GeckoView supporting a JavaScript module
at resource:///modules/BrowserUsageTelemetry.jsm with the
interface described in nsIBrowserUsage.idl. Bug 1573238 has
been filed in order to implement this module on GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D41621
--HG--
extra : moz-landing-system : lando
This changes the way crash reports for child processes happening too early
during the child process' startup. Before bug 1547698 we wrote a partial
.extra file with those crashes that lacked the process type. The user would
not be notified of those crashes until she restarted Firefox and even when
submitted those crashes would be erroneously labeled as browser crashes.
After bug 1547698 we stopped writing .extra files entirely for those crashes
which left orphaned .dmp files among the pending crash reports.
This patch does three things to improve the situation:
* It writes a partial .extra file so that the crashes are detected at the next
startup. So the user is still not notified directly of these crashes but she
can report them later.
* It adds the process type to the .extra file so that the crash reporters are
labelled correctly.
* It fixes a leak in the `pidToMinidump` hash-map. Since the crashes were
not finalized the `ChildProcessData` strucutre associated with them would
never be fred.
Differential Revision: https://phabricator.services.mozilla.com/D40810
--HG--
extra : moz-landing-system : lando
This patch implements how to use MediaController to control corresponding media in content processes.
Differential Revision: https://phabricator.services.mozilla.com/D38145
--HG--
extra : moz-landing-system : lando
We implement some helpful functions in MediaControlUtils which can be used to notify controller when media starts/stops playing or become audible/inaudible.
For now, we can temporarily notify these changes in AudioChannelService where we have already known when media has these kinds of status changing.
Differential Revision: https://phabricator.services.mozilla.com/D38144
--HG--
extra : moz-landing-system : lando
Converts dom.ipc.processPriorityManager.backgroundPerceivableGracePeriodMS and dom.ipc.processPriorityManager.backgroundGracePeriodMS to static prefs and removes the initializer function they were in, as they were the last prefs initialized there.
Differential Revision: https://phabricator.services.mozilla.com/D40702
--HG--
extra : moz-landing-system : lando
Previously, the principal of the embedder would be used, which would mean a
document with the wrong principal would be created in the target process. By
using a null principal we can ensure that this initial document will be replaced
almost immediately.
In a follow-up, we should switch this to using the principal of the document to
be loaded to avoid unnecessary intermediate window globals.
Differential Revision: https://phabricator.services.mozilla.com/D41236
--HG--
extra : moz-landing-system : lando
This also renames the existing infallible nsDocShell:GetBrowsingContext()
getter to BrowsingContextRef(), and changes the return type, since several
callers rely on it returning a raw pointer rather than an already_AddRefed.
Differential Revision: https://phabricator.services.mozilla.com/D40312
--HG--
extra : moz-landing-system : lando
This patch implements how to use MediaController to control corresponding media in content processes.
Differential Revision: https://phabricator.services.mozilla.com/D38145
--HG--
extra : moz-landing-system : lando
We implement some helpful functions in MediaControlUtils which can be used to notify controller when media starts/stops playing or become audible/inaudible.
For now, we can temporarily notify these changes in AudioChannelService where we have already known when media has these kinds of status changing.
Differential Revision: https://phabricator.services.mozilla.com/D38144
--HG--
extra : moz-landing-system : lando
Currently, TabGroups know to break their reference cycles only when the last
window leaves them. For TabGroups which have never had a window join (which
happens under Fission), this means they also never see a window leave, and
therefore never break their reference cycles, and leak.
This patch adds a check to break reference cycles if no windows have joined by
the time a BrowserChild they belong to is destroyed.
MANUAL PUSH: Lando fails to rebase.
Differential Revision: https://phabricator.services.mozilla.com/D40669
--HG--
extra : source : 03acb28ab60fb77fa06064385a62cc46cf4ad1bd
extra : amend_source : 0a71625d99951bebe45ee6f62570de491a714e97
The database is accessible from the parent process due to to the sandbox thus it is required an IPDL protocol that will transfer the queries and the results
Differential Revision: https://phabricator.services.mozilla.com/D38313
--HG--
extra : moz-landing-system : lando
This patch implements how to use MediaController to control corresponding media in content processes.
Differential Revision: https://phabricator.services.mozilla.com/D38145
--HG--
extra : moz-landing-system : lando
We implement some helpful functions in MediaControlUtils which can be used to notify controller when media starts/stops playing or become audible/inaudible.
For now, we can temporarily notify these changes in AudioChannelService where we have already known when media has these kinds of status changing.
Differential Revision: https://phabricator.services.mozilla.com/D38144
--HG--
extra : moz-landing-system : lando
There are some unfortunate aspects of openWindow() and openWindow2() that make
this difficult. Namely, they sometimes return top-level chrome windows, and
sometimes a single content window from the top-level chrome window that they
open, depending on how they're called.
There really isn't any reason to return a BrowsingContext rather than a chrome
window in the former case, but there also really isn't a way to make the API
polymorphic in a way that would allow handling the two cases differently. So
at some point, the two cases should ideally be split into separate APIs rather
than separate special cases of a single API.
In the mean time, I've left openWindow() returning local mozIDOMWindowProxy
objects, since it isn't used by the DOM window.open() or openDialog() APIs,
and only updated openWindow2(). As a follow-up, we should remove both
openWindow() and openWindow2(), and replace them with openChromeWindow() and
openContentWindow() (or similar) methods which make it immediately clear what
type of window is being returned.
Differential Revision: https://phabricator.services.mozilla.com/D35689
--HG--
extra : moz-landing-system : lando
This is the first step in making it possible to return remote WindowProxy
objects from window.open() and related APIs.
This patch also incidentally fixes a bug where getContentWindowOrOpenURI
returned the top-level browser window rather than the new content window when
passed OPEN_NEWWINDOW for the `aWhere` parameter. This was not the expected
behavior, and was a potentially major footgun for any new users who expected
to always get the content window for the URL they were loading, rather than
sometimes getting a chrome browser window instead.
For now, that case just returns null, which is only a minor footgun, rather
than the major one we had before.
Differential Revision: https://phabricator.services.mozilla.com/D35688
--HG--
extra : moz-landing-system : lando
So that paint doesn't reenter on layout, or mess with incomplete frame trees, or
what not.
I just early-returned rather than only skipping the PaintWhileInterruptingJS
call because I don't think we should be running untrusted scripts in the first
place when IsSafeToRunScript() is false.
Differential Revision: https://phabricator.services.mozilla.com/D39913
--HG--
extra : moz-landing-system : lando
Ensure that IsFormSubmission is set in all constructors and can be serialized
Differential Revision: https://phabricator.services.mozilla.com/D39935
--HG--
extra : moz-landing-system : lando
This asserts that the embedder is always set soon enough that we don't run into
the situation which caused the null deref fixed by bug 1565489.
Differential Revision: https://phabricator.services.mozilla.com/D39187
--HG--
extra : moz-landing-system : lando
This is an example refcounted actor which was easy enough to port over as an
initial test. More can be ported in the future, potentially alongside removing
`mIPCOpen`.
Differential Revision: https://phabricator.services.mozilla.com/D39503
--HG--
extra : moz-landing-system : lando
This functionality is currently unused, and blocks work needed to support
Fission.
Differential Revision: https://phabricator.services.mozilla.com/D39542
--HG--
extra : rebase_source : 1d8fdea73d48c714112d13844f5110f7f1892dda
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
The work from bug 1510569 that has ported the majority of the `nsIWebProgress`
event handlers from `WebProgressChild`/`RemoteWebProgress` to
`BrowserChild`/`BrowserParent` was not properly propogating the events in the
responsive design mode case. The `BrowserParent` assumed that its frame element
was an `nsIBrowser`, but in RDM it is an `<iframe mozbrowser>` which does not
implement `nsIBrowser`. In the RDM case we now walk up the document in the
`BrowserParent` tree to find the `<xul:browser>` and call the event handlers on
that instead.
Differential Revision: https://phabricator.services.mozilla.com/D38916
--HG--
extra : moz-landing-system : lando
This should help ensure that the embedder is always set soon enough that we
don't run into the situation which caused the null deref fixed by bug 1565489.
This patch also adds an assertion earlier in WindowGlobalParent's lifecycle to
ensure that the condition is satisfied. This assertion will fail before the
changes in part 1.
Differential Revision: https://phabricator.services.mozilla.com/D38723
--HG--
extra : moz-landing-system : lando
The crash appears to be being caused by the GetEmbedderWindowGlobal call
returning a null value. This patch simply avoids the crash in this case, and
returns a reasonable default value of false, as it should never be true for a
BrowsingContext with a parent without Fission enabled.
This patch should be small enough to safely uplift if necessary.
Differential Revision: https://phabricator.services.mozilla.com/D38722
--HG--
extra : moz-landing-system : lando
This also adds an extra assertion against browsing context mismatches that
happen when we don't get this right.
Differential Revision: https://phabricator.services.mozilla.com/D36852
--HG--
extra : source : 4b07deb4cd2ef4c98b6d6ee961a20705f4f2deae
My preference was to annotate most of the failing tests with `fail-if` so that
if they start passing, the `fail-if` needs to be removed and they need to keep
passing. That doesn't work for tests that timeout, or which trigger failures
from their cleanup functions, however, so those tests need skip-if. And tests
with fail in their cleanup functions likely leave the browser in an
inconsistent state for subsequent tests, anyway, so really should be skipped
regardless.
There are some remaining tests which still fail because of crashes. I chose
not to skip them here, but to fix the crashes in separate bugs instead.
Differential Revision: https://phabricator.services.mozilla.com/D38247
--HG--
extra : rebase_source : 39ba8fec2e882cfe577c5f2b58ab7e4b461f1178
We can remove references held in the ContentChild and the ContentParent once the BrowsingContextGroup becomes empty.
This allows to break the cycles and the BrowsingContextGroup to be deleted.
Differential Revision: https://phabricator.services.mozilla.com/D38180
--HG--
extra : moz-landing-system : lando
The ipc::browser-destroyed message must be sent when a top-level remote browser is destroyed.
Currently this is done by BrowserParent::ActoryDestroy and relies on having access to
mBrowserHost. This can break if we start clearing out this pointer. This commit moves
the trigger to fire in BrowserHost::DestroyComplete. Semantically this is different,
but from the users of this observer, I don't see any risk.
Differential Revision: https://phabricator.services.mozilla.com/D37171
--HG--
extra : rebase_source : c863fb8d8a3a540d3dec42472c71342bed8ba541
extra : amend_source : aae3d054d453e63c10fec8707c8cda0497580a87
This ensures that the object is not discarded while there are still in-flight
messages from the parent process, and vice-versa, which could cause crashes if a
CC was run before any pending messages have arrived.
Differential Revision: https://phabricator.services.mozilla.com/D36995
--HG--
extra : moz-landing-system : lando
Having to namespace these into GeckoChildProcessHost is annoying. The
|using| declarations help to some extent, but it's easier to just put
them in mozilla::ipc.
Differential Revision: https://phabricator.services.mozilla.com/D36538
--HG--
extra : moz-landing-system : lando
Depending on the timing of events, we can invoke InitInternal after
we've already torn down the compositor thread, which can make
CreateContentBridges fail, which in turn makes us unable to make a
correct InitRendering call. Implement the infrastructure to bail out in
this case.
Differential Revision: https://phabricator.services.mozilla.com/D36644
--HG--
extra : moz-landing-system : lando
In the bug which introduced mIsDiscarded, the code was changed to not set
mClosed during Detach, and only set mIsDiscarded. This was a mistake because a
bunch of places are only reading mClosed. Specifically when creating a
BrowsingContext for an iframe, we check GetClosed() to see whether to skip
creating it. Not doing this check can lead to assertions like the one in this
bug.
This patch changes the behaviour to continue setting `mClosed`, and also updates
the relevant `GetClosed()` checks to correctly check `IsDiscarded()`
Differential Revision: https://phabricator.services.mozilla.com/D37267
--HG--
extra : moz-landing-system : lando
To avoid populating the clipboard cache,
`nsContentUtils::IPCTransferableToTransferable` should set the
IsPrivateData flag on the output transferable BEFORE assigning data to
it, not therafter.
This patch includes a new regression test for this specific scenario.
The patch also includes fixes for incorrect IsPrivateData flags in some
other locations with `transferable->Init(nullptr)`, but without unit
tests.
Differential Revision: https://phabricator.services.mozilla.com/D36440
--HG--
extra : moz-landing-system : lando
When Fission is enabled, the load will be retargeted to the correct process
automatically, and will in the mean time give callers access to an about:blank
document as required by the spec.
Differential Revision: https://phabricator.services.mozilla.com/D36242
--HG--
extra : rebase_source : a0b1643d0aaaf4ffd2dd75e159543e475f3df24b
extra : source : 72630a7c6e6742388107a77afc26c9c191722705
Apparently the GetChromeOffset() in BrowserChild becomes stale after exiting
fullscreen, but it's not clear to me what is supposed to keep it updated. So
this patch adds a fullscreenchange event listener that updates it. If we
encounter other scenarios where this happens maybe we can find a better way
to do this but without more knowledge of the scenarios this is the best option
I have.
Differential Revision: https://phabricator.services.mozilla.com/D36080
--HG--
extra : moz-landing-system : lando
There are a couple of places where JSWindowActor currently sends uninitialized
StructuredCloneData objects in places where it wants the message data to be
undefined. The problem with this is that it causes an error when trying to
read the data, which leads to odd behavior like `sendQuery` promises never
being settled if the message handler throws, or `sendAsyncMessage` and
`sendQuery` failing to decode the message if the caller doesn't pass a second
argument.
The errors reported for these problems also have no context, which means it's
very hard for a developer to figure out the source of the problem. And, to
make matters worse, the errors look the same as structured clone encoding
errors, so there isn't even the clue that the error is happening on decode.
This patch updates the offending code to always explicitly initialize the
structured clone data with `undefined` when that's what it wants, and adds
assertions to make it more obvious where the decode errors are actually
happening.
Differential Revision: https://phabricator.services.mozilla.com/D35052
--HG--
extra : rebase_source : dd4720d63cd0722a554524e65d16e31b702adbf3
extra : source : 158a4000c44b9b17a7935340db79431d544fb556
The current JSWindowActor code assumes that all actors will be created in the
shared JSM global. This has a few problems:
1) For actors in other scopes, it enters the wrong compartment before decoding
messages, which leads to a compartment checker error when trying to call
message handlers. That could be fixed by just wrapping the result for the
caller, but that would lead to other problems. Aside from the efficiency
concerns of having to deal with cross-compartment wrappers, SpecialPowers in
particular would not be able to pass the resulting objects to unprivileged
scopes, since only SpecialPowers compartments have permissive CCWs enabled.
2) It also leads to the prototype objects for the actor instances being
created in the shared JSM scope, even when the actors themselves are defined
in other compartments. Again, aside from CCW efficiency issues, this prevents
the SpecialPowers instances from being accessed by the unprivileged scopes
that they're exposed to, since the prototype objects live in privileged scopes
which don't have permissive CCWs enabled.
This patch changes child actors to always create their objects in the global
of their constructors.
The parent objects are still created in the shared JSM global, but they now
wrap values for the appropriate compartment before trying to call message
handlers.
Differential Revision: https://phabricator.services.mozilla.com/D35051
--HG--
extra : rebase_source : 436ce516080812680d1433bf3ecbd12f91d88165
extra : source : 61fa2745733f3631488a3ecccc144823683b7b6d
With Fission enabled, remote types can have the form
webIsolated=<URI>. This is bad, because we store them in telemetry in
some places. This patch adds and uses a method that sanitizes remote
types.
Differential Revision: https://phabricator.services.mozilla.com/D36068
--HG--
extra : moz-landing-system : lando