views:

389

answers:

8

Update: Thanks for the responses so far. To clarify, I'm not really looking for a logger, but more of a debugger/tracer -- I want a dump of every piece of JavaScript that executed and when it executed. I tried Venkman earlier today but it isn't very stable. My theory is that something is going wrong deep in the Dojo code, or even the Firefox code.

This only happens in Firefox 3.5 - 3.6 when Firebug is disabled (or just not installed).

Basically, I'm sending an AJAX request in Dojo 0.4.3 (I know!) using dojo.io.bind (now deprecated!). If you're familiar, it's using dojo.io.XMLHTTPTransport as the transport. Now, basically the way it works is that it sends the XHR and then has a watcher function called startWatchingInFlight that gets called every 10ms to check on the XHR's readyState property. When the property is 4, it does a bunch of stuff:

dojo.io.XMLHTTPTransport = new function () { /* I know, I know. I would never do this */
  // somewhere in XMLHTTPTransport ...
  this.startWatchingInFlight = function () {
    // alert('watching...');
    if (!this.inFlightTimer) {
      this.inFlightTimer = setTimeout("dojo.io.XMLHTTPTransport.watchInFlight();",10);
    }
  };

  this.watchInFlight = function () {
    // alert('a glance');
    // do a bunch of stuff...
    var tif = foo(); // well, never mind how we get it but it's the object in flight
    // tif.http is the XHR object
    if (4 == tif.http.readyState) {
      // call some stuff
    }
  }

  this.bind = function (args) {
    // somewhere in XMLHTTPTransport.bind ....
    this.startWatchingInFlight();
    http.send(query); // Again, http is the already-opened XHR object
    // and so on
  }
}

Now, here's the fun part! If I were to uncomment those two alerts up above, when this code is executed I would only get one alert: 'watching...'. Something happens in the 10ms before the first call to watchInFlight that prevents it from being called. (EDIT: I've also used logging statements instead of alerts to the same effect.)

So, what I need is a way to trace the JavaScript thread to see what is blocking the first call to watchInFlight. Though, if you have a solution to the above problem, I'll also take that.

Restrictions: I cannot use another library unless you can get it to play nice with Dojo 0.4.3 (I think I just threw up a little in my mouth...I'm kidding. Dojo has always been a good library).

Any help would be very appreciated.

+2  A: 

Check out the Javascript stacktrace library to do just that for all browsers :)

Eric Wendelin
That is not actually what I was looking for. I was looking for an execution tracer, not a stack tracer.
ntownsend
A: 

This is just a quick response, but alerts, depending on the situation, can screw things up. Alerts block code execution. I'd suggest instead of an alert, and if some form of debugger is out of the question, run this on a page and dedicate yourself a little pure HTML console for output.

<div id="console"></div>

Instead of alert, run a simple function like:

function log(msg) {
    document.getElementById("console").innerHTML += msg;
}

And since the code is pretty small, just write in your own pseudo-stack trace:

log("entering watchInFlight.");

IMO, alerts are great for immediate feedback, except for when asynchronous network requests are involved. In those cases, gotta use the browser debugger or a home grown logger.

jeremyosborne
That's a good call. I actually already tried that but forgot to mention it in the post. We get the same behavior even with writes to a console.
ntownsend
I think there's something contextual that is getting lost in the snippet somewhere, potentially with the scope "this" is referencing. I usually wrap my setTimeouts inside of a function closure instead of passing in a global object to eval. It's not an answer to your question, but rather something else you may want to do code you write in the future. (Evals are really, really, really slow.)
jeremyosborne
Sorry, `this` references dojo.io.XMLHttpTransport. I'll update the question to reflect that.I would also wrap my setTimeouts in a closure and not use an implied eval, but, alas, this is Dojo's code, not mine.
ntownsend
A: 

iirc, alert is like a yield, enabling other events to fire while the dialog is present, so it will change the timing of the code you're trying to debug

peller
alert() won't block the timer but it will block further JavaScript execution. So if the timer in setTimeout(foo,10) expires while an alert() fires, foo will be placed in the execution queue to be executed as soon a.s.a.p. (assuming no other setTimeOut or setInterval functions beat it to the punch.)
ntownsend
I'm talking about native events, not the js timer queue
peller
My mistake. I understood what you're saying now.
ntownsend
A: 

We use Blackbird and that works really well.

Mark
+1  A: 

I am not sure if the code that you posted is an exact replication of your problem, but in any case you have a typo!

dojo.io.XMLHttpTransport in your first line is not the same as dojo.io.XMLHTTPTransport in line 6. Notice that HTTP is different letter-case than Http.

So the browser fails when doing the eval of the timeout to determine which function to run. This explains why you didn't see any error messages... although, I'd expect it to fail also when firebug is enabled. The only thing I can think of is that firebug somehow affects how native firefox js code is doing eval.

Yoni
That was just a typo that occurred in typing up the question. In the actual code there isn't any problem with the capitalization.
ntownsend
A: 

Aptana IDE has a browser deubgger mechanism that works with firefox. So if you can set it up right and your source it might let you debug from eclipse. Note it installs a plugin to firefox.

Dmitriy Likhten
A: 

Thanks, all, for your answers. Venkman ended up being the tool I used to step through the code and led me to understand what the problem was. Or, rather, is. For those that are interested, my issue is caused by a Firefox bug: 496087. This bug may also be involved: 501501. It looks like setTimeout and setInterval are a bit broken when used between frames in Firefox 3.0.10+.

Venkman is pretty handy, but a little unstable. I occasionally get errors that say that data is missing in the execution stack.

ntownsend
A: 

Firefox 3.5 and 3.6 have the Javascript JIT enabled. When using Firebug on a page the JSD disables JIT so you can effectively debug. So the first step would be to change the JIT setting on about:config javascript.options.jit.content. If you have Firebug installed, you can also try changing the Script tag from Enabled to Disabled. I suggest you eliminate this possibility first before you continue.

sroussey
Consider it eliminated. I disabled Firebug and set `javascript.options.jit.content` to `false`. This gave me the same behavior as before (terminating JavaScript execution after the call to `setTimeout`).
ntownsend