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
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
--HG--
rename : testing/web-platform/tests/referrer-policy/generic/iframe-inheritance.html => testing/web-platform/tests/referrer-policy/generic/inheritance/iframe-inheritance-data.html
rename : testing/web-platform/tests/referrer-policy/generic/iframe-inheritance.html => testing/web-platform/tests/referrer-policy/generic/inheritance/iframe-inheritance-srcdoc.html
extra : moz-landing-system : lando
Right now there's some duplicated code with the focus manager and the
DOMWindowFocus event.
Android didn't handle the new framefocusrequested event, so the test-cases in
bug 416771 still didn't work there.
I think using the focus manager codepath everywhere is preferable. I confirmed
manually that the stuff that sent DOMWindowFocus events still works as expected
with this patch (i.e., switching to the right tab when you click on a
notification, etc.).
This fixes it so that it works in Fennec, and it sends the focus events right in
GeckoView Example (i.e., we get here[1] properly).
The snippet that Snorp provided on IRC to implement the "bring activity to
front" stuff (`startActivity(getIntent())`) didn't actually work for me, but I
confirmed that the right message is sent when the focus is requested, and that
we get there.
[1]: https://searchfox.org/mozilla-central/rev/952521e6164ddffa3f34bc8cfa5a81afc5b859c4/mobile/android/geckoview_example/src/main/java/org/mozilla/geckoview_example/GeckoViewActivity.java#503
Depends on D32353
Differential Revision: https://phabricator.services.mozilla.com/D32354
--HG--
extra : moz-landing-system : lando
The class contains original full referrer and referrer policy will be
applied to the referrer.
Differential Revision: https://phabricator.services.mozilla.com/D17923
--HG--
extra : moz-landing-system : lando
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.
We'll always need a URI for DocShellLoadState, and it should only
change is special circumstances. Construct the object with it, and
then follow up in Bug 1515433 for more cleanup.
Differential Revision: https://phabricator.services.mozilla.com/D13490
--HG--
extra : moz-landing-system : lando
By forcing our subject principal to be that of the service worker, we confuse
the permissions-checking code in the new process we create for
clients.openWindow. We need to tell the new process about the principal that's
doing work before it does any work.
Further principals (such as the principal for the loaded page) will be passed
down to the child via the various networking channels that we create for it.
Differential Revision: https://phabricator.services.mozilla.com/D14799
--HG--
extra : moz-landing-system : lando
By forcing our subject principal to be that of the service worker, we confuse
the permissions-checking code in the new process we create for
clients.openWindow. We need to tell the new process about the principal that's
doing work before it does any work.
Further principals (such as the principal for the loaded page) will be passed
down to the child via the various networking channels that we create for it.
Differential Revision: https://phabricator.services.mozilla.com/D14799
--HG--
extra : moz-landing-system : lando
The missing return would have caused an assertion if OpenWindow had failed as you can't reject a promise twice.
Differential Revision: https://phabricator.services.mozilla.com/D14030
--HG--
extra : moz-landing-system : lando
Make consistent use of MozPromise chaining where possible and remove unnecessary refcount.
Differential Revision: https://phabricator.services.mozilla.com/D14029
--HG--
extra : moz-landing-system : lando
- Expose FetchEvent.resultingClientId on non-subresource, non-"report"-destination requests.
- Delay Clients.get(FetchEvent.resultingClientId) resolution until the resulting client is execution ready.
- Add WPTs to test for existence of resultingClientId and Clients.get promise resolution values.
Differential Revision: https://phabricator.services.mozilla.com/D5333
--HG--
extra : moz-landing-system : lando
Kris Maglione
Perry Jiang
Andrea Marchesini
arthur.iakab
Sebastian Streich
Thomas Nguyen
Emilio Cobos Álvarez
Ehsan Akhgari
Christoph Kerschbaumer
Noemi Erli
Sylvestre Ledru
Dorel Luca
Cosmin Sabou
Csoregi Natalia
Narcis Beleuzu
Jan Varga
Alex Gaynor
Kyle Machulis
Blake Kaplan
Bogdan Tara
James Willcox
Jean-Yves Avenard
Gabriele Svelto
Perry Jiang