All geek questions in one place

Firebug (1.10.1) assumes javascript is not limited to a single thread in firefox (13.0)

When debugging client side javascript today in Firefox, I came across something that I found rather strange and a bit unnerving. Also, I was not able to duplicate this behavior when debugging the same script using IE / VS2010.

I created a simple html document example to illustrate abnormally what I see.

<!DOCTYPE html> <html> <head> <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.js" type="text/javascript" ></script> </head> <body id="main_body"> <script type="text/javascript"> $(function () { $(".test-trigger").on("click", function () { loadStuff(); console && console.log && console.log("this will probably happen first."); }); }); function loadStuff() { $.get("http://google.com/") .fail(function () { console && console.log && console.log("this will probably happen second."); }); } </script> <button class="test-trigger">test</button> </body> </html>

If you upload this document to Firefox (I use version 13.0 with Firebug version 1.10.1 in Windows 7), click the "Check" button and look at the console tab in Firebug, you should notice that the request for receipt failed (cross domain violation, has nothing to do with the point I'm trying to make here), and then you will most likely see:

 this will probably happen first. this will probably happen second.

Now place breakpoints on lines 13 and 20:

 13: console && console.log && console.log("this will probably happen first."); 20: console && console.log && console.log("this will probably happen second.");

If you hit the test again, you will break line 13 as expected. Now resume execution. If your experience is similar to mine, you will not break on line 20. Also, if you go to the console tab, you will see the following sequence of log output:

 this will probably happen second. this will probably happen first.

For me, this means that the ajax request handler fails in a thread other than the one in which the click handler is executed. I always had to believe that all javascript for one page will be executed by one thread in any browser. Did I miss something really obvious here? Thanks for any understanding of this observation.

Oh, if I debug the same page as in IE using Visual Studio, both breakpoints fall as I expected.

+2
source share
3 answers

I find it safe to assume that the anomaly you are observing is caused by how Firebug implements breakpoints / works under the hood. I can’t confirm this. This also happens with FF 14 on OS X.

If jQuery immediately executes your fail() function and exceeds the whole XMLHttpRequest object, then there is a guarantee that the ordering of the statements will this will probably happen first. , then this will probably happen second. .

Given JavaScript single-threaded, functions will be essentially atomic; they will not be interrupted by a callback.

It seems you are trying to simulate what happens if the click function takes some time to finish execution after calling loadStuff() . The click function should not be interrupted when the fail method is executed (of course, you found a way to do this).

To take breakpoints from the equation, the version is changed here. The rest of the markup does not change.

 $(function () { $(".test-trigger").on("click", function () { loadStuff(); for (var i = 0; i < 1000000000; i++) { //block for some interesting calculation or something } console && console.log && console.log("this will probably happen first."); }); }); function loadStuff() { $.get("http://google.com/") .fail(function () { console && console.log && console.log("this will probably happen second."); }); }

The click function obviously takes a lot of time after calling loadStuff() , but the console will still display the correct order of the log statements here. It is also worth noting that if you insert the same breakpoints, the order will be invalid, for example, the original example.

I would post a problem for this using Firebug.

+2
source

$.get("http://google.com/") is asynchronous, this is a race for what comes first. The first time it is slower, since it needs to make a call, and the call occurs later when the code is executed. The call is already cached with the second request, so execution is faster.

If you need to do something before the request goes blank , use beforeSend () .

0
source

In my experience, Firebug doesn't work well when it puts breakpoints in asynchronous code.

those. if you have one straight line of execution and put control points in it, everything will be fine. However, if you enter asynchrony, for example. using setTimeout , you will not hit a breakpoint in this “parallel” line (which, of course, is not parallel, the JS engine switches between tasks). I have experienced this a lot over the last couple of months.

In Chrome, this works fine (they postpone timeouts reasonably somehow). Perhaps because Chrome dev tools are built into the browser, it is easier to manipulate timeouts. Firebug is an "easy" add-on and it may be difficult to do it right.

A simple script to reproduce the problem:

Put breakpoints on lines when I assign x , y , z . First, you click the breakpoint on line x = 1 . Use F10 to jump. You will not get to a breakpoint on a line with z = 3 ever hit a breakpoint on a line with z = 3 only if you are fast enough by pressing F10 (Firefox 14, Firebug 1.10).

 <!DOCTYPE html> <html> <body> <script type="text/javascript"> function foo(){ var x = 1; setTimeout(bar, 2000); var y = 2; } function bar(){ var z = 3; } foo(); </script> </body> </html>
0
source

Source: https://habr.com/ru/post/922915/

More articles:


All Articles