Also some minor cleanup in nsWindowWatcher, as well as a small fix,
where GetWindowByName forgot to addref its return value (as changed in
Part 1).
Differential Revision: https://phabricator.services.mozilla.com/D48976
Also some minor cleanup in nsWindowWatcher, as well as a small fix,
where GetWindowByName forgot to addref its return value (as changed in
Part 1).
Differential Revision: https://phabricator.services.mozilla.com/D48976
The (non-normative) window.open spec does not specify what should happen when
window.open is called on a window with a null/discarded browsing context, but
in general the lookup and creation rules do not make sense when the window has
no BC. It does, however, specify that we should return null when a target BC
cannot be found or created, and gives us broad discretion over when we decide
to ignore a load request and return null. Since we can't trigger a
cross-process load from a discarded BC, simply aborting in that case seems
like the logical solution.
For Location objects, the spec is more specific, and requires that we ignore
load attempts on Location objects whose documents are null, which in our
implementation corresponds to a discarded BrowsingContext.
LocationBase::SetURI already enforces this, but a second check in
BrowsingContext::LoadURI is probably a good idea as well.
Differential Revision: https://phabricator.services.mozilla.com/D45635
This allows us to actually correctly load URIs into and return BCs for
cross-process named targets. It still leaves a lot of code which needs to
operate directly on DocShells, but it only applies to new windows, which
always start out same-process.
The one exception is the logic to change the opener of an existing
cross-process window targeted by an open() operation, which can't currently be
accomplished outside of the BC's owner process. This will need a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D40501
This check always has access to an in-process DocShell which is attempting to
perform a load, but its target may often be cross-process, and have no
in-process DocShell. This patch changes the target checks to use a
BrowsingContext in a Fission-compatible way.
Differential Revision: https://phabricator.services.mozilla.com/D40496
We need to be able to check the one-permitted-sandboxed-navigator from
potentially-cross-process access checks in DocShell, which means it needs to
live on BrowsingContext rather than DocShell.
Differential Revision: https://phabricator.services.mozilla.com/D40495
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
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
Also, in many place, we use document uri as referrer. It is not right
for the case srdoc iframe. We should use the last non-srdoc parent
document's uri
Differential Revision: https://phabricator.services.mozilla.com/D30191
