Instantiate the parent process target actor from the server via the watcher actor
Categories
(DevTools :: Framework, task)
Tracking
(Not tracked)
People
(Reporter: ochameau, Assigned: ochameau)
References
(Depends on 1 open bug, Blocks 3 open bugs)
Details
Attachments
(1 file, 3 obsolete files)
The Parent Process Target actor is still created via the client-side logic over there:
https://searchfox.org/mozilla-central/rev/497076b5edd0f906ae088cdf224e45896162694b/devtools/shared/commands/target/target-command.js#549
It would be helpful to have all the targets to be created from the server codebase, via the watcher actor framework. So that all the targets go through the watcher codepaths.
This will probably help enabling EFT for parent process WindowGlobals.
|
Assignee | |
Comment 1•2 years ago
|
||
This new data is passed down to all function filtering in/out the WindowGlobal's.
This will be used in the next patch to allow listening for frame targets in the parent-process-only mode.
It would have been easier to re-use sessionContext to augment it with this data.
But it would make sessionContext become mutable whereas it is static today.
It is built once on WatcherActor construction.
And it would still request a SessionData message to update it accordingly in all processes/threads.
|
|
Assignee | |
Comment 2•2 years ago
|
||
This ensures that all the targets are spawned via the watcher actor in the context
of the browser toolbox. We were missing the top level target, i.e. the parent process target actor.
This could be described as enabling "server side target switching" for the Browser Toolbox.
A first challenge is that the browser toolbox focusing only on the parent process
doesn't listen to any target type.
I'm forcing to listen to FRAME target type in order to help the TargetCommand
receive the "target-available-form" RDP event while calling WatcherActor.watchTarget(FRAME).
Otherwise, if we were creating the parent process target actor when we instantiate the watcher
actor, we would emit this event and the frontend would miss it.
I picked FRAME as the parent process target actor has a FRAME targetType.
But listening to FRAME targets in the parent-process-only browser toolbox would instantiate targets for all the WindowGlobals.
Whereas we expect only the Parent Process Target to be created.
Note that if we want to enable EFT for the browser toolbox completely,
we would create target actors for parent process WindowGlobals, while ignoring the content process ones.
In the previous changeset, I'm implementing TARGET_FILTERING_OPTIONS session data,
which conveys the browser toolbox scope and this helps ignore all WindowGlobals
when the browser toolbox focuses on the parent process.
And alternative would have been to split FRAME targets into two types:
parent process and content process ones and require to watch for them in two
distinct watchTarget calls.
But note that TARGET_FILTERING_OPTIONS is meant to be reused for bug 1772310.
|
|
Assignee | |
Comment 3•2 years ago
|
||
|
||
Updated•1 year ago
|
|
|
||
Comment 4•1 year ago
|
||
Comment on attachment 9290303 [details]
Bug 1785106 - [devtools] Always retrieve the Watcher Front from commands.
Revision D154900 was moved to bug 1791973. Setting attachment 9290303 [details] to obsolete.
|
|
Assignee | |
Comment 5•1 year ago
|
||
Rather use the shortcut of it on WatcherActor, which will pass all meaningful contextual arguments to it.
|
|
||
Comment 6•1 year ago
|
||
Comment on attachment 9290131 [details]
Bug 1785106 - [devtools] Pass the browser toolbox scope to the server via TARGET_FILTERING_OPTIONS session data.
Revision D154808 was moved to bug 1811845. Setting attachment 9290131 [details] to obsolete.
|
|
||
Comment 7•1 year ago
|
||
Comment on attachment 9314359 [details]
Bug 1785106 - [devtools] Use WatcherActor.getAllBrowsingContexts rather than getAllBrowsingContextsForContext.
Revision D167993 was moved to bug 1814615. Setting attachment 9314359 [details] to obsolete.
Description
•