Support running devtools with bfcache navigation in parent
Categories
(DevTools :: Framework, enhancement)
Tracking
(Fission Milestone:M7a, firefox89 fixed)
Tracking | Status | |
---|---|---|
firefox89 | --- | fixed |
People
(Reporter: ochameau, Assigned: ochameau)
References
(Blocks 4 open bugs)
Details
(Whiteboard: dt-fission-m3-mvp)
Attachments
(3 files, 2 obsolete files)
Bug 1689601 will introduce a new behavior when a bfcache navigation occurs and fission is enabled.
A new DocShell will be spawn in the same process, which will break the current code supporting bfcache navigation.
Today bfcache navigation is handled by listening to pageshow and pagehide on the chromeeventhandler.
pageshow and pagehide are still firing with the new setup, but on two distinct docshells. We are then missing the pageshow event on the navigated to docshell.
In order to support this new behavior, we would need to listen to pageshow and pagehide from the DevTools's JSWindowActor, and fire a new top level target on pageshow.
But for now, top level targets are only created by the frontend, whereas here, it should be created by the backend. We have to depend on bug 1644397 in order to support that.
Once bug 1644397 lands, it should be quite easy to support the new bfcache navigations.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 1•4 years ago
|
||
Also once this bug lands, we might be able to renable tests that were disabled in bug 1665165.
Assignee | ||
Comment 2•4 years ago
|
||
Assignee | ||
Comment 3•4 years ago
|
||
BFCache in parent navigation ends up spawning a new DocShell in the same process.
The existing BrowsingContextTargetActor no longer receive the pageshow event,
because it fires on a new, distinct DocShell.
We have to listen for these two events on the JSWindowActor and spawn new target actors
when such navigation happens.
Updated•4 years ago
|
Assignee | ||
Comment 4•4 years ago
|
||
Assignee | ||
Comment 5•4 years ago
|
||
I'll have to rebase the target destruction patch on top of bug 1694906 as it introduces a destructor-destroyed event, which I'm depending on.
Assignee | ||
Comment 6•4 years ago
|
||
And I'll try to fix a few things around descriptor/target destroy in bug 1695929 first.
Comment 7•4 years ago
|
||
Comment on attachment 9206184 [details]
Bug 1694651 - Destroy target from TargetList.onTargetDestroyed and get rid of tabDetached
Revision D106835 was moved to bug 1631451. Setting attachment 9206184 [details] to obsolete.
Updated•4 years ago
|
Assignee | ||
Comment 9•4 years ago
|
||
TargetFrontMixin may try to call detach method which won't work in some cases.
At least for bfcache navigations. The target actor will already be destroyed.
detach will stay pending and the target front will never be fully destroyed
as we only call Front.destroy after detach completed.
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 10•4 years ago
|
||
Comment 11•4 years ago
|
||
Comment 12•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/350aea656f79
https://hg.mozilla.org/mozilla-central/rev/d8c17c24ef62
https://hg.mozilla.org/mozilla-central/rev/80de12aca743
Description
•