Open Bug 1615660 Opened 5 years ago Updated 10 months ago

Reduce Network resource limits while panel is idle

Categories

(DevTools :: Netmonitor, enhancement, P3)

Product:
DevTools
Component:
Netmonitor
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: Harald, Unassigned)

References

(Blocks 1 open bug)

Details

When debugging large responses in Network panel, I want to be able to easily circumvent the response limits, so that I can inspect/download those responses. Telling devs to reload with Network panel open might be a good way that also "just works" for many devs that intentionally record network activity with the panel in focus.

devtools.netmonitor.responseBodyLimit is 1Mb right now. A simple heuristic could just multiply that by 10 when the panel is in foreground.

Implementation wise, https://searchfox.org/mozilla-central/source/devtools/server/actors/network-monitor/network-response-listener.js#193 would somehow need a hint that devtools is in foreground.

Honza, Bomsy, wdyt about this as a stopgap solution to dropping response data that is important for network debugging?

Flags: needinfo?(odvarko)
Flags: needinfo?(hmanilla)
See Also: → 1594378

From the other bug:

Bomsy:

Another idea ... how about the limit kicks in a couple of secs (wait time) after the panel is not longer active also?

me

Or simply bump it up once it was activated in a session. Most sessions never open Network panel (similar to Console only keeping the 1000 last messages before it opens).

The simple v0 solution for this might be the latter option; if users hadn't opened Network panel yet, it should only retain 500 (or even less) requests. Once active, it can throttle up.

Why this is good: 15% of DevTools DAU open Network panel; so it's important to minimize overhead for people that are not using it.

Summary: Raise responseBodyLimit when Network panel is in foreground → Reduce Network resource limits while panel is idle

Note that there are also following prefs:

  • devtools.netmonitor.requestBodyLimit - limit for POST data (1048576)
  • devtools.netmonitor.response.ui.limit - UI limit for rendering of the response body

I like what we've done for WebSocket inspector - UI that allows the user to workaround the limit. Could we do the same for HTTP? This would also make the UI consistent. Also note that request bodies should be included in the plan and use the same UI/UX as response bodies.

Honza

Flags: needinfo?(odvarko)
Flags: needinfo?(hmanilla)

Could we do the same for HTTP? This would also make the UI consistent.

The tie in is a good idea and all use cases should be considered here.

The goal for this bug should focus on a much lower threshold for the panel while in background. A UI to disable throttling (like WS does) completely should be a follow-up bug.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.