Browser Toolbox Debugger not stopping for breakpoints
Categories
(DevTools :: Debugger, defect, P2)
Tracking
(Not tracked)
People
(Reporter: Gijs, Unassigned)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression)
Attachments
(1 file)
(deleted),
image/png
|
Details |
What were you doing?
- open locally built nightly/firefox from recent m-c tip (9f8766e42efe for me; doubt it matters much) with
./mach run
- open browser toolbox
- switch to debugger
- accel-p, filter for
contentAreaUtils.js
- accel-f, find
getDefaultFileName
- set breakpoint on first line
- open arbitrary webpage
- hit accel-s to save the page
What happened?
A prompt pops up asking where to save the page
What should have happened?
The breakpoint should have been hit first - the default filename is input to that dialog.
You can verify the code is being hit by adding a Cu.reportError()
call (though beware bug 1613367 or you might not see that logging either).
Anything else we should know?
The combination of bug 1613367 and this bug make it very very difficult to do frontend browser work right now because it is hard to tell if code is being hit or not.
Comment 1•5 years ago
|
||
The priority flag is not set for this bug.
:jlast, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 2•5 years ago
|
||
Gijs, is this still a problem?
I was following your steps (Win10, today's m-c) and the BP (on line 757 for me, see the attached screenshot) hits for me just fine.
Honza
Reporter | ||
Comment 3•5 years ago
|
||
(In reply to Jan Honza Odvarko [:Honza] (always need-info? me) from comment #2)
Created attachment 9131111 [details]
image.pngGijs, is this still a problem?
I was following your steps (Win10, today's m-c) and the BP (on line 757 for me, see the attached screenshot) hits for me just fine.
Honza
I saw something similar again a few days ago. I'll see if I can get some more STR either later today or tomorrow.
Reporter | ||
Comment 4•5 years ago
|
||
So, updated STR:
- clean profile, on regular nightly, on macOS
- open regular devtools, enable browser + remote debugging
- open xkcd.com
- open the browser toolbox with the shortcut (accel-opt-shift-i)
- open the debugger
- use accel-p to filter, open
contentAreaUtils.js
- set breakpoint on the 3rd executable line of
saveImageURL
(anif
statement) - switch back to the nightly you're debugging, right click the image, and click "save image as..."
- the breakpoint gets hit. click continue, then you get a file download prompt, and dismiss that with [esc]
- quit the debugged browser (which will also quit the debugger)
- reopen the debugged browser
- reopen xkcd.com
- reopen the browser debugger. It loads with the debugger and
contentAreaUtils.js
focused, and the breakpoint re-appears - right click the image again, click "save image as..." again
ER:
also stops on breakpoint
AR:
no stopping on breakpoint the second time. :-(
Toggling the breakpoint off and back on doesn't seem to help. Nor does setting other breakpoints in the same function. But setting a breakpoint in saveMedia()
in nsContextMenu.js
does work.
At this point I have no idea what's going on internally in the toolbox, I just know that the UI is lying to me and breakpoints aren't hitting when the code is running, which is Very Bad.
Updated•5 years ago
|
Comment 5•5 years ago
|
||
Thanks for the STRs, Gijs!
I can easily reproduce the problem on my machine too (Win10)
I am marking as P2 since we should pay attention to BP issues.
Jason, what could be the problem here?
Honza
Comment 6•5 years ago
|
||
I'm not sure, usually it is the server not registering the breakpoint.
Reporter | ||
Updated•5 years ago
|
Updated•5 years ago
|
Comment 7•5 years ago
|
||
Looks like the same core issue, so going to dup w/ your other bug.
Description
•