Instead of letting the outer window to process `MediaControlActions`, it would be better to handle those actions all in `MediaActionHandler`.
Differential Revision: https://phabricator.services.mozilla.com/D51029
--HG--
extra : moz-landing-system : lando
This is a partial fix, which prevents the test from simply timing out. It
still fails, because this is a test of content session history listeners,
which don't currently work as expected for cross-process navigations.
Differential Revision: https://phabricator.services.mozilla.com/D51696
--HG--
rename : docshell/test/browser/file_bug422543_script.js => docshell/test/browser/Bug422543Child.jsm
extra : moz-landing-system : lando
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