Emit all resources via the Watcher Actor
Categories
(DevTools :: Framework, enhancement)
Tracking
(Not tracked)
People
(Reporter: ochameau, Assigned: ochameau, NeedInfo)
References
(Depends on 3 open bugs)
Details
Attachments
(2 files, 1 obsolete file)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
Bug 1764178 - [devtools] Set a fixed BrowsingContext ID and innerWindowID for parent process target.
48 bytes,
text/x-phabricator-request
|
Details | Review |
In order to help bug 1754452, it would be nice to have the watcher actor process all the resources.
For now, most target-related resources are emited as RDP events on the target actors.
But we could be firing all of them on the Watcher actor.
We are already firing all resources that can only be watched from the parent process this way. They are notified to the client via resource-available-form RDP event on the Watcher actor, with an innerWindowId
attribute set on each resource so that we can relate them to the right target actor/front.
Doing this would help slowly getting away from protocol.js and devtools intermediate transport. Instead resources would be send via a manual JSWindowActor message to the parent process. Then, from the watcher actor we don't have a strong dependency on protocol.js. We could possibly send a low level RDP packet bypassing protocol.js.
The willingness to intercept resources from the watcher actor is about being able to observe DOCUMENT_EVENT resources. This helps know when a reload is completed.
Assignee | ||
Comment 1•3 years ago
|
||
This helps get away from DevTools "Transports", but also
help send all the resources update packets from the watcher actor.
This ease a bit listening to this packets from the client side.
We only need to listen on the Watcher actor and then query the innerWindowId/browsingContextID
attributes on each resource in order to relate to the right target front.
On the server side, it can also help listen to resource packets from tha parent process.
Updated•3 years ago
|
Comment 2•2 years ago
|
||
There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:ochameau, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit auto_nag documentation.
Updated•2 years ago
|
Assignee | ||
Comment 3•2 years ago
|
||
This will help apply more transformations to all these notifications in the following patch.
Assignee | ||
Comment 4•2 years ago
|
||
For now, the parent process target actor still involved non-EFT pattern,
where this targets expose resources for many WindowGlobals.
All the WindowGlobals running in the parent process.
On top of this, if the current browser.xhml document targeted by the Browser Toolbox closes,
it will involve the iframe dropdown codepath and change the top level
document to another top level window.
We might then change the innerWindowId and BrowsingContext ID of the target,
which will later be a trouble on the client side as we consider these IDs fixed per target.
Comment 5•2 years ago
|
||
Comment on attachment 9289615 [details]
Bug 1764178 - [devtools] Merge all resource notify callback into a unique one.
Revision D154493 was moved to bug 1786516. Setting attachment 9289615 [details] to obsolete.
Description
•