Firefox’s New WebSocket Inspector(hacks.mozilla.org)
hacks.mozilla.org
Firefox’s New WebSocket Inspector
https://hacks.mozilla.org/2019/10/firefoxs-new-websocket-inspector/
54 comments
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...)
(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).
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).
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
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 unless someone else knows what I'm talking about, but if nobody does, I suppose knowing that could help motivate me to isolate and reproduce the issue next time it happens.
That's probably way too vague to be helpful unless someone else knows what I'm talking about, but if nobody does, I suppose knowing that could help motivate me to isolate and reproduce the issue next time it happens.
A lot of the time that it happens to me, and I've bothered to check, it's always been some react code that's had errors.
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.
It could be the different extensions you have installed. Often this happens with adblockers, so if you use incognito mode or another browser it would fix it.
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 changes I made.
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 changes I made.
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.
Proper undo-redo is on the roadmap. It works in some cases but needs to work throughout the whole Inspector!
Chrome is usable as a standalone mini-IDE. You can open developer tools, go to sources, open a folder as a workspace and start making an actual webpage - from scratch. It can create, open, save and edit files.
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).
Where don't they? I just did a quick run through the dev tools and all the input fields I used behaved exactly as I expected.
Whoops I apologize, looks like it's only the console prompt! I get that Ctrl+V might be disabled for security reasons, but is there a config flag to enable it anyway?
And yeah for some reason Ctrl+Left/Right to jump around words, Ctrl+Shift+Left/Right to select words, and Ctrl+Backspace to delete a word, are disabled in the console prompt as well (they do seem to work in all the other DevTools input fields I can see). These are pretty ingrained in my muscle memory so I constantly bump into them.
Also I'm on Linux, in case that matters.
And yeah for some reason Ctrl+Left/Right to jump around words, Ctrl+Shift+Left/Right to select words, and Ctrl+Backspace to delete a word, are disabled in the console prompt as well (they do seem to work in all the other DevTools input fields I can see). These are pretty ingrained in my muscle memory so I constantly bump into them.
Also I'm on Linux, in case that matters.
Interesting, sounds like you may want to file a bug report. I'm on Linux as well (Arch, Cinnamon) and all of those key combinations work for me.
That's curious, they do work fine on another machine running Xfce so apparently it's related to Gnome. Filed a bug at https://bugzilla.mozilla.org/show_bug.cgi?id=1591783, thanks!
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?
Does it work for you? Your comment seems to suggest it mostly works fine for you but for me. For me it's 100% unusable.
1. JSFiddle. Run a fiddle with a loop (setTimeout/setInterval/requestAnimationFrame). Try to find it in the debugger. Fail
2. Add a `debugger` statement in the loop. Watch as Firefox doesn't display the code in the debugger
3. Add a syntax error, see message in console, click link to code, firefox doesn't display code.
1. JSFiddle. Run a fiddle with a loop (setTimeout/setInterval/requestAnimationFrame). Try to find it in the debugger. Fail
2. Add a `debugger` statement in the loop. Watch as Firefox doesn't display the code in the debugger
3. Add a syntax error, see message in console, click link to code, firefox doesn't display code.
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 multiple WSs) rather than having to look at all of them separately.
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 multiple WSs) rather than having to look at all of them separately.
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.
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.
> 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.
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.
> 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.
Fun thing is - there is no real reason for that to happen. It's just that both devtools are written using HTML and JavaScript, and it's not trivial to handle big sets of data there.
Fun thing is - there is no real reason for that to happen. It's just that both devtools are written using HTML and JavaScript, and it's not trivial to handle big sets of data there.
> 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.
Check out and financial trading website using websockets (for example the crypto ones). You'll see tens of messages per second. Example - https://www.bitmex.com/app/trade/XBTUSD
Check out and financial trading website using websockets (for example the crypto ones). You'll see tens of messages per second. Example - https://www.bitmex.com/app/trade/XBTUSD
> 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.
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.
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
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.
I can't imagine ever wanting to know when my chat message was received in relation to when a .gif was loaded.
Finally! Soon I won't need to start Chromium to debug something as simple as websockets anymore.
I recently found out about the CSS tooling Firefox has for flexbox (they're quite hard to discover).
Another feature I sometimes use in Chrome is the ability to specify my own network throttling specs (based on measured throughputs of customers and users) instead of the default profiles. It's much less of an issue than the websockets but I hope that custom network profiles become a feature as well soon. So far none of them seem advanced enough to not necessitate a virtual instance of pfSense with a shaper (to allow for burst speed/packet loss/etc.) to reliably reproduce customer network behaviour but every advancement here is a step closer to ditching my clunky setup.
I recently found out about the CSS tooling Firefox has for flexbox (they're quite hard to discover).
Another feature I sometimes use in Chrome is the ability to specify my own network throttling specs (based on measured throughputs of customers and users) instead of the default profiles. It's much less of an issue than the websockets but I hope that custom network profiles become a feature as well soon. So far none of them seem advanced enough to not necessitate a virtual instance of pfSense with a shaper (to allow for burst speed/packet loss/etc.) to reliably reproduce customer network behaviour but every advancement here is a step closer to ditching my clunky setup.
Finally! This has been on my list of "reasons why I can't use Firefox to do my job" for nearly a DECADE. Glad to see it's finally here, but wish it had been done long ago. Better late than never.
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.
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
Finally!
With such great dev tools for most other things, I've been looking forward to not have to use Chrome for websocket work.
Also, it seems we already see why competition is great, lots of cool features on the inspection.
With such great dev tools for most other things, I've been looking forward to not have to use Chrome for websocket work.
Also, it seems we already see why competition is great, lots of cool features on the inspection.
The only reason I use Chrome for development is the custom formatters, any idea if there’s a plan to implement this in Firefox?
We have them in the backlog and had some conversations with users about them to scope them out. What are you using them for? We hear it a lot from the ClojureScript community.
I use it for Elm development. https://github.com/kraklin/elm-debug-transformer. Please let me know where it is discussed, so I can contribute.
Great work! Gonna try it out!
BTW when could we have firefox be able to use the private client certificate from the MacOS's system keychain?
Have been switched back to FF as my personal browser for the past month, now this is the only thing blocking me from using it in my working environment.
https://bugzilla.mozilla.org/show_bug.cgi?id=963354
BTW when could we have firefox be able to use the private client certificate from the MacOS's system keychain?
Have been switched back to FF as my personal browser for the past month, now this is the only thing blocking me from using it in my working environment.
https://bugzilla.mozilla.org/show_bug.cgi?id=963354
>>> Binary payload viewer
Now you have my attention. I deploy both JSON and base64 string messages. It would save a lot of code-time effort to have a MITM custom handler that would allow me to inspect parse manipulate and view side effects
Thnx for building ;)
Now you have my attention. I deploy both JSON and base64 string messages. It would save a lot of code-time effort to have a MITM custom handler that would allow me to inspect parse manipulate and view side effects
Thnx for building ;)
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)
Plugable, Wireshark-style data dissectors would be the best option.
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.
Usually custom, that needs to be reverse engineered (with some help of usually minified JavaScript)
This is one option: https://developers.google.com/protocol-buffers
Chrome developer tools can view binary data transmitted with this approach.
Chrome developer tools can view binary data transmitted with this approach.
Yes, this is upcoming next as binary preview is pretty bad without it.
Nice! When can I debug nodejs code in Firefox?
I wonder if the deno project will integrate against this.
Huh yeah, used something like this for Meteor back in the day. It was incredibly awesome to see and use live.
This is great news! We had a lot of trouble debugging our XMPP client on Firefox without it.
Is this not the current functionality in Developer edition?
It is. Firefox Developer Edition uses the beta channel, which is already on version 70.
Gotcha. Thought I was going mad.