Name Description Size
browsing-context-helpers.jsm Helper function to know if a given BrowsingContext should be debugged by scope described by the given session context. @param {BrowsingContext} browsingContext The browsing context we want to check if it is part of debugged context @param {Object} sessionContext The Session Context to help know what is debugged. See devtools/server/actors/watcher/session-context.js @param {Object} options Optional arguments passed via a dictionary. @param {Boolean} options.forceAcceptTopLevelTarget If true, we will accept top level browsing context even when server target switching is disabled. In case of client side target switching, the top browsing context is debugged via a target actor that is being instantiated manually by the frontend. And this target actor isn't created, nor managed by the watcher actor. @param {Boolean} options.acceptInitialDocument By default, we ignore initial about:blank documents/WindowGlobals. But some code cares about all the WindowGlobals, this flag allows to also accept them. (Used by _validateWindowGlobal) @param {Boolean} options.acceptSameProcessIframes If true, we will accept WindowGlobal that runs in the same process as their parent document. That, even when EFT is disabled. (Used by _validateWindowGlobal) @param {Boolean} options.acceptNoWindowGlobal By default, we will reject BrowsingContext that don't have any WindowGlobal, either retrieved via BrowsingContext.currentWindowGlobal in the parent process, or via the options.windowGlobal argument. But in some case, we are processing BrowsingContext very early, before any WindowGlobal has been created for it. But they are still relevant BrowsingContexts to debug. @param {WindowGlobal} options.windowGlobal When we are in the content process, we can't easily retrieve the WindowGlobal for a given BrowsingContext. So allow to pass it via this argument. Also, there is some race conditions where browsingContext.currentWindowGlobal is null, while the callsite may have a reference to the WindowGlobal. 16834
moz.build 462
session-context.js Create the SessionContext used by the Browser Toolbox and Browser Console. This context means debugging everything. The whole browser: - all processes: parent and content, - all privileges: privileged/chrome and content/web, - all components/targets: HTML documents, processes, workers, add-ons,... 4443
SessionDataHelpers.jsm Helper module alongside WatcherRegistry, which focus on updating the "sessionData" object. This object is shared across processes and threads and have to be maintained in all these runtimes. 6302
target-helpers 4
WatcherRegistry.jsm Helper module around `sharedData` object that helps storing the state of all observed Targets and Resources, that, for all DevTools connections. Here is a few words about the C++ implementation of sharedData: https://searchfox.org/mozilla-central/rev/bc3600def806859c31b2c7ac06e3d69271052a89/dom/ipc/SharedMap.h#30-55 We may have more than one DevToolsServer and one server may have more than one client. This module will be the single source of truth in the parent process, in order to know which targets/resources are currently observed. It will also be used to declare when something starts/stops being observed. `sharedData` is a platform API that helps sharing JS Objects across processes. We use it in order to communicate to the content process which targets and resources should be observed. Content processes read this data only once, as soon as they are created. It isn't used beyond this point. Content processes are not going to update it. We will notify about changes in observed targets and resources for already running processes by some other means. (Via JS Window Actor queries "DevTools:(un)watch(Resources|Target)") This means that only this module will update the "DevTools:watchedPerWatcher" value. From the parent process, we should be going through this module to fetch the data, while from the content process, we will read `sharedData` directly. 13568