From the Fission API design doc for DevTools[1], we'll be adding a Resource actor that our tools can then use to work across many frames. [1]: https://docs.google.com/document/d/19Z0nWxnEbf7ztKDE4ei7m4TLFVuFo5t7RKdjftgfMfU/edit

Well, this is really not as polished as I would like it to be... but I figured it's best to push something and try to move forward anyway since I am leaving soon.

Comment on attachment 8993194 [details] Bug 1471754 - Resources: Basic infrastructure. https://reviewboard.mozilla.org/r/257998/#review265006 ::: devtools/server/actors/resources/resources.js:60 (Diff revision 1) > + * - Process scripts [c] > + * - Sandboxes > + * - JSMs > + * - Chrome workers [t] > + * - Hidden window (from `Services.appShell.hiddenDOMWindow`) > + * - Windowless browsers (from `Services.appShell.createWindowlessBrowser()`) Having this doc inlined here is really super helpful. I think that's the first time we get such overview of everything! Now this overview helps highlighting two things that feel clunky: 1) the resource actor will be redundant with the RootActor and part of the BrowsingContextActor (listTabs, listWorkers, listAddons, ...). 2) in bug 1471754 you are using it as a target actor, but I'm wondering if it should rather be a global actor. I'm wondering if RootActor should be this new ressource actor, that eventually spawn child ressource actors. Or if RootActor should expose one root ressource actors that itself exposes child ones if necessary. I would rather see all the target come from the resource rather than having mixes cases, where some target are exposed from it and some others from the root actor. Don't you foresee a plan where rootactor's listTabs/getTab would be replaced by some equivalent in the resource actor?

Comment on attachment 8993195 [details] Bug 1471754 - Resources: Add support for processes. https://reviewboard.mozilla.org/r/258000/#review265012 ::: devtools/server/actors/resources/process.js:31 (Diff revision 1) > + } > + > + async find({ includeRemote } = {}) { > + // TODO(jryans): This implementation assumes we must be in the parent process if we > + // to access processes. With Fission, the story is more complex, but we don't have > + // the platform support for such cases yet. It is not clear what "processes" are in the overall doc from devtools/server/actors/resources/resources.js. It may only be something for browser debugging and so only exposed from main process ressource actor. I think it will most likely be only that. But it will be important to state the difference between that and the other cross process targets we will have like tabs/addons/... May be we should always go through processes to reach anything? I think early suggestions of Jim to support e10s was suggesting such API. I think this overall doc is helping draw what kind of tree we will be using around ressource actor(s) and the actors it spawns. ::: devtools/server/actors/resources/process.js:70 (Diff revision 1) > + } > + > + _connectToProcess(i) { > + const mm = ppmm.getChildAt(i); > + this.knownProcessMessageManagers.add(mm); > + return DebuggerServer.connectToContentProcess(this.conn, mm); Given our experience with RootActor.listTabs/getTab, I think it will be helpful to have two steps: 1) list things 2) connect to things That would allow connecting only to a subtest or just one target. It sounds important as connecting to a cross process target is an expensive action.

Comment on attachment 8993196 [details] Bug 1471754 - Resources: Add event piping. https://reviewboard.mozilla.org/r/258002/#review265020 As said in another comment, I don't think we should create the targets right away as it can be very expensive and we may not want to do that in every cases? ::: devtools/server/actors/resources/resources.js:115 (Diff revision 1) > + conn: this.conn, > + context: this.context, > + emit: (eventType, ...args) => { > + this.emit(eventType, type, ...args); > + }, > + }); Ahah, "Scanner" is your signature. After the AdbScanner, here comes the target scanners :)

