Create the first top level target from the Watcher Actor
Categories
(DevTools :: Framework, enhancement)
Tracking
(Fission Milestone:M7a, firefox90 fixed)
| Tracking | Status | |
|---|---|---|
| firefox90 | --- | fixed |
People
(Reporter: ochameau, Assigned: ochameau)
References
(Blocks 1 open bug)
Details
(Whiteboard: dt-fission-m3-mvp)
Attachments
(4 files)
Today, the first top level target is created from the Frontend, via TargetFactory.forTab()/RootActor.getTab()=>TabDescriptor.getTarget().
Today next top level targets are still instantiated by the Frontend, on TabRemotenessChange, but bug 1644397 is soon going to replace that by having the Watcher Actor to spawn the next top level targets from the server codebase. This will emit a target-available-form, like any other new target.
All but the first top level target are going to be using JSWindow Actor API and follow the WindowGlobal lifecycle. Leaving the first top level target, created via TabDescriptor.getTarget(), be the only one to still use MessageManager and follow the DocShell lifecycle. Reloads and navigation within the same process won't trigger the creation of a new target.
We do want to change that, so that all targets follow the same codepath, and ultimately, we stop using MessageManager completely.
|
||
Updated•4 years ago
|
|
|
||
Comment 1•4 years ago
|
||
Depends on D105544
|
|
||
Comment 2•4 years ago
|
||
We recently discussed whether we should have only one preference for server-side target creation or 2 preferences: one for the first target and one for server side target switching.
If we chose to have 2 preferences, I think we should NOT enable the target-switching pref on any channel without the "first target" pref. We have a lot more test coverage for the first target, and we might miss many bugs if we enable only the target-switching pref.
|
Assignee | |
Updated•3 years ago
|
|
||
Updated•3 years ago
|
|
|
||
Updated•3 years ago
|
|
|
||
Updated•3 years ago
|
|
|
||
Updated•3 years ago
|
|
|
Assignee | |
Comment 3•3 years ago
|
||
When using JSWindowActor based target, each target actor is destroyed on each reload/navigation.
This code in walker actor is registering a DOMContentLoaded listener which
only fires after the target is already destroyed. This leads to exceptions.
|
||
Updated•3 years ago
|
|
|
Assignee | |
Comment 4•3 years ago
|
||
|
|
Assignee | |
Comment 5•3 years ago
|
||
One last try before landing:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=19802d8ead83f6973c3713f8c598d98d4237bfd5
|
|
Assignee | |
Comment 6•3 years ago
|
||
Use a unique way to know if we have a top level BC / a BC without a parent: !browsingContext.parent.
This is typically where we want to know if the BC is the top level tab document.
Also start using isProcessRoot in order to know if a BC is either a top level BC,
or, if its embedder is in another process. a.k.a. "top BC in a given process".
Remote iframes in a tab will have a parent attribute refering to the top level tab document,
while their isProcessRoot will be true.
We will typically use this flag to know if we should spawn a target for the given BC.
|
|
Assignee | |
Comment 7•3 years ago
|
||
Pushed by apoirot@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/e8282af5e51d [devtools] Unify all the BrowsingContext checks around top level / process roots. r=nchevobbe https://hg.mozilla.org/integration/autoland/rev/8b1ca506f67e [devtools] Create first top level target from the watcher. r=nchevobbe https://hg.mozilla.org/integration/autoland/rev/2253003c636c [devtools] Use navigateTo in debugger tests. r=nchevobbe https://hg.mozilla.org/integration/autoland/rev/a2458384f1da [devtools] Fix WalkerActor exception on server side target switching. r=nchevobbe
|
|
||
Updated•3 years ago
|
|
||
Comment 9•3 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/e8282af5e51d
https://hg.mozilla.org/mozilla-central/rev/8b1ca506f67e
https://hg.mozilla.org/mozilla-central/rev/2253003c636c
https://hg.mozilla.org/mozilla-central/rev/a2458384f1da
Description
•