Possible clue to breakpoints problem

[San]

I still don't have a test-case that I can make public for the ongoing problem with some breakpoints not working (in Firefox 36, with Firebug 2.0.8, in both Mac and Win7). The issue for me is that in some cases Firebug stops at the red "breakpoint" circle, but doesn't put the yellow triangle in it, at which point all the debugger buttons are grayed out and don't work.

No test case, but I think I may have a clue as to what's happening. I got this by comparing the behavior of the Firebug debugger with Chrome's debugger on the same files and code lines. (BTW I'm finding Chrome's debugger much more reliable, although overall I still prefer Firebug, maybe just because I'm more used to it.)

In Chrome I don't see any hints as to which code lines may be breakable; it seems to let me put a breakpoint anywhere, and I only find out whether it will work when I reload. This basically sucks. Helpfully, Firebug does give such hints, by making the breakable line numbers green. I now suspect that the problem may be that Firebug is making some line numbers green that it shouldn't -- fooling me into thinking those lines can take breakpoints, and letting me click to make a red circle there. So the problem may not be so much "breakpoints failing" as "showing too many bogus breakable lines."

I hope this may help the developers fix this problem, although I don't hold much hope frankly.

BTW, can anybody explain WHY (in any debugger) some lines can take breakpoints and some can't? Offhand I haven't noticed any pattern there but I suspect there is one, something inherent to JavaScript itself rather than any particular debugger. What is the logic there? Thanks.

[Sebastian Zartner]

The green lines are executable lines, that is lines with JavaScript that can be reached by the debugger when you set a breakpoint. I also saw earlier that Firebug didn't reliably mark them as green, though I made a few quick tests right now and in these tests it was always right. There are also some related issues reported. Unfortunately it allows you to set breakpoints at unreachable areas, e.g. within HTML or at empty lines within JavaScript, which should be automatically corrected, though that code doesn't seem to work correctly.

If you have a test case with reproducible steps where the executible lines are incorrectly set, you should create issues for it.

Sebastian

[Lawrence San]

The green lines are executable lines, that is lines with JavaScript that can be reached by the debugger when you set a breakpoint.

​That seems almost tautological. What is it that makes one line of JavaScript "executable"  in the sense you mean, and another line not? My code lines that Firebug refuses to break at​ (whether or not it shows green line numbers) are executing in the page, because I can see that the page is working correctly, and it couldn't if those code lines didn't execute.

​So apparently what's "breakable" for a debugger is actually a limited subset of what's "executable" for the browser as a whole, but why?  What's the limitation or pattern there?​

That's a different question from, but presumably related to, the issue of Firebug not accurately predicting (with the green) which lines it will be able to break at.

[Sebastian Zartner]

On Sunday, March 1, 2015 at 7:16:49 PM UTC+1, San wrote:

The green lines are executable lines, that is lines with JavaScript that can be reached by the debugger when you set a breakpoint.

​That seems almost tautological. What is it that makes one line of JavaScript "executable"  in the sense you mean, and another line not? My code lines that Firebug refuses to break at​ (whether or not it shows green line numbers) are executing in the page, because I can see that the page is working correctly, and it couldn't if those code lines didn't execute.

It may be a bug. Though hard to say without a test case. Do you have a link I can try out?

Sebastian

[Mahks Doma]

@ Lawrence are these breakpoints in an iFrame?

--
You received this message because you are subscribed to the Google Groups "Firebug" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebug+u...@googlegroups.com.
To post to this group, send email to fir...@googlegroups.com.
Visit this group at http://groups.google.com/group/firebug.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebug/4e54563e-7aac-4aaa-99f6-cf258d7f279f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Lawrence San]

Sebastian, you haven't addressed my core question, which doesn't require looking at any code: in general, what makes a line of code "breakable" (in any debugger, not just Firebug)? Why is some code executable from the browser's point of view but not from the debugger's?

@Mahks Doma: No, there are no iframes in that page, and no Ajax either. Also no linked libraries like jQuery or whatever -- I write almost all my own code from scratch. Some of the JS values were set via PHP, but that shouldn't matter; that's history by the time the debugger sees it. It is complex code, with nested functions, objects, conditionals, and branching logic, and more than one JS file linked into the html page. Only one of the JS files shows the breakpoints problem, but that code works well in the page and throws no errors.

My intuition says debugger "breakability" may have something to do with scope, or code branching... but I just don't see the pattern. Somebody must have written the code in Firebug that decides (not always correctly) which line numbers to turn green -- and that person must know what the logic is.

[Sebastian Zartner]

On Monday, March 2, 2015 at 2:44:36 AM UTC+1, San wrote:

Sebastian, you haven't addressed my core question, which doesn't require looking at any code: in general, what makes a line of code "breakable" (in any debugger, not just Firebug)?

"breakable" means the debugger can stop at a specific statement (can be multiple statements within a single line of code).

Why is some code executable from the browser's point of view but not from the debugger's?

The simple answer is, that it may be a bug. Though without having an example, it's impossible to confirm.

The longer answer is this:
Note that JavaScript engines try to do some execution optimizations when parsing the code. E.g. they skip unreachable code like if(false) { ... }. Debuggers need to turn these optimizations off in order to allow breaking at breakpoints and do step debugging. Also JavaScript engines do not need to take line numbers into account while debuggers do. Therefore debuggers need to map the line numbers to the related code. This mapping may sometimes be incorrect as bug 1013219 shows.

@Mahks Doma: No, there are no iframes in that page, and no Ajax either. Also no linked libraries like jQuery or whatever -- I write almost all my own code from scratch. Some of the JS values were set via PHP, but that shouldn't matter; that's history by the time the debugger sees it. It is complex code, with nested functions, objects, conditionals, and branching logic, and more than one JS file linked into the html page. Only one of the JS files shows the breakpoints problem, but that code works well in the page and throws no errors.

Again, please post a link to a site, so your issue can be reproduced.
 

My intuition says debugger "breakability" may have something to do with scope, or code branching... but I just don't see the pattern. Somebody must have written the code in Firebug that decides (not always correctly) which line numbers to turn green -- and that person must know what the logic is.

The logic basically comes from the platform side. The code for this is implemented in debuggerLib.js. Honza may know more about that logic. See also issue 5730.

Note that marking lines as executable and actually stopping at those lines are two different things.

Sebastian