1613376 - Browser Toolbox Debugger not stopping for breakpoints

Status: RESOLVED DUPLICATE of bug 1627712

(DevTools :: Debugger, defect, P2)

Description

[:Gijs (he/him)]

What were you doing?

1. open locally built nightly/firefox from recent m-c tip (9f8766e42efe for me; doubt it matters much) with ./mach run
2. open browser toolbox
3. switch to debugger
4. accel-p, filter for contentAreaUtils.js
5. accel-f, find getDefaultFileName
6. set breakpoint on first line
7. open arbitrary webpage
8. 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

[BugBot [:suhaib / :marco/ :calixte]]

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

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Attachment: image.png

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

Comment 3

[:Gijs (he/him)]

(In reply to Jan Honza Odvarko [:Honza] (always need-info? me) from comment #2)

Created attachment 9131111 [details]
image.png

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

I saw something similar again a few days ago. I'll see if I can get some more STR either later today or tomorrow.

Comment 4

[:Gijs (he/him)]

So, updated STR:

1. clean profile, on regular nightly, on macOS
2. open regular devtools, enable browser + remote debugging
3. open xkcd.com
4. open the browser toolbox with the shortcut (accel-opt-shift-i)
5. open the debugger
6. use accel-p to filter, open contentAreaUtils.js
7. set breakpoint on the 3rd executable line of saveImageURL (an if statement)
8. switch back to the nightly you're debugging, right click the image, and click "save image as..."
9. the breakpoint gets hit. click continue, then you get a file download prompt, and dismiss that with [esc]
10. quit the debugged browser (which will also quit the debugger)
11. reopen the debugged browser
12. reopen xkcd.com
13. reopen the browser debugger. It loads with the debugger and contentAreaUtils.js focused, and the breakpoint re-appears
14. 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.

Comment 5

[Jan Honza Odvarko [:Honza] (always need-info? me)]

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

[Jason Laster [:jlast]]

I'm not sure, usually it is the server not registering the breakpoint.

Comment 7

[Logan Smyth [:loganfsmyth]]

Looks like the same core issue, so going to dup w/ your other bug.