You can read all about it in our hacks article.
File bugs in the meta bug or comment here.
1 Like
Nice work, I really like the new extensions!
Something I have been missing dearly in the past is help in getting WebSocket compression working. This can be somewhat of a hassle depending on the framework used. Since the extension does not show whether messages have been compressed, the only option to validate compression is to leverage Wireshark. Needless to say that this is far from a good developer experience 
Thanks for jumping in Ben! We do have a bug on file where I tried to spec the compression work and understand it better:
https://bugzilla.mozilla.org/show_bug.cgi?id=1567608 would show if a connection is compressed.
https://bugzilla.mozilla.org/show_bug.cgi?id=1567606 would show the compressed message size as well (and probably the total transferred size in the footer)
That sounds great! Thanks for getting back to me Harald!
Hi @camden.narzt, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1590046. Could you help me understand how action cables should be formatted in the inspector?
I investigated a bit, but I hope somebody can double-check as its all deferred from the JS implementation: https://bugzilla.mozilla.org/show_bug.cgi?id=1590046#c1
Is there a way to have an “Edit and Resend” option for websocket frames, similar to how we have an “Edit and Resend” option by right-clicking on web requests? It would be great to be able to do some manual debugging by hand-editing websocket frames.
Yes, that sounds useful and I had a similar idea in the backlog. Having a basic Resend would be a good start and we can build it out from there.
Hi, great work on getting the web socket inspector into Firefox Dev Tools. It was the last thing tying me to using Chrome for me primary web development.
I have a few suggestions for improvements and useful functionality that I’d like to see:
- Make the “Size” and “Time” columns have a maximum width, or make the columns in general be resizable. Currently if you expand the dev tools window the Time column becomes very large with a lot of wasted white space that could be used for showing more of the data
- Add a total transfer size for the entire connection (both upload & download ideally)
- When the protocol is a supported one for nicer display, expand that section by default rather than the “Raw Data” section
- Support regular expressions for filtering
Great job with this so far. If any of these sound like good potential “first contributions” to Firefox I’d love to help out and implement them if pointed in the right direction to getting started.
Thanks for the many suggestions, @abryzak, and your offer to help!
Make the “Size” and “Time” columns have a maximum width
Agreed, it doesn’t make sense to resize all columns at the same rate. Filed bug 1593830.
- Add a total transfer size for the entire connection (both upload & download ideally)
Yeah, makes sense. Tracked in bug 1593831
- When the protocol is a supported one for nicer display, expand that section by default rather than the “Raw Data” section
This landed in bug 1588444 a few days ago and I only just asked now to uplift it to DevEdition.
- Support regular expressions for filtering
Right, our filtering support should be more consistent! Filed bug 1593837.
If any of these sound like good potential “first contributions” to Firefox I’d love to help out and implement them if pointed in the right direction to getting started.
This would be amazing! From your feedback, bug 1593831 is probably the lowest hanging fruit. Feel free to comment on it to get it assigned and the team can also point you to the right code locations to get started.
Hi!
Thank you for this tool.
I came across it when I was trying to debug my application which seems to have problems receiving big messages (files >100 MB) over websockets in Firefox.
In the Inspector I can see a short “Data has been truncated” message. Indeed, raw data displayed by the tool is truncated, but I have no information if truncation also applies to the data actually sent by a websocket.
So please treat it as a suggestion for improving the Inspector, but if you also have an idea why I am experiencing the described problem, I’d be super grateful for suggestions. ^^
100Mb WS messages has been out of scope for the MVP as its shipping, but having this feedback will help us prioritize it and start thinking how we can better allow inspection for this bug data.
Can you confirm if you are sending one frame with > 100 Mb data or multiple frames? I assume you’d want a binary viewer for those files, or what would you expect from inspection?
TBH I don’t know at this point whether a single frame or multiple frames are sent.
First thing that I would expect from the inspection is a clear information whether “Data has been truncated” refers only to the data viewer in the inspector itself, or the actual data sent by a websocket.
In the viewer, when I scroll all the way down, I can see that the file indeed is not displayed as a whole.
In my case it’s a text file, so a binary viewer wouldn’t help.
Looks like its 10Mb in one frame, as we don’t combine frames.
With binary viewer we will have to revisit truncation again as well. We will also discuss truncation in https://bugzilla.mozilla.org/show_bug.cgi?id=1591897.