Comment on attachment 8993194 [details] Bug 1471754 - Resources: Basic infrastructure. https://reviewboard.mozilla.org/r/257998/#review265006 > Having this doc inlined here is really super helpful. I think that's the first time we get such overview of everything! > > Now this overview helps highlighting two things that feel clunky: > 1) the resource actor will be redundant with the RootActor and part of the BrowsingContextActor (listTabs, listWorkers, listAddons, ...). > 2) in bug 1471754 you are using it as a target actor, but I'm wondering if it should rather be a global actor. > > I'm wondering if RootActor should be this new ressource actor, that eventually spawn child ressource actors. Or if RootActor should expose one root ressource actors that itself exposes child ones if necessary. > > I would rather see all the target come from the resource rather than having mixes cases, where some target are exposed from it and some others from the root actor. > > Don't you foresee a plan where rootactor's listTabs/getTab would be replaced by some equivalent in the resource actor? Yes, I agree the inline summary of resource types is quite nice! Hopefully it will be a good reference. (Not sure if it will stay up to date... but at least it has been started!) I agree the areas you mentioned are bit a clunky so far. For the paths in root actor and target actors that list things (listTabs, listWorkers, etc.), yes, I think it would be great to migrate those toward the resource actor approach instead. I think resource actor design offers a more standardized API surface for working with any kind of "list of things". About the resource actor being a target-scoped actor... I guess I am less sure here, and this connects with your other questions about whether the resource actor should be used to retrieve the primary target. I had it in my mind that the resource actor made sense as being target-scoped because it would then return lists of things filtered for that target. I think it's easiest to see this if we were to build an Application panel listing all resources for a tab using the resource actor design. Such a panel wants to show all the scripts, styles, workers, etc. for just that target (the tab in this case), so it seemed natural for the resource actor to be target-scoped, and for each resource scanner (like frames) to only look for frames that descend from the target. Okay, so if it is target-scoped, how would you use it to get the initial target then...? Maybe it could be installed as _both_ a global and target-scoped actor? You'd be dealing with at least two resources actors, a global one to get your primary target for the tab, and then the target-scoped one to get resources within the tab, like sub-frames, workers, etc. Even with multiple resource actors at different levels, it may still be an improvement over the current state, since there's a consistent API for primary and extra targets.

Comment on attachment 8993195 [details] Bug 1471754 - Resources: Add support for processes. https://reviewboard.mozilla.org/r/258000/#review265012 > It is not clear what "processes" are in the overall doc from devtools/server/actors/resources/resources.js. > It may only be something for browser debugging and so only exposed from main process ressource actor. I think it will most likely be only that. But it will be important to state the difference between that and the other cross process targets we will have like tabs/addons/... > > May be we should always go through processes to reach anything? I think early suggestions of Jim to support e10s was suggesting such API. > I think this overall doc is helping draw what kind of tree we will be using around ressource actor(s) and the actors it spawns. This support for processes is really a small thing I added that's quite specific to the case of things like Browser Console. For Browser Console, you _could_ use the frames list to connect the console to every frame in the browser, and it would work. But the Console is implemented via a process-wide platform service, so we can be more effecient here by supporting per-process connections instead of per-frame. So that's all this is here for, really. I don't think we want to force client code to traverse the tree of process boundaries manually, if that's what you mean. For example, clients should be able to use the frames list to get _all_ sub-frames: remote, non-remote, all of them. (Now, maybe some cases will need more specific filter options. More usage code will help clarify this.) > Given our experience with RootActor.listTabs/getTab, I think it will be helpful to have two steps: > 1) list things > 2) connect to things > That would allow connecting only to a subtest or just one target. It sounds important as connecting to a cross process target is an expensive action. Yes, fair enough. I agree we should break this up into 2 steps. I'll think about the best way to offer that.

