This value is determined in Parent process and passed down to nsDocShell. Delete
the messages to pass the setting down and set it on the BrowsingContext in the
Parent process.
Refactor the code that determines to opt-out of using global history. Code
inspection determines that windowless browsing contexts want to opt-out as well
as any frame with `disableglobalhistory` attribute set on it.
Differential Revision: https://phabricator.services.mozilla.com/D72279
Note that the propagation of the target guid to places where the transform
will be applied is best-effort at the moment. In particular, the
InputAPZContext will result in the correct guid being available in places
that are called synchronously from the Recv*() functions, but not places
called asynhcronously (e.g. via DelayedFireSingleTapEvent).
To mitigate this, places where the transform is applied fall back on the
RCD-RSF if a guid is not available via InputAPZContext (added in a
subsequent patch).
The cases that this gets wrong are fairly edge casey (it requires (a) an
asynchronous codepath, (b) an event targeting a subframe, and (c) that
subframe having a "could not accept the APZ scroll position" transform),
so we just punt on them for now. If it turns out to be important to handle,
then options for doing so include (1) propagating the guid through each of
the affected asynchronous codepaths, or (2) attaching the guid to the event
itself.
Differential Revision: https://phabricator.services.mozilla.com/D68723
Note that the propagation of the target guid to places where the transform
will be applied is best-effort at the moment. In particular, the
InputAPZContext will result in the correct guid being available in places
that are called synchronously from the Recv*() functions, but not places
called asynhcronously (e.g. via DelayedFireSingleTapEvent).
To mitigate this, places where the transform is applied fall back on the
RCD-RSF if a guid is not available via InputAPZContext (added in a
subsequent patch).
The cases that this gets wrong are fairly edge casey (it requires (a) an
asynchronous codepath, (b) an event targeting a subframe, and (c) that
subframe having a "could not accept the APZ scroll position" transform),
so we just punt on them for now. If it turns out to be important to handle,
then options for doing so include (1) propagating the guid through each of
the affected asynchronous codepaths, or (2) attaching the guid to the event
itself.
Differential Revision: https://phabricator.services.mozilla.com/D68723
Implemecurnt a flag `suspendMediaWhenInactive` on the docShell that indicates media in that shell should be suspended when the shell is inactive. Currently, only GeckoView is using this flag.
---
The reason of implementing this flag is because in bug1577890 we remove the old way to suspend/resume the media, and I thought setting docshell to inactive is enough to suspend the media because we already have a mechanism which would suspend/resume media when document becomes inactive/active [1].
However, the active state of document is actually different from what I thought it was. Setting docshell to inactive won't change the document's active state, because that indicates if the document is the current active document for the docshell [2] (docshell can have multiple documents), instead of indicating if the docshell is active or not.
Therefore, we have to add another flag to indicate if the docshell wants to suspend its media when it's inactive, in order to use current mechanism to suspend/resume media.
[1] https://searchfox.org/mozilla-central/rev/4d2a9d5dc8f0e65807ee66e2b04c64596c643b7a/dom/html/HTMLMediaElement.cpp#6453
[2] https://searchfox.org/mozilla-central/rev/4d2a9d5dc8f0e65807ee66e2b04c64596c643b7a/dom/base/Document.h#2627-2633
Differential Revision: https://phabricator.services.mozilla.com/D69669
This commit:
- removes sendRpcMessage, which was unused;
- removes the CPOW argument to sendAsyncMessage, broadcastAsyncMessage, and
sendSyncMessage;
- removes the aIsSync argument used internally to distinguish sendRpcMessage
and sendSyncMessage;
- removes CPOW tests;
- updates the few remaining callsites that use more than 2 arguments in
sendAsyncMessage for the removal of the cpows argument.
Differential Revision: https://phabricator.services.mozilla.com/D71514
These were added for the sake of app browsers, and all of the code which
actually needed them has since been removed.
Differential Revision: https://phabricator.services.mozilla.com/D70741
These were added for the sake of app browsers, and all of the code which
actually needed them has since been removed.
Differential Revision: https://phabricator.services.mozilla.com/D70741
These were added for the sake of app browsers, and all of the code which
actually needed them has since been removed.
Differential Revision: https://phabricator.services.mozilla.com/D70741
Implemecurnt a flag `suspendMediaWhenInactive` on the docShell that indicates media in that shell should be suspended when the shell is inactive. Currently, only GeckoView is using this flag.
---
The reason of implementing this flag is because in bug1577890 we remove the old way to suspend/resume the media, and I thought setting docshell to inactive is enough to suspend the media because we already have a mechanism which would suspend/resume media when document becomes inactive/active [1].
However, the active state of document is actually different from what I thought it was. Setting docshell to inactive won't change the document's active state, because that indicates if the document is the current active document for the docshell [2] (docshell can have multiple documents), instead of indicating if the docshell is active or not.
Therefore, we have to add another flag to indicate if the docshell wants to suspend its media when it's inactive, in order to use current mechanism to suspend/resume media.
[1] https://searchfox.org/mozilla-central/rev/4d2a9d5dc8f0e65807ee66e2b04c64596c643b7a/dom/html/HTMLMediaElement.cpp#6453
[2] https://searchfox.org/mozilla-central/rev/4d2a9d5dc8f0e65807ee66e2b04c64596c643b7a/dom/base/Document.h#2627-2633
Differential Revision: https://phabricator.services.mozilla.com/D69669
--HG--
extra : moz-landing-system : lando
This still scrolls back to the top when focusing a subdocument via the tab key
or such in a (same-origin) iframe... I've decided to preserve behavior there but
let me know if you just want me to add a root element check in
nsFocusManager::ScrollIntoView instead.
I don't think it matters much, it's an edge case and either way this is a
progression.
Differential Revision: https://phabricator.services.mozilla.com/D70540
--HG--
extra : moz-landing-system : lando
There are no remaining users of mozbrowser in our tree, so this patch removes
the logic which used to exist for handling window.open differently within
mozbrowser frames.
Differential Revision: https://phabricator.services.mozilla.com/D67057
--HG--
extra : moz-landing-system : lando
This patch builds on top of part 7.1 by creating this object within
nsWindowWatcher and ContentParent to carry the relevant information through
provider interfaces when creating new content windows. The nsOpenWindowInfo
object is not created for new chrome windows.
This patch does not propagate these flags all of the way through to the
nsFrameLoader. That change is performed in later parts to keep each part
smaller.
Differential Revision: https://phabricator.services.mozilla.com/D67051
--HG--
extra : moz-landing-system : lando
Many of these setters are redundant, and duplicate work done elsewhere. As it is
no longer correct to set nsILoadContext attributes at these times, they're being
replaced with assertions.
Differential Revision: https://phabricator.services.mozilla.com/D67047
--HG--
extra : moz-landing-system : lando
This flag tries to change nsILoadContext flags late during browser creation,
which won't be possible after this patch stack.
Differential Revision: https://phabricator.services.mozilla.com/D67041
--HG--
extra : moz-landing-system : lando
TabGroup never really made any difference in which thread something go
dispatched to. This was the intended use, but development of TabGroups
with abstract main threads never made it that far. The good thing is
that thish makes it safe to also remove to the SystemGroup and instead
switch all SystemGroup dispatches to dispatches to main thread.
Timers for setTimeout and workers were the sole users of wrapped and
throttled event targets, that those throttled queues have been moved
to the BrowsingContextGroup and are now accessed explicitly.
The SchedulerEventTarget has been removed, since there are no longer a
separate event target for every TaskCategory. Instead a
LabellingEventTarget has been added to DocGroup to handle the case
where an event is dispatched do DocGroup or when an AbstractThread is
created using a DocGroup. This means that we'll actually label more
events correctly with the DocGroup that they belong to.
DocGroups have also been moved to BrowsingContextGroup.
Depends on D67636
Differential Revision: https://phabricator.services.mozilla.com/D65936
--HG--
extra : moz-landing-system : lando
There are no remaining users of mozbrowser in our tree, so this patch removes
the logic which used to exist for handling window.open differently within
mozbrowser frames.
Differential Revision: https://phabricator.services.mozilla.com/D67057
--HG--
extra : moz-landing-system : lando
This patch builds on top of part 7.1 by creating this object within
nsWindowWatcher and ContentParent to carry the relevant information through
provider interfaces when creating new content windows. The nsOpenWindowInfo
object is not created for new chrome windows.
This patch does not propagate these flags all of the way through to the
nsFrameLoader. That change is performed in later parts to keep each part
smaller.
Differential Revision: https://phabricator.services.mozilla.com/D67051
--HG--
extra : moz-landing-system : lando
Many of these setters are redundant, and duplicate work done elsewhere. As it is
no longer correct to set nsILoadContext attributes at these times, they're being
replaced with assertions.
Differential Revision: https://phabricator.services.mozilla.com/D67047
--HG--
extra : moz-landing-system : lando
This flag tries to change nsILoadContext flags late during browser creation,
which won't be possible after this patch stack.
Differential Revision: https://phabricator.services.mozilla.com/D67041
--HG--
extra : moz-landing-system : lando
Apparently we can have collected the nsWebBrowser already, or its docshell.
mWebNav is a nsWebBrowser instance, which is destroyed early during shutdown, in
BrowserChild::DestroyWindow, which nulls out its nsDocShell instance and can cause
do_GetInterface to fail.
Just deal with it.
Differential Revision: https://phabricator.services.mozilla.com/D69244
--HG--
extra : moz-landing-system : lando
Dan Glastonbury
Nika Layzell
Razvan Maries
Bogdan Tara
Botond Ballo
Simon Giesecke
Emilio Cobos Álvarez
Dorel Luca
Olli Pettay
Csoregi Natalia
Andrea Marchesini
alwu
Gijs Kruitbosch
Kris Maglione
Ciure Andrei
David Teller
Daniel Varga
Andreas Farre
Cosmin Sabou