This fixes the content policy type for document loads in these frames, where
the explicit mIsFrame flag was not set, due to DocShell creation taking a
different code path in remote frames than in in-process frames.
Differential Revision: https://phabricator.services.mozilla.com/D52093
--HG--
extra : moz-landing-system : lando
Exposes a new nsIDocShell API, isForceReloading, to determine if
the loaded document was force-reloaded or not.
It relies on the underlying behaviour of nsDocShell::IsForceReloading(),
which again relies on nsDocShell::IsForceReloadType(mLoadType).
The getter is used in the remote agent to test that
Page.reload({ignoreCache: true}) works as intended.
Differential Revision: https://phabricator.services.mozilla.com/D51435
--HG--
extra : moz-landing-system : lando
Getting visited colors is relatively low priority during page load. GeckoView
was using a 250ms timer, which was somewhat arbitrary.
If this turns out not to be acceptable for desktop, we can change it to a higher
priority timer.
This enables batching queries from the content process. The lesser priority of
the queries, plus the batching that this enables on the content process I hope
will make a dent on the performance regression that bug 1506842 introduces
as-is.
We should probably introduce batching in the other direction too, both of those
are potential follow-up work.
Differential Revision: https://phabricator.services.mozilla.com/D51621
--HG--
extra : moz-landing-system : lando
We can remove isOnlyToplevelInTabGroup entirely since we have
BrowsingContext/BrowsingContextGroup exposed through
chrome-webidl. Checking if a browsing context is the only top level
(auxilliary or otherwise) is only a matter of checking that there
isn't a parent, and that the size of the browsing context group is 1.
Differential Revision: https://phabricator.services.mozilla.com/D46590
--HG--
extra : moz-landing-system : lando
nsXULWindow is no longer XUL specific and is somewhat confusing name.
Differential Revision: https://phabricator.services.mozilla.com/D51486
--HG--
rename : xpfe/appshell/nsXULWindow.cpp => xpfe/appshell/AppWindow.cpp
rename : xpfe/appshell/nsXULWindow.h => xpfe/appshell/AppWindow.h
rename : xpfe/appshell/nsIXULWindow.idl => xpfe/appshell/nsIAppWindow.idl
extra : moz-landing-system : lando
nsXULWindow is no longer XUL specific and is somewhat confusing name.
Differential Revision: https://phabricator.services.mozilla.com/D51486
--HG--
rename : xpfe/appshell/nsXULWindow.cpp => xpfe/appshell/AppWindow.cpp
rename : xpfe/appshell/nsXULWindow.h => xpfe/appshell/AppWindow.h
rename : xpfe/appshell/nsIXULWindow.idl => xpfe/appshell/nsIAppWindow.idl
extra : moz-landing-system : lando
nsXULWindow is no longer XUL specific and is somewhat confusing name.
Differential Revision: https://phabricator.services.mozilla.com/D51486
--HG--
rename : xpfe/appshell/nsXULWindow.cpp => xpfe/appshell/AppWindow.cpp
rename : xpfe/appshell/nsXULWindow.h => xpfe/appshell/AppWindow.h
rename : xpfe/appshell/nsIXULWindow.idl => xpfe/appshell/nsIAppWindow.idl
extra : moz-landing-system : lando
These methods are only callable from the parent process, so it doesn't make
sense to have the method available driectly on BrowsingContext.
Differential Revision: https://phabricator.services.mozilla.com/D50854
--HG--
extra : moz-landing-system : lando
Behind a pref to ensure that we can turn this off pretty easily if it has perf
impact.
I want to leave the repainting stuff to another bug to land separately, to track
potential (though I hope not!) perf regressions more easily.
Differential Revision: https://phabricator.services.mozilla.com/D50704
--HG--
extra : moz-landing-system : lando
Lots of these callbacks have a non-`void*` final parameter, which UBSAN
complains about. This commit changes them to have a `void*` parameter.
This requires undoing the machinery added in the first two commits of bug
1473631: `TypePrefChangeFunc` and `PREF_CHANGE_METHOD`. The resulting code is
simpler (which is good) and more boilerplate-y (which is bad) but avoids the
undefined behaviour (which is good).
Differential Revision: https://phabricator.services.mozilla.com/D50901
--HG--
extra : moz-landing-system : lando
the URL moz://a redirects to mozilla's website, Because it redirects to
https we want to use documentchannel.
Depends on D49100
Differential Revision: https://phabricator.services.mozilla.com/D51227
--HG--
extra : moz-landing-system : lando
I rewrote BrowserUtils.addContentEventListener(), and that caused an
intermittent failure in browser_bug343515.js. The use of
addContentEventListener in the test is questionable, and the test as a
whole is old, so I freshened it up.
Instead of nShotsListener (and oneShotListener, which is a special
case of that) which waits for a hard coded number of load events to
fire to ensure that a page and its subframes are all loaded, I use
BrowserTestUtils.browserLoaded().
Instead of waitForPageshow, which runs a script in the content process
that waits for an event, it uses BrowserTestUtils.waitForContentEvent,
which does the same thing in a hopefully more resilient fashion.
The largest change in terms of number of characters changed is that I
rewrote the test so that it is written inside of a single add_task
async function, instead of being split into a chain of async
functions. I also used await to flatten a lot of .then() chained
things.
I fixed up some variable shadowing. There was some trickiness around
shadowed variable names being used as field names, so I introduced an
intermediate 'data' variable to hold the structure.
Finally, I call BrowserTestUtils.removeTab() instead of calling
removeTab() directly on the browser. I figured that was probably
better, though maybe it does not matter.
I added a check after each step that the URI is correct, where
missing, which would have caught a bug in an earlier version of this
patch.
Differential Revision: https://phabricator.services.mozilla.com/D51183
--HG--
extra : moz-landing-system : lando
Any number of outer windows may be attached to a BrowsingContext over its
lifetime. While the BrowsingContext is alive, it's easy to keep track of which
of these is active, and therefore which of its inner windows is active. After
it has been discarded, though, it discards its docShell reference, so all we
can tell about an inner window is whether it is active for its own outer
window, but not whether it should be considered active for its
BrowsingContext.
This patch updates the BrowsingContext detach logic to store a flag on the
current inner window recording that it was active when its BrowsingContext was
detached, and then later checks that flag to determine if it is the current
window for a detached BrowsingContext.
Differential Revision: https://phabricator.services.mozilla.com/D49032
--HG--
extra : moz-landing-system : lando
The changes try to ensure we haven't really started load process of the new page, just that
there is ongoing active request. history.back() will then only affect to the fragment navigation.
Differential Revision: https://phabricator.services.mozilla.com/D50220
--HG--
rename : docshell/test/navigation/file_fragment_handling_during_load_frame2.html => docshell/test/navigation/file_fragment_handling_during_load_frame2.sjs
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
This was copied verbatim from places, but the only thing the code can do is
schedule runnables, which outlive the function, so there's no script that can
run.
Depends on D50502.
Differential Revision: https://phabricator.services.mozilla.com/D50503
--HG--
extra : moz-landing-system : lando
GeckoView does this link clearing stuff (which is somewhat dubious), but always
used to return NS_OK.
The error handling case in Link.cpp was pretty broken anyway (it'd leave the
link marked as registered), so make that infallible, given we fatally assert in
the non-android case.
NotifyVisited is also infallible so make that infallible too.
There's no need to use NS_IMETHOD gunk when not using scriptable XPCOM, and
these functions are not called from script, so make them regular pure-virtual
functions.
Depends on D50478.
Differential Revision: https://phabricator.services.mozilla.com/D50480
--HG--
extra : moz-landing-system : lando
Interestingly the android implementation had a potentially serious bug (was
missing a script blocker).
Differential Revision: https://phabricator.services.mozilla.com/D50263
--HG--
extra : moz-landing-system : lando
In this patch, we add the propagation of the first party domain through
the tabContext while creating OOP browsers. In the window.open() case,
we will propagate the first party domain from the opener's browser parent.
And in the frame case, we will propagate it from the manager of the
browserBridgeParent of the OOP frame.
Differential Revision: https://phabricator.services.mozilla.com/D49886
--HG--
extra : moz-landing-system : lando
Depends on D49870
We fail coop-sandbox.https.html without this, since the changes in bug 1566868 don't apply to DocumentChannel.
Differential Revision: https://phabricator.services.mozilla.com/D49871
--HG--
extra : moz-landing-system : lando
We want this to run in both processes so that we set the cspToInherit on the LoadInfo within the child as well as the parent.
Differential Revision: https://phabricator.services.mozilla.com/D47355
--HG--
extra : moz-landing-system : lando
Depends on D49870
We fail coop-sandbox.https.html without this, since the changes in bug 1566868 don't apply to DocumentChannel.
Differential Revision: https://phabricator.services.mozilla.com/D49871
--HG--
extra : moz-landing-system : lando
We want this to run in both processes so that we set the cspToInherit on the LoadInfo within the child as well as the parent.
Differential Revision: https://phabricator.services.mozilla.com/D47355
--HG--
extra : moz-landing-system : lando
The other cases when ClearWindowProxy is called seem to be fine.
It is the Unlink case which was causing null .contentWindow with test_mozfiledataurl.html
Fixes bug 1580391 and backs out bug 1581004
Differential Revision: https://phabricator.services.mozilla.com/D48878
--HG--
extra : moz-landing-system : lando
All but browser_bug744745.js seem to pass even without the fixes I
made, which seems odd.
browser_bug1058164.js is a little odd because it passes in {} instead
of a boolean for the useCapture argument. I think this ends up calling
addEventListener(..., {}, false), which should be the equivalent of
addEventListener(..., {}).
Differential Revision: https://phabricator.services.mozilla.com/D49453
--HG--
extra : moz-landing-system : lando
Most of these tests have been disabled for a long time; they run well
in the current test environment.
With the additional tests running, task times increase; I have added one
more test chunk for android mochitest-plain.
These tests were identified from a random sampling of mochitest manifests;
I intend to enable more mochitests in future patches.
Differential Revision: https://phabricator.services.mozilla.com/D48912
--HG--
extra : moz-landing-system : lando
This flips the direction in which the BrowserBridge actor is generally created
such that it is generally created in the parent and sent down to a child
process.
This is done by making the decision about what kind of switch to perform in the
parent, and sending messages down to child processes async to orchestrate these
process changes.
Process launching is changed to use an async `MozPromise`-returning API in this
patch, though the actual process launching still occurs synchronously. A future
patch will enable performing async process launching through the
NewOrUsedBrowserProcess mechanism.
I know of at least a few timing issues which exist with the new logic,
especially around the state of the BrowsingContext during the process
transition. I decided to not try to fix all of these issues in this patch, as
many are complex and will require changing how we manage the lifecycle of
BrowsingContext substantially. I do, however, think that the new logic is more
reliable and has fewer timing issues than the previous logic.
Differential Revision: https://phabricator.services.mozilla.com/D47310
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
Matt Woodrow
Dorel Luca
Jonathan Kingston
Kris Maglione
Coroiu Cristina
Andreas Tolfsen
Sebastian Hengst
Emilio Cobos Álvarez
Andreas Farre
Brendan Dahl
Mihai Alexandru Michis
Peter Van der Beken
Nika Layzell
Dragana Damjanovic
Nicholas Nethercote
Paul Bone
Cosmin Sabou
Christoph Kerschbaumer
Andrew McCreight
Andreea Pavel
Kashav Madan
Razvan Maries
Daniel Varga
Ehsan Akhgari
Olli Pettay
Arthur Iakab
Edgar Chen
Brian Grinstead
Paul Zuehlcke
Tim Huang
Anny Gakhokidze
Thomas Nguyen
Tom Tung
Gijs Kruitbosch
Mark Banner
Oana Pop Rus
Boris Zbarsky
Marco Bonardo
Geoff Brown
Junior Hsu
Paolo Amadini
Narcis Beleuzu