User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Firefox/33.0 (Beta/Release) Build ID: 20140730004005 Steps to reproduce: 1. Set breakpoint 2. Reload page 3. Remove breakpoint 4. Reload page Actual results: Breakpoint is still there Expected results: Breakpoint should stay removed
I've been getting this bug in Devtools for as long I can remember using them, make that a few months.
I did the STR with this page on bugs.js line 27 and I can't reproduce. Can you attach expand your STR with a specific webpage, source, and line number?
I think it has to do with when the breakpoint doesn't get hit. http://codepen.io/joallard/debug/wqKsE STR: 1. Set breakpoint on wqKsE:21 2. Reload 3. Remove breakpoint on 21 4. Reload => Breakpoint is back
Summary: Removed debugger breakpoints reappear after reload → Unhit debugger breakpoints reappear after reload
Strangely, after updating to the Aug 1st Aurora, I'm getting another bug (?) that makes the breakpoint get hit even within the `if(false)` block. It seems that on a run which the breakpoint is hit, it will be able to be removed properly. However if the breakpoint does not get hit, it comes back on next reload.
I can't reproduce the results in comment 3 in nightly. Can you try with a nightly build too, to make sure we are seeing the same thing? Also, do you get any errors in the Browser Console (Cmd-Shift-J) when you see the weird behavior?
In comment 4, I was referring to #1051632, which makes reproducing this bug hard with the provided STRs. I was playing with this here (http://bl.ocks.org/joallard/raw/babcee6d4024ba0cb8d8/8f8f0fe65d4983b8104c2ed6c07aa1da2227d140/), setting breakpoints in either branches. What is weird is that when I ran the file I wrote on my disk, I got all kinds of weirdness (sticky breakpoint in true branch), but I can't reproduce anything online on Blocks. And even when I download the file I can't reproduce either. I'm really scratching my head now. I'm at a loss for a reliable STR here. Sent from my Nightly
However, I'm better able to reproduce the issue in Aurora 33 (Blocks URL), which means something along those lines has been fixed or at least fiddled with. Closing.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.