Closed Bug 1561631 Opened 3 months ago Closed Last month

Limit number of displayed frames in WebSocket side panel

Categories

(DevTools :: Netmonitor, defect, P2)

defect

Tracking

(firefox70 fixed)

RESOLVED FIXED
Firefox 70
Tracking Status
firefox70 --- fixed

People

(Reporter: Honza, Assigned: tanhengyeow)

References

(Blocks 3 open bugs)

Details

Attachments

(3 files)

Attached image image.png

The number of displayed frames should be limited and the current max limit should be stored in about:preferences

The UI should also display a notification when the limit applies (the same notification as used when response body is limited, see attached screenshot).

Honza

Priority: -- → P3
Priority: P3 → P2

I believe this should be tagged M1 too.

Flags: needinfo?(odvarko)

True, done.

Honza

Flags: needinfo?(odvarko)

To avoid pref bloat and as they are the same concept, should this use the same pref as the response preview for network?

Flags: needinfo?(odvarko)

Good point, yes, I think so.
Honza

Flags: needinfo?(odvarko)

One thought on UX here: It would be great if users can opt out of truncating messages.
Why: This can be annoying for high-frequency websockets (use case games), where 100 or 1000 messages can be generated within seconds.
How: When truncation happens, we will show a message inline with the table body Older messages got truncated.. The warning could give the option (link-styled text Disable for this session, title Might increase memory use and slow down DevTools) to disable truncation for this devtools session, which would basically be an in-memory override.

To avoid pref bloat and as they are the same concept, should this use the same pref as the response preview for network?

I missed that this bug was about the messages table, not the response preview; where it would actually apply.

Hi Harald!

The warning could give the option (link-styled text Disable for this session, title Might increase memory use and slow down DevTools) to disable truncation for this devtools session, which would basically be an in-memory override.

This sounds good to me. I was thinking we can show the option as a button (flushed right) in the notification line Honza linked in the description. When users click on it, all the messages would be shown.

Some concerns would be on how accessible this button would be to users. Also, I'm not sure if it is good to have a "Disable permanently" type of button for users that prefer to see all messages all the time. If users want it back at some point, then that's 1 more thing to think about.

Alternatively, we could have a toggle button to toggle between receiving all messages/truncate them, maybe in the filter bar?

Flags: needinfo?(hkirschner)

Truncate displayed frames if they are over the specified limit. Offers a way to disable this behaviour.

Attached image image.png

Alternative UX using inline warning-style table row, top-aligned in the table body and only visible when users scroll all the way up.

See live mockup for the latest iteration: https://www.figma.com/file/OWflRU1bKHXMR6nh921AQiMD/Network-WebSocket-Inspector?node-id=25%3A2

Flags: needinfo?(hkirschner)
Pushed by jodvarko@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/46e63c7f4609
Limit number of displayed frames in WebSocket side panel. r=Harald,Honza
Status: NEW → RESOLVED
Closed: Last month
Resolution: --- → FIXED
Target Milestone: --- → Firefox 70
Assignee: nobody → E0032242
You need to log in before you can comment on or make changes to this bug.