FireFox paused on breakpoint when there is no any breakpoint
Categories
(DevTools :: Debugger, defect, P3)
Tracking
(Not tracked)
People
(Reporter: kes-kes, Unassigned, NeedInfo)
References
(Blocks 2 open bugs)
Details
Attachments
(1 file)
(deleted),
image/jpeg
|
Details |
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:79.0) Gecko/20100101 Firefox/79.0
Steps to reproduce:
I open debugger panel (F12) and refresh the page.
Actual results:
Firefox pauses on breakpoint when there is no any breakpoint
Expected results:
FireFox should not stop on code lines without breakpoints.
How to workaround: put breakpoint and remove it. Then I can continues.
Comment 1•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Comment 2•4 years ago
|
||
Thanks for the report Eugen!
Is there any way how to reproduce the problem? Can you still see it on your machine.
We can't do much without reproducible test case.
Honza
Reporter | ||
Comment 3•4 years ago
|
||
it looks like some memory leak. Its random.
At some point it stops on lines in files that I do not open.
I use http://tabulator.info/ library. and when I open dev.tools debugger starts to stop somewhere inside tabulator.js
Comment 4•4 years ago
|
||
Any chance you could share your web page?
Does it happen when you create a new Firefox profile? If yes, what's the difference between your old profile and new profile?
Honza
Comment 5•4 years ago
|
||
I am keeping this report open since I've seen that before.
We need STRs to make a progress on it.
Honza
Updated•4 years ago
|
Comment 6•4 years ago
|
||
I've seen the problem. It appears to happen with these steps:
- Debug the code using breakpoints.
- Remove or disable the breakpoints.
- Change the code.
- Reload the web page in the current tab.
In some cases the debugger seems to break on the same line number as a previous breakpoint. It seems that some information about the disabling of the breakpoint is lost when the new code is loaded.
It's been in the back of my mind to come up with more details about when it happens, but when it happens I'm using thinking "just kill that breakpoint so I can find my own bug".
I've been running into this as well lately, and I think I have steps to reproduce it. It might not be the exact same thing but it consistently produces phantom breakpoints.
1.
function beep() {
return "beep";
}
function boop() {
var temp = "boop";
return temp;
}
console.log("🤖", beep(), boop());
- Set a breakpoint on the body of
beep
(line 2). - Edit the js file and swap the names of the two functions - just lines 1 and 5, not the function bodies.
- Reload the page and you should pause on line 2, where you set your breakpoint, but with no breakpoint visible.
If you remove the second function or rename it to something else, the breakpoint shows up again.
It looks like the breakpoint still exists and is sent to the page as a pending breakpoint, then later syncBreakpoints() finds the function name previously associated with the breakpoint, sees that it can't break on the same line offset+column as before, assumes the breakpoint isn't valid at all, and exits without adding a breakpoint marker to the view.
Comment 8•4 years ago
|
||
Thanks for the STR Matthew, this is super useful. I could reproduce it.
Any other found consistent STR's are welcome, as i think that there a many other scenarios that lead to these phantom breakpoints.
Comment 9•4 years ago
|
||
I can also reproduce it (using Win10, FxNightly), thank you.
Honza
Comment 10•4 years ago
|
||
It looks like related to this bug: if I remove or add breakpoints, it is still breaking on the removed breakpoints and not on the new added ones. (I run FF 88.0 on Win 10.) If I close then reopen the Developer Tools window, it's now breaking on the correct breakpoints.
Comment 11•3 years ago
|
||
This seems to be a very long-standing issue, and though I see it rather often, it is very difficult to come up with a reproducible test case. Is there anything Mozilla/Firefox could do to make this easier? I'd like to do something like this:
- Reset my dev tools in a way that is guaranteed to destroy any existing breakpoints
- Flip a switch for advanced breakpoint logging
- Keep working normally until it shows up again
- Go grab a log file from somewhere and paste it here, along with the file and line number that now contains the phantom breakpoint
Comment 12•3 years ago
|
||
I see this quite often on pages where I have had a breakpoint set in a previous version of Firefox; I can't seem to reproduce it in a fresh profile. (It also doesn't happen in private windows in the affected profile.)
The behaviour is slightly different than what was reported in comment #7 (although I can't guarantee it's different): the unexpected breakpoint dialog occurs most often on operations that affect the displayed content of the page, e.g. a page reload, or if a div-based modal dialog is shown over the content.
(Currently running 94.0b9, but it's been happening since at least 90.)
Comment 13•3 years ago
|
||
I'm also seeing this happening on latest Nightly 97.0a1 (2021-12-15) (64-bit) on OSX. Only way to fix was recreating the profile.
Comment 14•3 years ago
|
||
seeing this bug as well on Developer Version 96.0b10 (64-bit)
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Comment 16•2 years ago
|
||
Redirect a needinfo that is pending on an inactive user to the triage owner.
:bomsy, since the bug has recent activity, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 17•2 years ago
|
||
Does someone knows where the breakpoints are stored in the profile? Being able to purge this could be very useful when we have this annoying bug.
Comment 18•2 years ago
|
||
(In reply to Mildred Ki'Lya from comment #17)
Does someone knows where the breakpoints are stored in the profile? Being able to purge this could be very useful when we have this annoying bug.
Hi Mildred,
You can run this in the browser console to clear the breakpoints
await (async function () {
var loader = Cu.import("resource://devtools/shared/loader/Loader.jsm", {});
var asyncStorage = loader.require("devtools/shared/async-storage");
await asyncStorage.setItem("debugger.pending-breakpoints", {});
await asyncStorage.setItem("debugger.xhr-breakpoints", []);
})()
We are also doing some work so users can clear them here Bug 1742774
Thanks
Description
•