STR: 1) Go to https://dxr.mozilla.org/mozilla-central/source/toolkit/devtools/server/actors/script.js?from=actors/script.js#3481-3482 2) Open debugger to code-highlighter.js 3) Set BP on line 14: var container = $('#line-numbers'), 4) Note that BP is listed under code-highlighter.js in the sources panel 5) Right click on BP and add conditional breakpoint with condition `5`. 6) Refresh and hit the pause ER: The BP is still listed under code-highlighter.js in the sources panel. AR: The BP is not listed in the sources panel.

This looks like a frontend bug, and related to breakpoints, so I'd like to give it some priority. James, you said you wanted to do frontend stuff for the debugger, right? Any chance I could get you to pick up this bug?

I can take a look soon. My Q1 goal was to start restructuring the files so that it's easier in general to work on the frontend, and less about fixing small bugs, but this is still important.

Hi James, there has been no activity on this bug for over 2 months. Do you mind if I steal it from you?

I can no longer reproduce this bug using the given STR. I know we usually want regression tests for this kind of behavior, but I don't really know how to come up with a test case that doesn't depend on code-highlighter.js, which is not in our source tree. I'm voting to resolve this bug as fixed. If anyone disagrees, please leave a comment in the bug.

Hello everyone, I do debugging a lot and this bug was very annoying for me, after reload the breakpoint was set at the end of any file, if there was 2 files with the same name (but with different url paths) and set some breakpoints in the second loaded file then the breakpoint would stop at the end of the first file(!). This happened till version 37, in version 38 is ok as I tested, I hope this info will help you to create some regression tests to prevent such nasty behavior :) and yes, I vote for marking this bug as fixed. cheers

(In reply to Micleusanu Nicu from comment #5) > Hello everyone, I do debugging a lot and this bug was very annoying for me, > after reload the breakpoint was set at the end of any file, if there was 2 > files with the same name (but with different url paths) and set some > breakpoints in the second loaded file then the breakpoint would stop at the > end of the first file(!). This happened till version 37, in version 38 is ok > as I tested, I hope this info will help you to create some regression tests > to prevent such nasty behavior :) and yes, I vote for marking this bug as > fixed. > > cheers Thank you for letting us know Micleusanu. We appreciate your feedback!

This no longer seems to be happening. I can't think of a good way to write regression tests for this problem, so I'm resolving this bug as fixed.

Hey Eddy, I discovered another issue which may be related to this bug, if I set a breakpoint and after some time the execution stops to this breakpoint the whole browser UI stops responding (FF 38, Win 8.1), no response even if I click on something in the window, if I switch the browser window with some other running application and switch back to Firefox it works ok and I can continue debugging. I could not reproduce it in Firefox 39(beta), seems to be fixed but may be helpful for writing regression tests.

Oops, it seems that Firefox 39 has this issue too, tested some more and the UI stopped responding as in the case of Firefox 38, one detail the OS is working ok so it's not because of the poor productivity of the PC

I could isolate this issue with stopped UI, the execution flow that comes to the breakpoint is triggered by the "blur" event of an element on the page.

(In reply to Nicu Micleusanu from comment #10) > I could isolate this issue with stopped UI, the execution flow that comes to > the breakpoint is triggered by the "blur" event of an element on the page. Could you do me a favor and open a separate bug for this issue, with exact steps to reproduce, so I can take a closer look at it?

oh, it seems that this is a reported bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1016561