Friday, 1 February 2013

Websockets in Bugzilla

During a recent project a co-worker and I were trying to diagnose some issues with a Websocket implementation. We were testing in Firefox and brought up Firebug to see what was going on. To our surprise while we could see the UPGRADE request to create the Websocket, but we couldn't see the Websocket data itself. We ended up, at first, resorting to using Google Chrome and using its Websocket monitoring "functionality" (horrible, horrible, horrible!) to try and debug. We later settled into using Charles to monitor the Websocket data, this was pretty nice and had the added benefit of being able to easily test from a mobile divice as well. Even with that okay solution I feel that there should be a quick easy way to view any and all data passing to/from the browser by default, and that an implementation should be neat and clean, much like the rest of Firebug but unlike Google Chrome's attempt.

What has been done so far:

Firefox Bugzilla

-0 results

Firebug Google Issues

-0 results

So... nothing.

Has anyone else noticed this lacking?

MrEcho has:!topic/firebug/Z4f0UON_ebk
but he never got a response. :(

enq... did, and even got a good response!!topic/firebug/DXF5KjionVQ
and then never followed up!

Yes, others have notice, but there doesn't seem to be much of a drive to get the functionality.

Quick fixes (in order from cleanest/easiest to most problematic)

  1. Use Charles
  2. Use Google Chrome
  3. Intercept all websocket data (with console messages for example) in your implementation
  4. Bind to the "message" callback
Number four was of particular interest to me. While I was looking in to a way to capture data from the websocket implementation in Firefox I ended up following the actual notifications all the way up to the Javascript level. This was interesting because it could be done without modifying the Mozilla code base, and at a very high level. As a matter of fact I created a Scriptmonkey script that would bind to the Websocket object in the project we were working on. The problem was that it is difficult to have it detect any Websocket being created and binding to it. An idea as to why this is difficult is that the the MutationObserver doesn't seem to trigger on mutations (such as the creation of a Websocket) as high as the window object, which is where it would be happening.

What to do about it

Firebug has awesome extension capabilities, which is great, but alone isn't enough. Looking at the HTTPobserver usage in Firebug gives us an example of just how much it is dependent on observer implementation deep in the Necko framework.

We will first have to modify the Websocket implementation in Necko to allow Firebug to hook into it as an observer. Then give Firebug the ability to hook in and display the data, either as an extension or built in. Though hopefully in the case of the former, creating it in such a way that  it could easily be ported as built in to Firebug.