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

41–50 of 55 posts

Re: Firefox’s New WebSocket Inspector

#41

Post by tazard »

xenostar wrote: post #38
digitarald wrote: post #14

Earlier quoted context omitted.

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

When I change a CSS property in the Rules tab under the Inspector, and I press ctrl/cmd+z, it doesn't set the property back to what it was before I changed it. And obviously ctrl/cmd+y doesn't go forwards. It's amazing how such a small change makes it so much more difficult to use the Firefox dev tools compared to Chrome. Sometimes I just want to toggle between CSS values and see what is changing, or undo a few chang…

Not a total fix, but I always just put a new rule under the one I'm replacing, and use the checks to enable (override) or disabled the rule.

Re: Firefox’s New WebSocket Inspector

#42

Post by bonestamp2 »

XaspR8d wrote: post #5
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.

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 could inspect websocket connections that started before I opened the inspector window

That's cool, and there is a way to do this in chrome in the right circumstances (like another tab/window spawned that tab/window). But if you just want it there as kind of a DVR then that's nice... I wish that was the default (at least up to some reasonable buffer size).

Re: Firefox’s New WebSocket Inspector

#43

Post by baroffoos »

jjoonathan wrote: post #31
digitarald wrote: post #14

Earlier quoted context omitted.

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

I seem to be running across an increasing number of buttons that simply don't register clicks in Firefox. It's probably not FF's fault -- my money would be on webdevs leaning on chrome-only features -- but it does bring my Firefox session to a screeching halt and sends me back to chrome, usually after filling a form and trying to hit submit. It happens about once a week. That's probably way too vague to be helpful un…

Strangely my routers web admin will not load at all on firefox. Checking the console shows there is a js error about an undefined variable. Really wonder how they managed to stuff up the page that bad.

Re: Firefox’s New WebSocket Inspector

#44

Post by greggman2 »

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

debugging iframes. I write lots of code in jsfiddle/codepen/stack overflow and Firefox fails to be able to debug.

Re: Firefox’s New WebSocket Inspector

#45

Post by bonestamp2 »

evilpie wrote: post #28
cft wrote: post #23

Binary WS data inspector with an ASCII decoder would be useful: the current trend is to use binary WS socket data to obfuscate/prevent scraping (e.g. NYSE.com real time quotes)

Is there some common protocol that is used for binary communication, or is it all custom? Something like hexview or xxd would probably help generally.

This is one option: https://developers.google.com/protocol-buffers

Chrome developer tools can view binary data transmitted with this approach.

Re: Firefox’s New WebSocket Inspector

#46

Post by igornadj »

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…

Disclaimer: haven't worked with websockets

I can't imagine ever wanting to know when my chat message was received in relation to when a .gif was loaded.

Re: Firefox’s New WebSocket Inspector

#47

Post by Kiro »

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…

> If people were using many (10s, 100s) of websockets in a single page

In my game a client can receive 60 WS frames a second. I've personally only used WebSockets for high throughput cases so I'm surprised you say people are using them in a similar way to how they would use a normal HTTP request.

Re: Firefox’s New WebSocket Inspector

#48

Post by digitarald »

xenostar wrote: post #38
digitarald wrote: post #14

Earlier quoted context omitted.

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

When I change a CSS property in the Rules tab under the Inspector, and I press ctrl/cmd+z, it doesn't set the property back to what it was before I changed it. And obviously ctrl/cmd+y doesn't go forwards. It's amazing how such a small change makes it so much more difficult to use the Firefox dev tools compared to Chrome. Sometimes I just want to toggle between CSS values and see what is changing, or undo a few chang…

Proper undo-redo is on the roadmap. It works in some cases but needs to work throughout the whole Inspector!

Re: Firefox’s New WebSocket Inspector

#49

Post by digitarald »

greggman2 wrote: post #44
digitarald wrote: post #14

Earlier quoted context omitted.

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

debugging iframes. I write lots of code in jsfiddle/codepen/stack overflow and Firefox fails to be able to debug.

We are looking into that right now actually to make that easier, maybe you could file a specific bug. Are you using the iframe-picker in Firefox and that isn't working as expected?

Re: Firefox’s New WebSocket Inspector

#50

Post by digitarald »

Waterluvian wrote: post #26

Something I've had a really hard time with is profiling bandwidth usage over time. I'm happy that I can look at individual messages and see their size, but I want to watch how the KB/s changes over monitored time. The unsatisfying answers from the Web are generally, "Use Wireshark." I don't think I should need to drop down to that layer.

This would be a great feature request. Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1588994
Post reply on HN