Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Firefox’s New WebSocket Inspector

hacks.mozilla.org

Post reply on HN
Print view View original

11–20 of 55 posts

Re: Firefox’s New WebSocket Inspector

#11

Post by digitarald »

pimterry wrote: post #6

This is really cool, but I'm slightly sad that it looks like they've taken the same approach as Chrome: treat the whole websocket connection as a single item in the list of requests, and then show the frames within separately when it's selected. Imo, it'd be much better to have a UI that interleaved full HTTP requests with websocket frames, so you can see the comparative timing of the both (and of frames across multi…

It does seem nice to at least know when messages were sent/received in context, while not killing the performance of the network tab. I filed it as a feature request: https://bugzilla.mozilla.org/show_bug.cgi?id=1588859

Re: Firefox’s New WebSocket Inspector

#12

Post by pimterry »

kbenson wrote: post #8
pimterry wrote: post #6

This is really cool, but I'm slightly sad that it looks like they've taken the same approach as Chrome: treat the whole websocket connection as a single item in the list of requests, and then show the frames within separately when it's selected. Imo, it'd be much better to have a UI that interleaved full HTTP requests with websocket frames, so you can see the comparative timing of the both (and of frames across multi…

Given the amount of traffic a websocket might see, that might bog down or even crash devtools by loading that tab when there's a lot of messages. At least maybe you can see some summary information this way, and it also clearly delineates between multiple websockets, or if you closed one and opened another.

> that might bog down or even crash devtools

I'm not convinced - if that's true, then there's so many frames that clicking the websocket would crash devtools, which is equally unacceptable.

In my experience people tend to use websockets in a not that dissimilar way to how they'd previously use pure HTTP requests, but now the server can instantly push data back too. If that is typical (hard to say) then it shouldn't be too bad.

If people were using many (10s, 100s) of websockets in a single page then there would be an argument that individually they're manageable but together it's impossible, but I would be surprised if that's common. I'd love examples if it is!

> it also clearly delineates between multiple websockets, or if you closed one and opened another

I think you could show all frames together and still differentiate the individual sockets within. I'm imagining a UI a bit like standard git tree UIs, with a row for each item, but links between the related ones. I don't think good UX here is impossible.

Re: Firefox’s New WebSocket Inspector

#13

Post by digitarald »

silon42 wrote: post #10
XaspR8d wrote: post #5

Earlier quoted context omitted.

The websocket-monitor extension for Firefox was actually better for me than Chrome's baseline, since it could inspect websocket connections that started before I opened the inspector window. (To be clear, I'm not asking it to save past connections/frames. I just want to see the new frames that arrive/depart after I open it...)

It would be nice if it showed some info about compression.

Does that bug I filed capture it? https://bugzilla.mozilla.org/show_bug.cgi?id=1567606

Re: Firefox’s New WebSocket Inspector

#14

Post by digitarald »

jchw wrote: post #4

Oh my God, this has been such a long time coming. Debugging WebSocket connections has been one of the main reasons I’ve had to open up Chrome in recent memory. There might not be full feature parity but I think now Firefox’s dev tools are at least complete for my uses.

I'd love to hear what other things come to mind regarding feature parity. We have been hitting a few of those out of the park lately and are slowly running out of obvious ones crossing fingers

Re: Firefox’s New WebSocket Inspector

#15

Post by kbenson »

pimterry wrote: post #12
kbenson wrote: post #8

Earlier quoted context omitted.

Given the amount of traffic a websocket might see, that might bog down or even crash devtools by loading that tab when there's a lot of messages. At least maybe you can see some summary information this way, and it also clearly delineates between multiple websockets, or if you closed one and opened another.

> that might bog down or even crash devtools I'm not convinced - if that's true, then there's so many frames that clicking the websocket would crash devtools, which is equally unacceptable. In my experience people tend to use websockets in a not that dissimilar way to how they'd previously use pure HTTP requests, but now the server can instantly push data back too. If that is typical (hard to say) then it shouldn't b…

> I'm not convinced - if that's true, then there's so many frames that clicking the websocket would crash devtools, which is equally unacceptable.

I routinely see devtools of both Chrome and Firefox bog down if you preserve transactions or stay ona page with a log or background requests for a while or the console and load a few pages with a lot of ajax and/or js or that log a lot. I'm not making some assumption about a case that has no basis, I deal with the basis for what I'm assuming regularly.

> In my experience people tend to use websockets in a not that dissimilar way to how they'd previously use pure HTTP requests, but now the server can instantly push data back too. If that is typical (hard to say) then it shouldn't be too bad.

Sure. But as I noted, I see this with regular requests, so I'm not expecting websockets to show any new behavior, I'm just noting how this might help existing behavior I see.

> If people were using many (10s, 100s) of websockets in a single page then there would be an argument that individually they're manageable but together it's impossible, but I would be surprised if that's common. I'd love examples if it is!

Imagine the scenario of a page that generated a lot of websocket traffic. Maybe you've been examining something else in devtools for a few minutes (or you left it for an hour). You could have thousands of messages. Clicking on the websocket section might show you the single websocket and some summary info (bytes transferred, last communication time, what the endpoint is, etc). Clicking on the websocket to expand it might bog down, freeze or crash devtools as it loads too much data to easily display. I all the messages were shown separately, just clicking on the websocket section would likely cause the problems, and that might leave some information harder to find out or lost if you close and restart devtools.

UI design isn't always about making stuff easiest for the common case. Part of it is making sure the somewhat uncommon but not entirely rare case doesn't break the UI entirely, and that sometimes necessitates some trade-offs in the common case.

Re: Firefox’s New WebSocket Inspector

#18

Post by toupeira »

digitarald wrote: post #14
jchw wrote: post #4

Oh my God, this has been such a long time coming. Debugging WebSocket connections has been one of the main reasons I’ve had to open up Chrome in recent memory. There might not be full feature parity but I think now Firefox’s dev tools are at least complete for my uses.

I'd love to hear what other things come to mind regarding feature parity. We have been hitting a few of those out of the park lately and are slowly running out of obvious ones crossing fingers

It would be great if the DevTools input fields behaved like all other input fields in Firefox ;-) Things like Ctrl+C/V, Ctrl+(Shift+)Left/Right, and others I'm probably forgetting right now (am on phone).
Post reply on HN