Make the TargetList expose additional targets when devtools.contenttoolbox.fission is true
Categories
(DevTools :: Framework, enhancement, P3)
Tracking
(Fission Milestone:M6, firefox74 fixed)
Tracking | Status | |
---|---|---|
firefox74 | --- | fixed |
People
(Reporter: ochameau, Assigned: ochameau)
References
(Blocks 1 open bug)
Details
Attachments
(3 files)
Bug 1578745 introduce the devtools.contenttoolbox.fission preference, in order to enable fission debugging in tab, with a web/content toolbox.
But the initial implementation of TargetList, landed in bug 1471754, do not consider this preference.
It should consider this preference and enable additional targets if this preference is set and we are debugging a local tab.
This will help testing bug 1565200 against a content toolbox.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 1•5 years ago
|
||
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 3•5 years ago
|
||
Before, each callsite had to mention which type it would like to listen to.
But at the same time, TargetList was gating this listening via the devtools fission preference.
It sounds easier if all the logic to define if we are listening to additional targets
and which types is written in one place.
Assignee | ||
Comment 4•5 years ago
|
||
Pushed by apoirot@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/b021b70fbe1c Revisit TargetList.startListening in order to bundle in the type being listened. r=jdescottes https://hg.mozilla.org/integration/autoland/rev/c28a7fe55250 Make listRemoteFrames to return only remote frames. r=jdescottes https://hg.mozilla.org/integration/autoland/rev/7468eacbeec5 Make TargetList follow devtools.contenttoolbox.fission preference. r=jdescottes
Comment 6•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/b021b70fbe1c
https://hg.mozilla.org/mozilla-central/rev/c28a7fe55250
https://hg.mozilla.org/mozilla-central/rev/7468eacbeec5
Description
•