1519082 - Add API's on the Network Front to handle getting extra Network request info from the backend

Status: NEW

(DevTools :: Netmonitor, enhancement, P3)

Description

[Yulia Startsev [:yulia]]

We currently use the webconsole client to manually route requests to netEvent actors. examples: https://searchfox.org/mozilla-central/source/devtools/shared/webconsole/client.js#462-640

We should instead use the netEvent front to take care of all of these requests automatically

Comment 1

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(In reply to Yulia Startsev [:yulia] from comment #0)

We currently use the webconsole client to manually route requests to netEvent actors. examples: https://searchfox.org/mozilla-central/source/devtools/shared/webconsole/client.js#462-640

We should instead use the netEvent front to take care of all of these requests automatically

Yulia that link isn't valid anymore. Can you please send a new perma link, please?

Honza

Comment 2

[Nicolas Chevobbe [:nchevobbe]]

The client.js file was moved to devtools/shared/fronts/webconsole.js in Bug 1485664 .

Comment 3

[Yulia Startsev [:yulia]]

yes, sorry about that. here is an updated link of methods in the webconsole that are used to send netevent requests: https://searchfox.org/mozilla-central/rev/597a69c70a5cce6f42f159eb54ad1ef6745f5432/devtools/shared/fronts/webconsole.js#250-428

There is a patch for this: https://phabricator.services.mozilla.com/D14395

Comment 4

[Alexandre Poirot [:ochameau]]

Even if the console panel is impacted, I consider this rather as specific to the netmonitor.

Comment 5

[Nicolas Chevobbe [:nchevobbe]]

Let's move it as P3 then, as netmonitor is not in M1 scope

Comment 6

[Chris Peterson [:cpeterson]]

Tracking Fission DevTools bugs for Fission Nightly (M6)

Comment 7

[Chris Peterson [:cpeterson]]

Clearing Fission Milestone because this is not a Fission bug.

Comment 9

[Hubert Boma Manilla (:bomsy)]

See also Bug 1659082 for some details

Comment 10

[Hubert Boma Manilla (:bomsy)]

Adding followup notes from a patch
We should consider doing two things here:

Stop using the WebConsoleFront. We were not calling the WebConsoleActor's methods here.

There is all these functions on WebConsoleFront which relate to networking:
https://searchfox.org/mozilla-central/rev/e0eb861a187f0bb6d994228f2e0e49b2c9ee455e/devtools/client/fronts/webconsole.js#232-410
But they should rather be moved to the NetworkContentFront, here
https://searchfox.org/mozilla-central/source/devtools/client/fronts/network-content.js

They are trying to call these methods:
https://searchfox.org/mozilla-central/rev/e0eb861a187f0bb6d994228f2e0e49b2c9ee455e/devtools/server/actors/network-monitor/network-event-actor.js#152-278

More details from Alex
Stop using DevToolsClient.request in favor of protocol.js fronts
The code in WebConsoleFront is using conn.request(), this is very cryptic and deprecated. We should avoid using that. We actually would like to get rid of this request method. It keeps a lot of code alive in DevToolsClient just for this.
But using protocol.js means instantiating fronts, so that we would probably have to instantiate NetworkEventFront in a transformer, similarly to what Belèn is about to introduce here:
https://phabricator.services.mozilla.com/D92634#change-ddgzuOh7Fta9

Comment 11

[Chris Peterson [:cpeterson]]

Tracking dt-fission-m3-mvp bugs for Fission MVP.

Comment 12

[Alexandre Poirot [:ochameau]]

Let me try to rephrase comment 10 in a more structure message.

This bug is about the requests to pull extra information about a given request. (headers, cookies, ... for requests and responses)

Today, these requests are done via the WebConsoleFront:
https://searchfox.org/mozilla-central/rev/07342ce09126c513540c1c343476e026cfa907bf/devtools/client/fronts/webconsole.js#232-410
And related actor implementation:
https://searchfox.org/mozilla-central/rev/07342ce09126c513540c1c343476e026cfa907bf/devtools/server/actors/network-monitor/network-event-actor.js#145-260

There is two issues about that here:

1. This has nothing to do with the console, nor the console actor. This code should be moved to components related to network events or network monitor.
2. We are using DebuggerClient.request. This is the only one place left where we use that. It bypass protocol.js and use a very old codepath to send and receive requests, which predates protocol.js It would be nice to remove this last usage and cleanup DebuggerClient quite significantly.

Having said that, there is many ways to address these two points.
To address 2), we have to start using a protocol.js front/actor.
To address 1), we have to use another placeholder, some front.

Comment 10 mentions reusing NetworkContentFront, that's an option. But we should acknowledge that it would be slightly special. Special in a good way.
We will have the NetworkContentActor to receive RDP requests (getRequestHeaders, getResponseHeader, ...) about many NetworkEventActors (many observed http requests). This will make NetworkEventActor no longer be an actor, but just some class used on the server, no longer directly exposed to the frontend.
Special in a good way as this pattern is actually what I have in mind with "Commands":
https://phabricator.services.mozilla.com/D97575
"Commands" are singleton actors, which receives methods calls, and some method calls may be about instances of resources.
Instead of following protocol.js principle, and having each resource be an actor and front, with methods.
These methods will be on the "command actor", and receive the resource ID.

Comment 13

[Chris Peterson [:cpeterson]]

Moving some dt-fission-m3-mvp bugs from Fission MVP to M7 (blocking Beta experiment).

Comment 14

[Chris Peterson [:cpeterson]]

Tracking dt-fission-m3-mvp test and infrastructure bugs for Fission M8 (blocking Release experiment).

Comment 15

[Chris Peterson [:cpeterson]]

Tracking DevTools Post-M8 bugs for Fission MVP milestone. They don't block the Fission Release channel experiment, but we would like them to be completed before we roll out Fission by default.

Comment 16

[Alexandre Poirot [:ochameau]]

As said in last comments, but just to clarify what should be done here:
We should introduce a NetworkEvent command (or similar) in order to hide the call to DevToolsClient.request(...) and/or call the right Front.
So that all the frontent can call the NetworkEvent command with a trivial API and ignore all the complexity of RDP.