Closed Bug 1568895 Opened 2 years ago Closed 2 years ago

Breakpoints not working in FF68


(DevTools :: Debugger, defect, P1)

68 Branch


(firefox69 fixed, firefox70 fixed)

Firefox 70
Tracking Status
firefox69 --- fixed
firefox70 --- fixed


(Reporter: pgadmin, Assigned: loganfsmyth)




(Whiteboard: [debugger-reserve])


(3 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Opening the debugger on a page (nextcloud app), and setting a breakpoint on a javascript event routine. With pre-68, FF stopped at the breakpoint, and I could step single, in, out and continue running.
With 68.0.1 running on MacOS (I'm not sure if this started with 68.0 or 68.0.1), execution will stop if the event is triggered, but single stepping doesn't work, the "pause execution" button won't change to "continue". Execution is stopped until the devtools window is closed.

Just checked on Linux: 66.0.4 works fine, after update to 68.0.1 same problem.

Actual results:

execution stops at unknown position, and won't continue under debugger control.

Expected results:

Debugging should work.

Component: Untriaged → Debugger
Product: Firefox → DevTools

This is very weird: The very same files served from a different server will debug normally. Most settings including CSP should be the same on both servers. No hints on the console.

Both servers deliver the very same headers. Problem persists with all addons disabled.

Any hint were to poke further appreciated.

Latest version that works is 67.0.4, 68.0 invented the problem.

Sorry for not getting back this this earlier. I have not seen this in Nightly lately but we fixed and uplifted a few breakpoint bugs to Beta.

I tried to find a nexcloud example to try out, but have not found any publicly accessible environents. Could you confirm the issue persists on Nightly?

Flags: needinfo?(pgadmin)

Unfortunately, I can confirm that 70.0a1 (2019-07-26) shows the same problem.
Different: the window is greyed out, and it says "stopped at breakpoint" (translated) on it. Still uncontrollable as described above.

Flags: needinfo?(pgadmin)

Correction: there actually is a difference.
With 68.0.1, the app will continue to work normally if the devtools window is closed. With nightly, the windows greyout is removed, but the app is defunct. I guess execution was aborted. No more event processing, right click to firefox context menu is defunct as well.
Re-opening devtools from the menu (as context menu / inspect element doesn't work any more), the breakpoint is removed.
Need to refresh page to regain functionality.

That issue is tracked in

Does this happen on every page for you with all scripts? Is there some specific page we could test with?

I have set up a minimalistic app to reproduce the problem. Please contact me privately for access information.

Would it be possible to condense a reproduction into a zip, repo, or glitch we could post here? I'm assuming the reproduction would not require anything specific to your private usecase.

Attached file

Attached a nextcloud app that exposes the problem on three servers, but not on a forth.

Since the problem seems to be sensitive to the server, I'd suggest to use my test installation to narrow down the issue.

70.0.a1 fixes the "closing devtool doesn't continue" bug 1567210, but this issue is still present.

The priority flag is not set for this bug.
:jlast, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jlaster)

I've just tested the nextcloud app I've been uploading previously on a completely different nextcloud installation. It shows the very same problem, so it probably reproduces on other instances as well.

(In reply to Andreas Pflug from comment #12)

Since the problem seems to be sensitive to the server, I'd suggest to use my test installation to narrow down the issue.

How exactly should I use the attached zipped app to reproduce the problem on my machine.
Can you please provide some instructions?

For example:

  1. Open DevTools and Debugger
  2. Load this URL (from the attached zip)
  3. Operate the page to ...
  4. etc.


You need a running Nextcloud installation. ZIP has to be extracted in the /apps directory, then enable the app. Navigate to the app, set a breakpoint in moztest.js:7 and press "Click me to debug" to trigger that breakpoint.

If you don't have a NC installation at hand, I can provide access to my instance. Please contact me privately for credentials.

Flags: needinfo?(jlaster)
Priority: -- → P1
Assignee: nobody → lsmyth
Ever confirmed: true
Blocks: dbg-70
Whiteboard: [debugger-reserve]
Pushed by
Ignore duplicate original files when found. r=jlast
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 70
Regressed by: 1547307

Beta/Release Uplift Approval Request

  • User impact if declined: Debugger will fail to hit breakpoints in some cases if multiple JS files on the page have a sourcemap containing the same original JS file.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This is a very small change purely to filter items out of an array, so the affect is very minimal. It should stop the code from throwing, but otherwise have no visible effect.
  • String changes made/needed:
Attachment #9087788 - Flags: approval-mozilla-beta?
Comment on attachment 9087788 [details] [diff] [review]

Fix for debugger breakpoints not always working as expected. Approved for 69.0rc1.
Attachment #9087788 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
You need to log in before you can comment on or make changes to this bug.