Waiting for docshells and frameloaders to destroy will leave attached
browsing contexts attached too long. In case the children of a
browsing contexts cannot be cached we want to detach all of them as
soon as possible.
Also normalizes the use of BrowsingContext::mGroup.
Differential Revision: https://phabricator.services.mozilla.com/D33602
--HG--
extra : moz-landing-system : lando
Waiting for docshells and frameloaders to destroy will leave attached
browsing contexts attached too long. In case the children of a
browsing contexts cannot be cached we want to detach all of them as
soon as possible.
Also normalizes the use of BrowsingContext::mGroup.
Differential Revision: https://phabricator.services.mozilla.com/D33602
--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
This ensures that links in about:license to about:rights and about:buildconfig actually work.
Differential Revision: https://phabricator.services.mozilla.com/D34136
--HG--
extra : moz-landing-system : lando
This is sorta-part of the work for bug 1510760. Currently if you do a process
switch, the window proxy state is completely borked, and a lot of stuff doesn't
work.
This patch aims to make it so that, while not transplanted correctly, methods
generally don't return the wrong WindowProxy object anymore after a process
swap.
Differential Revision: https://phabricator.services.mozilla.com/D33082
--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
This patch makes several changes to the kinds of URLs where we can cancel
content JS when navigating between them:
1) When navigating directly to a URL (e.g. by typing something into the
location bar and hitting Enter), we allow canceling content JS if the URLs
differ in any way *except* their ref ("#"). To help with this, we also
attempt to fix up the URL (e.g. by prepending "http://" to it).
2) When navigating through history, we allow canceling content JS if the
`prePath` part of the URLs differ. Most notably, this allows canceling
content JS when one of the URLs is an `about:` page (e.g. when hitting the
Home button).
3) We explicitly disallow cancelling content JS if the currently-running JS
is trusted or if the page being navigated away from is anything but
http(s): or file:.
4) We also disallow cancelling content JS for windows that are still being
created (e.g. when creating a new tab or window via `window.open`). For
more background on this, see the comments about `mCreatingWindow` in
dom/ipc/BrowserParent.h.
5) We ensure that, when attempting to cancel JS, the tab ID of the
currently-running script matches the original tab that requested the
cancellation. This avoids a race condition in which a particular JSContext
has already moved on to executing another tab's JS by the time we hit our
interrupt callback.
Differential Revision: https://phabricator.services.mozilla.com/D31875
--HG--
extra : moz-landing-system : lando
This is sorta-part of the work for bug 1510760. Currently if you do a process
switch, the window proxy state is completely borked, and a lot of stuff doesn't
work.
This patch aims to make it so that, while not transplanted correctly, methods
generally don't return the wrong WindowProxy object anymore after a process
swap.
Differential Revision: https://phabricator.services.mozilla.com/D33082
--HG--
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
These are generally:
- Code comments to browser.xhtml
- Testcases, assertions that were mostly using browser.xul as a generic chrome URL
- References to the browser.xul path in tree
Differential Revision: https://phabricator.services.mozilla.com/D33208
We do this because we will be introducing more privileged content processes
and we want to be able to distinguish them.
Differential Revision: https://phabricator.services.mozilla.com/D30274
--HG--
rename : browser/base/content/test/tabs/browser_new_tab_in_privileged_process_pref.js => browser/base/content/test/tabs/browser_new_tab_in_privilegedabout_process_pref.js
extra : moz-landing-system : lando
The requestor should be ourselves: the toplevel docshell that the tabgroup does
not need to look in when doing the search.
Differential Revision: https://phabricator.services.mozilla.com/D32422
--HG--
extra : moz-landing-system : lando
Previously the `WebNavigationChild` would keep track of when triggering its
`nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods.
It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of
porting `OnStateChange` and `OnLocationChange` events from
`WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this
informations needs to be available from the `BrowserChild`. As it stands, it is
currently an expando property on the `WebProgressChild`.
Instead of introducing yet another XPCOM interface for the WebProgressChild, we
now store this information directly on the `nsDocShell`. Furthermore, instead
of having the `WebNavigationChild` manage this part of the `nsDocShell`'s
state, we can have the `nsDocShell` manage this state itself so it is always
consistent.
Differential Revision: https://phabricator.services.mozilla.com/D28124
--HG--
extra : moz-landing-system : lando
Valentin Gosu
Andreas Farre
Noemi Erli
Ehsan Akhgari
Sean Feng
Boris Zbarsky
Nika Layzell
Gijs Kruitbosch
Christoph Kerschbaumer
Bogdan Tara
Thomas Nguyen
Jim Porter
shindli
Emilio Cobos Álvarez
Cosmin Sabou
Henri Sivonen
Melvin George
arthur.iakab
Honza Bambas
Brian Grinstead
Tom Ritter
Mihai Alexandru Michis
Sylvestre Ledru
Barret Rennie
Edgar Chen
Tim Nguyen