Closed Bug 1528654 Opened 2 years ago Closed 2 years ago

Debugger does not pause at breakpoints except for the 1st window

Categories

(DevTools :: Debugger, defect)

67 Branch
defect
Not set
normal

Tracking

(firefox-esr60 unaffected, firefox65 unaffected, firefox66 unaffected, firefox67 fixed)

RESOLVED FIXED
Firefox 67
Tracking Status
firefox-esr60 --- unaffected
firefox65 --- unaffected
firefox66 --- unaffected
firefox67 --- fixed

People

(Reporter: Oriol, Assigned: loganfsmyth)

References

Details

(Keywords: testcase)

Attachments

(1 file)

  1. Press Ctrl+Shift+I to open devtools
  2. Press F1 to open devtools preferences
  3. Check "Enable browser chrome and add-on debugging toolboxes"
  4. Check "Enable remote debugging"
  5. Press Ctrl+Alt+Shift+I to open Browser Toolbox
  6. In the Browser Toolbox, switch to the debugger panel
  7. Press Ctrl+P to find file /content/tabbrowser.js, open it
  8. Press Ctrl+F to search ​ addTab(aUri, add a breakpoint just inside the addTab function
  9. Focus the Firefox window, press Ctrl+N to open a new window
  10. In the new window, open a new tab. Note the debugger pauses. Resume.
  11. Press Ctrl+Shift+J to open browser console, enter this code:
    var appStartup = Services.startup;
    appStartup.quit(appStartup.eForceQuit | appStartup.eRestart);
    
  12. Firefox restarts. You should get both normal windows back, also the debugger toolbox and the browser console.
  13. Open a new tab in both windows.

Expected: the breakpoint is triggered in both windows.
Actual: the breakpoint is only triggered when opening a tab in the 1st window, not in the 2nd.

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9b872b266b2ed7aabac64d2f6ccc394277dbaaf3&tochange=266c1eee61a85d63b69b60793365c37a95af2570

Flags: needinfo?(lsmyth)

I'm able to reproduce this if I add the breakpoint on the line if (!triggeringPrincipal) {. I haven't dug into it more than that, but did you bisect this to my specific changes, or tag me because my changes were related to breakpoint? Curious how much bisecting we'll have to do on our own to nail down what introduced this.

And to verify, is this a workflow that your perform often, so you're confident it is a newly-introduced issue?

Flags: needinfo?(oriol-bugzilla)

(In reply to Logan Smyth [:loganfsmyth] from comment #1)

did you bisect this to my specific changes

Yes, mozregression says this appeared in https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9b872b266b2ed7aabac64d2f6ccc394277dbaaf3&tochange=266c1eee61a85d63b69b60793365c37a95af2570

And to verify, is this a workflow that your perform often, so you're confident it is a newly-introduced issue?

Yes, this totally breaks my usual workflow, e.g. for bug 1521923 I had to use console.log(new Error().stack) in various places because the debugger was useless.

Flags: needinfo?(oriol-bugzilla)

A single Debugger.Source may have been evaluated multiple times resulting in multiple Debugger.Script
instances that map to the same location. When we query for breakpoints, we want to take the first
column breakpoint on a given line, but that needs to apply to all potential instances of the
Debugger.Script for that location, not just the first one.

Pushed by lsmyth@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/cd28688c1642
Select the first column breakpoint for _all_ evaluations of a Debugger.Source, not just the first. r=jlast
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 67
Duplicate of this bug: 1529332
Flags: needinfo?(lsmyth)

Now it's better, but still not working perfectly, like pausing at breakpoints that have already been removed, or not pausing at new breakpoints. Later I will try to find clear STR.

See Also: → 1530423
You need to log in before you can comment on or make changes to this bug.