Comment on attachment 8993196 [details] Bug 1471754 - Resources: Add event piping. https://reviewboard.mozilla.org/r/258002/#review265020 > Ahah, "Scanner" is your signature. > After the AdbScanner, here comes the target scanners :) Haha, indeed... :)

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #8) > Comment on attachment 8993194 [details] > > Even with multiple resource actors at different levels, it may still be an > improvement over the current state, since there's a consistent API for > primary and extra targets. I'm not suggesting to have only one global resource actor instance. Actually, I'm suggesting to have a tree of resource actors, that would match the hiearchy of resources that you have documented. Having a clear picture of what is each resource actor and what it can inspect would certainly help following what we are doing here. MainProcessResourceActor(windows[browser,hidden,windowless], processes, addons, scripts[sandbox,jsm,xpcom], workers[chrome]): * - Browser windows (BrowserWindowResourceActor(tabs) inherits from BrowsingContextActor) * - <each may have any of the resources shown above for a main document> * - Browser tabs (TabResourceActor(scripts[frame scripts,jsm,xpcom,sandbox], document)) * - Frame scripts [c] * - Main document [c] * - <each may have any of the resources shown above for a main document> * - Add-ons => AddonResourceActor(documents) * - UI documents [c] * - Background document [c] * - DevTools document [c] * - Process scripts [c] * - Sandboxes * - JSMs * - Chrome workers [t] * - Hidden window (from `Services.appShell.hiddenDOMWindow`) * - Windowless browsers (from `Services.appShell.createWindowlessBrowser()`) BrowsingContextResourceActor(scripts[regular, addon], stylesheets, fonts, images, workers[regular, sw], storages, requests, frames) * - Main document * - Scripts * - Stylesheets * - Fonts * - Images * - Service workers [c] * - Workers, worklets, etc. [t] * - Add-on content scripts affecting the document * - Storage * - Cache Storage * - Cookies [p] * - Indexed DB [p] * - Local Storage * - Session Storage * - Network request / response data [p] * - Frame documents [c] * - <each of these may itself have any of the above I'm not super confident about the actual tree it would create, but my key suggestion is to avoid involving the target actor (FrameTargetActor/BrowsingContextActor) so that we can query all the resources without involving any browsing-context-target-actor. The resource actor is really different from target-scoped actors. Conceptually, it manages all the resources being currently created by other target scoped actors (like scripts, stylesheets, ...). It may also even manage the target actor itself, so it looks weird to see it be a child of the target actor. One option is that it also becomes the target actor itself, or is a sibling of it. It see a good opportunity here to revisit the overal way to retrieve actors: * global vs target: if we ever include resources currently managed by other target scoped actors like scripts and stylesheets, we are going to go outside of just global and target scoped actors. It will be important to see how we manage these actors lifetime. Which actor manage them? * rootActor.listWorker vs browsingContextActor.listWorker, we are finally going to unify these methods shared by these two actors! * retrieving actors via rootActor.form() and browsingContextActor.form() we may want to have explicit calls to get a front, rather than immediately retrieving actor IDs and doing the laziness on the server side. It will be less magical on the server side and helps complying to protocol.js specs. So in order to move forward, I would suggest doing two things: * focus on a global resource actor, listing processes and try to use it in the browser console. This is a great usecase as this isn't web facing and RDP backward compatibility isn't a big issue here. * open followup to focus on how to get to a "scoped" resource actor. The discussion would most likely drive the opening of other followups

Here is a document to better explain my point of view on the opportunities to refactor existing codebase around the resource actor: https://docs.google.com/document/d/1Y4JdKBD8kBeBL4RYFFlcffW2JjXi3y9IV_Qj5ynlIzk/edit# I'm also trying to write another one focused on the target-scoped setup. Hopefully that will help moving forward with the resource actor. I see a good opportunity to start with processes. Replace RootActor.{listProcesses|getProcess} by a ResoureActor equivalent and use that in the browser console.

