Closed Bug 1745238 Opened 2 years ago Closed 2 years ago

Use watcher context to filter out network events

Categories

(DevTools :: Netmonitor, task)

task

Tracking

(firefox97 fixed)

RESOLVED FIXED
97 Branch
Tracking Status
firefox97 --- fixed

People

(Reporter: ochameau, Assigned: ochameau)

References

Details

Attachments

(4 files)

For now, the various resource watchers on the server side are using a browserId attribute to distinguish tab versus browser toolbox debugging.
But ideally, we should be using Watcher actor's context object in order to convey this information.
So we should pass the context object down to the matchRequest method:
https://searchfox.org/mozilla-central/rev/4ca2f73ae9346709d39de2c8fe33874e4203b9e6/devtools/server/actors/network-monitor/network-observer.js#79-90

Alongside to this, we should probably unify all network resource watchers to always use matchRequest to filter network related platform events.
NetworkEventContentWatcher is using a distinct implementation over here:
https://searchfox.org/mozilla-central/rev/4ca2f73ae9346709d39de2c8fe33874e4203b9e6/devtools/server/actors/resources/network-events-content.js#83-91
And misses filtering over there:
https://searchfox.org/mozilla-central/source/devtools/server/actors/resources/network-events-content.js#116-128

Also, there is this code in NetworkEventActor, which is created by the previous class (NetworkEventContentWatcher):
https://searchfox.org/mozilla-central/rev/9028b0458cc1f432870d2996b186b0938dda734a/devtools/server/actors/network-monitor/network-event-actor.js#107-109
We pass down the resource class to access its browserId, which is a mapping to watcher's context's browserId.
It would be clearer and simplify if we were passing down the context down to this code.

By doing all that we ensure always using the context to filter out channels/requests.
This will then help bug 1569859 slightly change how we accept BrowsingContext.
We will no longer only accept browsingcontext by doing:
browsingContext.browserId == context.browserId
But we will also accept:
browsingContext.opener.browserId == context.browserId.

Assignee: nobody → poirot.alex
Blocks: 1745240

This will be useful in next patch to know what is the overall debugged context.
We can finally know if that's the browser context/toolbox from almost any part of the server codebase!

This will help always use context to filter out resources.

This is more reliable check and it feels more common type of check
we already do elsewhere.
It also helps expose less convoluted objects to NetworkEventActor and so simplify it.

In prevision of a broader use of this existing "context" object,
I'm renaming it in order to make this important object clearer and more easily identifiable.

SessionContext object defines what we are debugging (everything, only one tab, an addon,...)
and so controls which platform data we should expose back to the client.

Pushed by apoirot@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/65845fd3f853
[devtools] Rename WatcherActor and SessionData "context" to "sessionContext". r=nchevobbe
https://hg.mozilla.org/integration/autoland/rev/1af93ade7986
[devtools] Pass watcher actor's `context` down to WindowGlobalTargetActor r=nchevobbe
https://hg.mozilla.org/integration/autoland/rev/9bbaf0d2cbe1
[devtools] Use watcher actor context or target actor to filter out network event requests r=nchevobbe
https://hg.mozilla.org/integration/autoland/rev/4f4e935acf4c
[devtools] Use context in NetworkEventActor to know if we are debugging a tab. r=nchevobbe
Regressions: 1747371
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: