Also adds a legacy `GetSameProcessOpener()` method for callers which can only
deal with in-process windows and may need to be updated for Fission.
Differential Revision: https://phabricator.services.mozilla.com/D43692
--HG--
extra : source : 0ddbc451dcab431c2a1d934fa9baa5e8efc71545
This is currently only available on the outer window, but needs to move to
BrowsingContext in order from us to remove redundant opener tracking from the
former.
Differential Revision: https://phabricator.services.mozilla.com/D43690
--HG--
extra : source : be7cbc61f825fdfc36b20d476bef710ef275ad73
Also adds a legacy `GetSameProcessOpener()` method for callers which can only
deal with in-process windows and may need to be updated for Fission.
Differential Revision: https://phabricator.services.mozilla.com/D43692
--HG--
extra : moz-landing-system : lando
This is currently only available on the outer window, but needs to move to
BrowsingContext in order from us to remove redundant opener tracking from the
former.
Differential Revision: https://phabricator.services.mozilla.com/D43690
--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
When a BrowsingContext changes from being local to remote, we have to
change all window proxies from being local to remote, using
transplanting. The actual window proxy becomes a remote window
proxy. Cross compartment wrappers (CCWs) to the window proxy also
become remote window proxies in their respective compartments, rather
than CCWs to a remote proxy in the old compartment of the window
proxy, because the window is no longer actually in that
compartment. This also avoids having to figure out what Xray behavior
for remote window proxies should be.
This patch uses the transplanting support I added to
GetRemoteOuterWindowProxy() in the previous patch to ensure that the
remote proxy map holds the correct value after transplanting finishes.
It drops the requirement that both arguments to JS_TransplantObject
have the same class, because we need to transplant a window proxy with
a remote window proxy. It also deals with this by not adding origobj
to the wrapper map unless it is a CCW, to handle transplanting to a
remote proxy.
The core design here, with the remote window proxies in every
compartment, is taken from a patch by peterv.
Differential Revision: https://phabricator.services.mozilla.com/D35730
--HG--
extra : moz-landing-system : lando
When a BrowsingContext changes from being local to remote, we have to
change all window proxies from being local to remote, using
transplanting. The actual window proxy becomes a remote window
proxy. Cross compartment wrappers (CCWs) to the window proxy also
become remote window proxies in their respective compartments, rather
than CCWs to a remote proxy in the old compartment of the window
proxy, because the window is no longer actually in that
compartment. This also avoids having to figure out what Xray behavior
for remote window proxies should be.
This patch uses the transplanting support I added to
GetRemoteOuterWindowProxy() in the previous patch to ensure that the
remote proxy map holds the correct value after transplanting finishes.
It drops the requirement that both arguments to JS_TransplantObject
have the same class, because we need to transplant a window proxy with
a remote window proxy. It also deals with this by not adding origobj
to the wrapper map unless it is a CCW, to handle transplanting to a
remote proxy.
The core design here, with the remote window proxies in every
compartment, is taken from a patch by peterv.
Differential Revision: https://phabricator.services.mozilla.com/D35730
--HG--
extra : moz-landing-system : lando
This patch adds the ability to load cross domain iframes in the
background to make the top level documents finish earlier.
This is an experiment feature that we'll keep it disabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D24938
--HG--
extra : moz-landing-system : lando
It's only moved around, but not actually used anywhere.
I have no idea what this was supposed to control in the past but it doesn't seem
useful to keep it around.
Differential Revision: https://phabricator.services.mozilla.com/D33393
--HG--
extra : moz-landing-system : lando
Marking GetGlobalJSObject and GetGlobalJSObjectPreserveColor final and inline
on inner/outer windows allows compilers to de-virtualize and inline them, which
makes them just as fast as calling FastGetGlobalJSObject is now (in the case of
GetGlobalJSObjectPreserveColor; GetGlobalJSObject has to do the gray-unmarking,
which is a bit more work).
In WindowDestroyedEvent::Run we want to switch to GetGlobalJSObject(), because
we want to root the object and hence should unmark gray.
In nsGlobalWindowInner::RunTimeoutHandler we likewise want to unmark gray. The
AutoEntryScript constructor likely did that already, but it's not that
expensive when it doesn't need to do any work.
Differential Revision: https://phabricator.services.mozilla.com/D29711
--HG--
extra : moz-landing-system : lando
This can be used in things like assertions or some other rare circumstances
where not exposing the object to active JS is OK.
Differential Revision: https://phabricator.services.mozilla.com/D29704
--HG--
extra : moz-landing-system : lando
Similarly to nsITabParent, TabChild is exposed to frontend code via nsITabChild. It's not clear what the future of this interface will be, but for now we can just rename it to nsIBrowserChild.
Differential Revision: https://phabricator.services.mozilla.com/D28134
--HG--
rename : dom/interfaces/base/nsITabChild.idl => dom/interfaces/base/nsIBrowserChild.idl
extra : rebase_source : a6c42a661e35b19e46c60f6f6a6f3dab64c0a1bc
extra : histedit_source : 1eb475bd840bf37a3f86294685c9b3c250684e79
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
Kris Maglione
Ehsan Akhgari
Tom Tung
Mihai Alexandru Michis
Brad Werth
Jon Coppeard
Nika Layzell
Kannan Vijayan
Ciure Andrei
Andrew McCreight
Noemi Erli
Bogdan Tara
Sylvestre Ledru
Sean Feng
Emilio Cobos Álvarez
arthur.iakab
Christoph Kerschbaumer
Masayuki Nakano
Liang-Heng Chen
Boris Zbarsky
Ryan Hunt
Andrea Marchesini
Cosmin Sabou
Peter Van der Beken