In reply to Alexandre Poirot [:ochameau] from comment #11) > I'm not super confident about the actual tree it would create, but my key > suggestion is to avoid involving the target actor > (FrameTargetActor/BrowsingContextActor) so that we can query all the > resources without involving any browsing-context-target-actor. The resource > actor is really different from target-scoped actors. Conceptually, it > manages all the resources being currently created by other target scoped > actors (like scripts, stylesheets, ...). It may also even manage the target > actor itself, so it looks weird to see it be a child of the target actor. > One option is that it also becomes the target actor itself, or is a sibling > of it. > > It see a good opportunity here to revisit the overal way to retrieve actors: > * global vs target: > if we ever include resources currently managed by other target scoped > actors like scripts and stylesheets, we are going to go outside of just > global and target scoped actors. It will be important to see how we manage > these actors lifetime. Which actor manage them? > * rootActor.listWorker vs browsingContextActor.listWorker, > we are finally going to unify these methods shared by these two actors! > * retrieving actors via rootActor.form() and browsingContextActor.form() > we may want to have explicit calls to get a front, rather than immediately > retrieving actor IDs and doing the laziness on the server side. It will be > less magical on the server side and helps complying to protocol.js specs. > > So in order to move forward, I would suggest doing two things: > * focus on a global resource actor, listing processes and try to use it in > the browser console. > This is a great usecase as this isn't web facing and RDP backward > compatibility isn't a big issue here. > * open followup to focus on how to get to a "scoped" resource actor. The > discussion would most likely drive the opening of other followups Thanks Alex, I agree with the direction you are thinking of. Thanks for making a list of all the places in the current codebase that would overlap with the resource actor approach I agree that for the long term, it seems more natural for things like scripts and their lifetimes, it would makes sense for those to move to the resource actor system. You may be right that it could be bad to land resource actor as a target-scoped actor if we end up changing the hierarchy further later (to make things more directly owned by resource actor). It definitely sounds great to simplify things like worker listing via resource actor system! :) That's exactly the type of simplification I was hoping for. I will trim this bug down to only land the process-specific version for the Browser Console.

This version removes the frames stuff and instead is just core support and processes. I filed bug 1478174 for the frames portion which will need further design. For the moment, listing and connecting are still done together. I'm still thinking about how to best separate them, but I thought I should post anyway.

The code looks good, but I'm wondering if we should expose individual scanners with their own spec rather than have them all go throught the resource actor? What do you think about this proposal? https://docs.google.com/document/d/1mCFq73D8bwdaWCcWOAs0l4E2UuRywAThH_qiGlkcrQs/edit# Otherwise, it is still a target-scoped actor, but I think it is fine addressing that in a followup. Making the resource actor be something else is most likely going to be a significant work that can be done independently.

This adds the basic infrastructure for a Resource actor that allows finding, listening for, and querying various types of things associated with the current Depends On D4075

This extends the Resources system to look for existing processes and listen for new ones when requested. Processes will be useful for the Browser Console in particular, as it can use this to easily listen in every process if desired. Depends On D4336

This adds event piping from Resource consumers in the client listening for new frames, processes, etc. to the scanners on the server that emit added and removed items. Depends On D4337

This bug currently prototypes a new set of actors and fronts to ease iterating over and listening to targets. Targets are tabs, frames, processes, addons, ... The outcome of current prototype is that it was redundant with existing listXXXX + XXXXListChanged APIs (like listTabs and tabListChanged). As-is it is as if we would still using old API and start using this new one in new places. Instead, we should draw a plan where we introduce a new, simplified API that we will be able to use from existing callsites and that also helps implementing fission. This bug is about figuring out the overall API and dispatching the work in multiple bugs (one per API: one for tabs, another one for addons, ...) and bug 1478174 which is about the new kind of targets that are necessary for fission: frames.

Pushed by apoirot@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/f4615a1b93ef Allow to unregister Front.onFront listeners. r=jdescottes

Pushed by apoirot@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/248d250adbf4 Implement the TargetList component. r=jdescottes https://hg.mozilla.org/integration/autoland/rev/f335193ba437 Make the Toolbox use the TargetList. r=jdescottes