This should make the flow of how data gets into the initial WindowContext state
more clear, and allows the setting of initial synced WindowContext fields.
Differential Revision: https://phabricator.services.mozilla.com/D74324
This is a temporary workaround for the crashes this can cause. A more thorough
fix to discarded ancestor issues will be implemented in bug 1634759.
Differential Revision: https://phabricator.services.mozilla.com/D74101
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
Previously, the PWindowGlobal actor was managed by the PBrowser which hosted it,
however this could cause issues when the tab containing the PWindowGlobal was
being destroyed. Due to the slightly different lifecycles of the PBrowser actor
and the nsGlobalWindowInner which the PWindowGlobal was trying to match the
lifetime of, the actor would sometimes not fire 'willDestroy' events correctly.
This patch moves PWindowGlobal to be directly managed by PContent, and changes
logic which previously used `Manager()` to get `Browser{Parent,Child}` to
instead use a pointer member.
Differential Revision: https://phabricator.services.mozilla.com/D68596
--HG--
extra : moz-landing-system : lando
Previously, the PWindowGlobal actor was managed by the PBrowser which hosted it,
however this could cause issues when the tab containing the PWindowGlobal was
being destroyed. Due to the slightly different lifecycles of the PBrowser actor
and the nsGlobalWindowInner which the PWindowGlobal was trying to match the
lifetime of, the actor would sometimes not fire 'willDestroy' events correctly.
This patch moves PWindowGlobal to be directly managed by PContent, and changes
logic which previously used `Manager()` to get `Browser{Parent,Child}` to
instead use a pointer member.
Differential Revision: https://phabricator.services.mozilla.com/D68596
--HG--
extra : moz-landing-system : lando
So that we can get the correct client offset value and store other metrics
there and reuse them when the top browser window moves.
The client offset, browser window title bar and window decorated frame width,
is necessary to get element positions in OOP iframes in screen coordinates
for drag-and-drop etc.
This change also fixes event.screen{X,Y}. A mochitest in this commit fails
without this change with enabling fission at least on Linux. Note that in the
mochitest we have to use nsIDOMWindowUtils.synthesizeNativeMouseClick instead
of nsIDOMWindowUtils.sendMouseEvent since sendMouseEvent doesn't work in fission
world (bug 1528935).
Differential Revision: https://phabricator.services.mozilla.com/D62190
--HG--
extra : moz-landing-system : lando
There are all sorts of lifecycle issues which arise from making DocShell
responsible for discarding BrowsingContexts. In this particular bug, we tend
to run into them in cases where we create a BrowsingContext for a FrameLoader,
and then never create a DocShell for it, leading to it never being destroyed.
But there are myriad other issues as well.
This patch moves the responsibility for BrowsingContext lifecycle management
to the FrameLoader/FrameLoaderOwner, rather than the DocShell, which makes
things more consistent, and more closely aligns with spec-defined behavior.
Differential Revision: https://phabricator.services.mozilla.com/D59008
--HG--
extra : moz-landing-system : lando
This makes clear where the information comes from, and also that there are some
bits of information that we should pass down from the child that we don't, like
allowfullscreen and the frame name.
Differential Revision: https://phabricator.services.mozilla.com/D58535
--HG--
extra : moz-landing-system : lando
The change to moz.build unveiled a couple unified build issues that I also had
to fix.
Depends on D55365
Differential Revision: https://phabricator.services.mozilla.com/D55366
--HG--
extra : moz-landing-system : lando
1. When creating a DocAccessibleParent for an embedded document in an OOP iframe, it's possible that the embedder accessible hasn't been set yet.
This can occur if the iframe is initially hidden.
Previously, we incorrectly set the document up as a top level document (e.g. tab document) in this case.
Now, we set up the document as top level in its content process, set up the proxy, etc.
The document will be added to its child document later when the embedder is set.
2. When setting the embedder accessible for an OOP iframe, check if the embedded DocAccessibleParent already exists.
This can happen if an iframe is hidden and then shown or an iframe is reflowed by layout.
If it already exists, add the embedded (child) document to its embedder.
3. Mac's implementation of ProxyCreated requires that AddChildDoc be called *before* ProxyCreated so it can invalidate the native children of the parent.
Because it's possible for an OOP iframe document to be added to its embedder after the document is created, we can't satisfy this requirement for OOP iframe documents.
Therefore, we now allow a null parent in Mac's ProxyCreated and use the reorder event fired later to invalidate the native children.
Differential Revision: https://phabricator.services.mozilla.com/D51357
--HG--
extra : moz-landing-system : lando
1. When creating a DocAccessibleParent for an embedded document in an OOP iframe, it's possible that the embedder accessible hasn't been set yet.
This can occur if the iframe is initially hidden.
Previously, we incorrectly set the document up as a top level document (e.g. tab document) in this case.
Now, we set up the document as top level in its content process, set up the proxy, etc.
The document will be added to its child document later when the embedder is set.
2. When setting the embedder accessible for an OOP iframe, check if the embedded DocAccessibleParent already exists.
This can happen if an iframe is hidden and then shown or an iframe is reflowed by layout.
If it already exists, add the embedded (child) document to its embedder.
Differential Revision: https://phabricator.services.mozilla.com/D51357
--HG--
extra : moz-landing-system : lando
1. When creating a DocAccessibleParent for an embedded document in an OOP iframe, it's possible that the embedder accessible hasn't been set yet.
This can occur if the iframe is initially hidden.
Previously, we incorrectly set the document up as a top level document (e.g. tab document) in this case.
Now, we set up the document as top level in its content process, set up the proxy, etc.
The document will be added to its child document later when the embedder is set.
2. When setting the embedder accessible for an OOP iframe, check if the embedded DocAccessibleParent already exists.
This can happen if an iframe is hidden and then shown or an iframe is reflowed by layout.
If it already exists, add the embedded (child) document to its embedder.
Differential Revision: https://phabricator.services.mozilla.com/D51357
--HG--
extra : moz-landing-system : lando
1. When creating a DocAccessibleParent for an embedded document in an OOP iframe, it's possible that the embedder accessible hasn't been set yet.
This can occur if the iframe is initially hidden.
Previously, we incorrectly set the document up as a top level document (e.g. tab document) in this case.
Now, we set up the document as top level in its content process, set up the proxy, etc.
The document will be added to its child document later when the embedder is set.
2. When setting the embedder accessible for an OOP iframe, check if the embedded DocAccessibleParent already exists.
This can happen if an iframe is hidden and then shown or an iframe is reflowed by layout.
If it already exists, add the embedded (child) document to its embedder.
Differential Revision: https://phabricator.services.mozilla.com/D51357
--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
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
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
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
aForceRepaint wasn't doing what it claimed to do at all, as we've recently
learned. In current mozilla-central:
* All those arguments ended up in a RecvRenderLayers with aForceRepaint = true
(so far so good, that's expected).
* But it was ignored (so that aForceRepaint is always true to calls to
MakeVisible) from UpdateVisibility:
https://searchfox.org/mozilla-central/rev/f43ae7e1c43a4a940b658381157a6ea6c5a185c1/dom/ipc/BrowserChild.cpp#2523
* Plus that argument only does anything useful on current central if we get to
the end of MakeVisible(true). And MakeVisible() early returns if already
visible.
So all in all this seems somewhat useless, and nobody has complained about such
a thing in a long time.
It seemed to do what it promised when it was introduced in
https://hg.mozilla.org/mozilla-central/rev/27f6f789b194, but it seems the
refactoring in https://hg.mozilla.org/mozilla-central/rev/4df5fa6fa785 broke it.
I think the new setup is somewhat easier to reason about, and nobody seems to be
missing that.
I'll try to remove the forceRepaint() call itself on a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D47127
--HG--
extra : moz-landing-system : lando
