Although many Clients API usages are inherently exclusive (a specific claim
or control request), the execution-ready promise is shared by all requests
to get the state of a client that is not yet execution ready.
Differential Revision: https://phabricator.services.mozilla.com/D49976
--HG--
extra : moz-landing-system : lando
We fail navigation-redirect.https.html?client without this (with the subtest to redirects to a cross-origin page and then redirects back again to a same-origin page). In this case the ClientChannelHelper running in the child only sees a same-origin redirect (the first URL to the final one), but we've still allocated a new ClientInfo in the parent and we want to create the corresponding ClientSource.
Differential Revision: https://phabricator.services.mozilla.com/D49870
--HG--
extra : moz-landing-system : lando
Although many Clients API usages are inherently exclusive (a specific claim
or control request), the execution-ready promise is shared by all requests
to get the state of a client that is not yet execution ready.
Differential Revision: https://phabricator.services.mozilla.com/D49976
--HG--
extra : moz-landing-system : lando
We fail navigation-redirect.https.html?client without this (with the subtest to redirects to a cross-origin page and then redirects back again to a same-origin page). In this case the ClientChannelHelper running in the child only sees a same-origin redirect (the first URL to the final one), but we've still allocated a new ClientInfo in the parent and we want to create the corresponding ClientSource.
Differential Revision: https://phabricator.services.mozilla.com/D49870
--HG--
extra : moz-landing-system : lando
This does many things:
1) stops producing (and consuming) `FennecJNI*` JNI wrappers
2) removes the :app and :thirdparty Gradle projects
3) removes relevant pieces of the Gradle target configuration
4) updates lints
5) purges old configurations
After this commit, the `mobile/android` project/application builds
only GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D46536
--HG--
extra : moz-landing-system : lando
This patch introduces the concept of a "future ClientSource" to the
ClientManagerService. A "future ClientSource" is registered/removed
from the ClientManagerService by
ClientManager::{Register,Forget}FutureClientSource and is required
when a ClientInfo is initially created without a backing ClientSource.
As a result, the ClientManagerService can distinguish between a
ClientSourceParent* that has yet to register itself with the
ClientManagerService and a ClientSourceParent* that has already
both registered and removed itself from the ClientManagerService.
Differential Revision: https://phabricator.services.mozilla.com/D47592
--HG--
extra : moz-landing-system : lando
NS_ERROR_DOM_TYPE_ERR is not much better, but this at least allows us to get
rid of NS_ERROR_TYPE_ERR completely...
Differential Revision: https://phabricator.services.mozilla.com/D46485
--HG--
extra : moz-landing-system : lando
Adds a ServiceWorkerDelegate to GeckoRuntime that allows GeckoView applications
to handle ServiceWorkerClient.openWindow() requests.
Differential Revision: https://phabricator.services.mozilla.com/D45572
--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
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
