Doing this helps ensuring that all async work done in panels,
when attaching to the top level target, to fetch already existing resources,
is fully completed before the test ends.
Differential Revision: https://phabricator.services.mozilla.com/D62554
--HG--
extra : moz-landing-system : lando
Do not include the problematic manifest on Android. We never run Android
mochitest-browser-chrome anyway. Bug 1435429 and bug 1557417 used a similar approach.
Differential Revision: https://phabricator.services.mozilla.com/D59828
--HG--
extra : moz-landing-system : lando
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.
Differential Revision: https://phabricator.services.mozilla.com/D57009
--HG--
extra : moz-landing-system : lando
In the Browser Toolbox, we fetch all types of targets, including frames and processes.
But the main process target, which is the top level target for the Browser Toolbox,
is also returned by listProcesses and so is reported as duplicated.
Differential Revision: https://phabricator.services.mozilla.com/D51630
--HG--
extra : moz-landing-system : lando
The existing checks were also enabling additional target tracking of the TargetList
for the Browser Content Toolbox.
Differential Revision: https://phabricator.services.mozilla.com/D51783
--HG--
extra : moz-landing-system : lando
This component will help build and maintain the list of all the Targets.
Making it easier to:
* listen for all the targets: TargetList.watchTargets/unwatchTargets,
* iterate over all the existing ones: TargetList.getAllTargets,
* get all the TargetScoped fronts of all the targets: TargetList.getAllFronts.
Differential Revision: https://phabricator.services.mozilla.com/D48857
--HG--
extra : moz-landing-system : lando
Alexandre Poirot
Julian Descottes
Geoff Brown