Currently, when JS callers try to access certain JSWindowActors before an
actor is initialized, or after it's destroyed, we throw a generic
`NS_ERROR_INVALID_STATE_ERROR` exception without any useful information about
the failure.
This patch changes that to use `ThrowInvalidStateError`, with a message
including the property name, the actor name, and details about whether the
error occurred because the actor has not been initialized or because it has
already been destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D96628
To force navigation to block on the long running script it needs to be
loading a page on the same domain as the blocking script, otherwise
fission and Session history in the parent will happily change
remoteness to another process and load immediately.
Depends on D90825
Differential Revision: https://phabricator.services.mozilla.com/D90826
There must be no pending exceptions on the JSContext when returning from a
native promise handler. We were not successfully clearing exceptions in all
cases in JSActor logic, meaning that query replies with unserializable data
would cause debug-mode crashes.
This patch handles JSActor's code, but doesn't improve the situation for other
native promise handlers which could throw exceptions.
Differential Revision: https://phabricator.services.mozilla.com/D87110
It's possible to end up in a situation where the window global has been set on
the BrowsingContext, but hasn't yet been initialized. Proceeding at this point
results in the document having a stale URI (about:blank in this case). Waiting
for a "window-global-created" instead should ensure that everything has been
initialized before we proceed.
Differential Revision: https://phabricator.services.mozilla.com/D86764
This is similar to JSWindowActor's includeChrome option, and defaults to
'false'. If users want to also instantiate the actor in-process, they can set
this option to 'true'.
Differential Revision: https://phabricator.services.mozilla.com/D82449
This switches the `nsIContent{Parent,Child}` interface to be
`nsIDOMProcess{Parent,Child}`, and also implements it on
`InProcess{Parent,Child}`, along with the `ProcessActor` interface.
Differential Revision: https://phabricator.services.mozilla.com/D80582
This switches the `nsIContent{Parent,Child}` interface to be
`nsIDOMProcess{Parent,Child}`, and also implements it on
`InProcess{Parent,Child}`, along with the `ProcessActor` interface.
Differential Revision: https://phabricator.services.mozilla.com/D80582
CLOSED TREE
Backed out changeset 8c4a24b91c88 (bug 1646088)
Backed out changeset ef746bdcbaf6 (bug 1646088)
Backed out changeset 77d15266af3c (bug 1646088)
I think at this point we can remove all of RemoteWebProgressManager, some/all of the TabProgressListener recreations, and probably a bunch more.
Differential Revision: https://phabricator.services.mozilla.com/D79240
I think at this point we can remove all of RemoteWebProgressManager, some/all of the TabProgressListener recreations, and probably a bunch more.
Differential Revision: https://phabricator.services.mozilla.com/D79240
I think at this point we can remove all of RemoteWebProgressManager, some/all of the TabProgressListener recreations, and probably a bunch more.
Differential Revision: https://phabricator.services.mozilla.com/D79240
The 'asyncStack' flag on JS execution contexts is used as a general switch
to enable async stack capture across all locations in SpiderMonkey, but
this causes problems because it can at times be too much of a performance
burden to general and track all of these stacks.
Since the introduction of this option, we have only enabled it on Nightly
and DevEdition for non-mobile builds, which has left a lot of users unable
to take advantage of this data while debugging.
This patch enables async stack traces across all of Firefox, but introduces
a new pref to toggle the scope of the actual expensive part of async stacks,
which is _capturing_ them and keeping them alive in memory. The new pref
limits the capturing of async stack traces to only debuggees, unless an
explicit pref is flipped to capture async traces for all cases.
This means that while async stacks are technically enabled, and code could
manually capture a stack and pass it back to SpiderMonkey and see that stack
reflected in later captured stacks, SpiderMonkey itself and related async
DOM APIs, among others, will not capture stacks or pass them to SpiderMonkey,
so there should be no general change in performance by enabling the broader
feature itself, unless the user is actively debugging the page.
One effect of this patch is that if you have the debugger open and then close
it, objects that have async stacks associated with them will retain those
stacks and they will continue to show up in stack traces, no _new_ stacks
will be captured. jorendorff and I have decided that this is okay because
the expectation that the debugger fully revert every possible effect that it
could have on a page is a nice goal but not a strict requirement.
Differential Revision: https://phabricator.services.mozilla.com/D68503
These tests used <iframe mozbrowser> for convenience, mostly forcing
themselves to only run in non-e10s mode in the process, but none of them
really have any need to.
Differential Revision: https://phabricator.services.mozilla.com/D70745
These tests used <iframe mozbrowser> for convenience, mostly forcing
themselves to only run in non-e10s mode in the process, but none of them
really have any need to.
Differential Revision: https://phabricator.services.mozilla.com/D70745
These tests used <iframe mozbrowser> for convenience, mostly forcing
themselves to only run in non-e10s mode in the process, but none of them
really have any need to.
Differential Revision: https://phabricator.services.mozilla.com/D70745
This was generated with
```
cp .gitignore .rgignore
rg -l -g '*.{html,xhtml}' 'href="chrome://global/skin/"' | xargs sed -i "" 's/href\="chrome:\/\/global\/skin\/"/href\="chrome:\/\/global\/skin\/global.css"/g'
```
Differential Revision: https://phabricator.services.mozilla.com/D67687
--HG--
extra : moz-landing-system : lando
Previously, the PWindowGlobal actor was managed by the PBrowser which hosted it,
however this could cause issues when the tab containing the PWindowGlobal was
being destroyed. Due to the slightly different lifecycles of the PBrowser actor
and the nsGlobalWindowInner which the PWindowGlobal was trying to match the
lifetime of, the actor would sometimes not fire 'willDestroy' events correctly.
This patch moves PWindowGlobal to be directly managed by PContent, and changes
logic which previously used `Manager()` to get `Browser{Parent,Child}` to
instead use a pointer member.
Differential Revision: https://phabricator.services.mozilla.com/D68596
--HG--
extra : moz-landing-system : lando
Previously, the PWindowGlobal actor was managed by the PBrowser which hosted it,
however this could cause issues when the tab containing the PWindowGlobal was
being destroyed. Due to the slightly different lifecycles of the PBrowser actor
and the nsGlobalWindowInner which the PWindowGlobal was trying to match the
lifetime of, the actor would sometimes not fire 'willDestroy' events correctly.
This patch moves PWindowGlobal to be directly managed by PContent, and changes
logic which previously used `Manager()` to get `Browser{Parent,Child}` to
instead use a pointer member.
Differential Revision: https://phabricator.services.mozilla.com/D68596
--HG--
extra : moz-landing-system : lando
After bug 1582832, DocShell destruction and BrowsingContext detaching happen
in separate operations, leaving a gap where a DocShell has been destroyed, but
its BrowsingContext is still considered attached. During this gap, the usual
invariant that an in-process, attached BrowsingContext always has an
associated DOM window doesn't hold, nor do the usual invariants for outer
window forwarding security checks.
This patch fixes the detach timing so that a child BrowsingContext for a frame
which has been removed is always marked detached at the same time its DocShell
is destroyed.
Co-authored-by: Kris Maglione <maglione.k@gmail.com>
Differential Revision: https://phabricator.services.mozilla.com/D62791
--HG--
extra : moz-landing-system : lando
There are all sorts of lifecycle issues which arise from making DocShell
responsible for discarding BrowsingContexts. In this particular bug, we tend
to run into them in cases where we create a BrowsingContext for a FrameLoader,
and then never create a DocShell for it, leading to it never being destroyed.
But there are myriad other issues as well.
This patch moves the responsibility for BrowsingContext lifecycle management
to the FrameLoader/FrameLoaderOwner, rather than the DocShell, which makes
things more consistent, and more closely aligns with spec-defined behavior.
Differential Revision: https://phabricator.services.mozilla.com/D59008
--HG--
extra : moz-landing-system : lando
Noemi Erli
Emilio Cobos Álvarez
Kris Maglione
Neil Deakin
alwu
Csoregi Natalia
Andreas Farre
Nika Layzell
Kashav Madan
Joel Maher
Butkovits Atila
Matt Woodrow
Cosmin Sabou
Dorel Luca
Narcis Beleuzu
Mihai Alexandru Michis
Razvan Maries
Bogdan Tara
Logan Smyth
Olli Pettay
David Teller
Stefan Hindli
Coroiu Cristina
Andreea Pavel
Ciure Andrei
Daniel Varga
Brian Grinstead
Mike Conley
Arthur Iakab
Mark Banner
Oana Pop Rus
Julian Descottes