
Firefox’s New WebSocket Inspector - feross
https://hacks.mozilla.org/2019/10/firefoxs-new-websocket-inspector/
======
jchw
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.

~~~
digitarald
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_

~~~
jjoonathan
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.

~~~
cmroanirgo
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.

------
pimterry
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.

~~~
kbenson
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.

~~~
pimterry
> 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.

~~~
kbenson
> 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.

~~~
seba_dos1
> 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.

------
jeroenhd
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.

------
bastawhiz
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.

------
Waterluvian
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.

~~~
digitarald
This would be a great feature request. Filed
[https://bugzilla.mozilla.org/show_bug.cgi?id=1588994](https://bugzilla.mozilla.org/show_bug.cgi?id=1588994)

------
markild
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.

------
girishso
The only reason I use Chrome for development is the custom formatters, any
idea if there’s a plan to implement this in Firefox?

~~~
digitarald
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.

~~~
girishso
I use it for Elm development. [https://github.com/kraklin/elm-debug-
transformer](https://github.com/kraklin/elm-debug-transformer). Please let me
know where it is discussed, so I can contribute.

------
evidencepi
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](https://bugzilla.mozilla.org/show_bug.cgi?id=963354)

------
ArtWomb
>>> 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 ;)

------
cft
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)

~~~
evilpie
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.

~~~
cft
Usually custom, that needs to be reverse engineered (with some help of usually
minified JavaScript)

------
wyuenho
Nice! When can I debug nodejs code in Firefox?

~~~
MuffinFlavored
I wonder if the deno project will integrate against this.

------
dfischer
Huh yeah, used something like this for Meteor back in the day. It was
incredibly awesome to see and use live.

------
Andrew_nenakhov
This is great news! We had a lot of trouble debugging our XMPP client on
Firefox without it.

------
SketchySeaBeast
Is this not the current functionality in Developer edition?

~~~
commoner
It is. Firefox Developer Edition uses the beta channel, which is already on
version 70.

~~~
SketchySeaBeast
Gotcha. Thought I was going mad.

