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

Steps to reproduce:

1. Have a content script loaded in both the main page and iframes (I work on an addon)
2. Open dev tools, set a breakpoint
3. Change the "targeted document" to an iframe
4. Watch the breakpoint being shown, but ignored.
5. Set another breakpoint - this one works.

Point 4 is a problem, as I need to come up with tricks to delay code execution until I set a fresh breakpoint. If main-page breakpoints are supposed to be ignored in iframes, then why show them?

What also seems to be an issue is devTools loading code and breakpoints gradually and only after queued tasks are run - my main-page content script takes some time to run, during which I could set in-iframe breakpoints, but I can see no code to inspect until after everything has been run.

P.S. If someone could tell me where breakpoints are stored, I'd be grateful - phantom undeletable breakpoints are starting to drive me mad.

Thanks for the report.

Any chance to get your add-on to try to reproduce the issue on our machines?

Honza

I thought any addon would do - I did try to make sure it wasn't me, so I re-tested everything on a new profile and a small test addon -- feel free to use it: https://github.com/aliko-str/borderifyTMP

Just put a breakpoint somewhere in borderify.js (e.g., lines 21-24) and then switch devtools context to an iframe.

4. Watch the breakpoint being shown, but ignored.

I am not sure what you mean by "the breakpoints is ignored". Do you mean that it's disabled (gray)?

I am sending a screenshot of what I see. I can create BP as I need.
I don't know how to trigger them in your extension, but they seem to work.

Honza

I mean if you switch to an iframe, e.g., flick etc., debugger doesn't stop on the breakpoint that was set in the main-frame context, even though the the breakpoint is still shown and blue

I mean if you switch to an iframe, e.g., flick etc., debugger doesn't stop on the breakpoint that was set in the main-frame context, even though the the breakpoint is still shown and blue

Julian, are top level document BPs supposed to be ignored when an iframe is selected? Is it a feature?
Sounds like the fix here should be to render them disabled in such case.

I am not sure if this is intended or not, as there is no test checking this behavior. The code is not super explicit either.

When we change the selected frame, we mimic a regular navigation in several ways.
One of those is that the top BrowsingContextTargetActor will emit a server-side will-navigate event:
https://searchfox.org/mozilla-central/rev/4f05a46731c1f7f111ec7a41ce38a34594aa0d37/devtools/server/actors/targets/browsing-context.js#1363-1369

The thread-actor then catches this event at https://searchfox.org/mozilla-central/rev/4f05a46731c1f7f111ec7a41ce38a34594aa0d37/devtools/server/actors/thread.js#1762 , which will call removeAllWatchpoints and disableAllBreakpoints.

    this.removeAllWatchpoints();
    this.disableAllBreakpoints();

On top of that the BrowsingContextTargetActor will also emit a fake window-ready event at https://searchfox.org/mozilla-central/rev/4f05a46731c1f7f111ec7a41ce38a34594aa0d37/devtools/server/actors/targets/browsing-context.js#1429-1435

The thread-actor will perform even more cleanup there: https://searchfox.org/mozilla-central/rev/4f05a46731c1f7f111ec7a41ce38a34594aa0d37/devtools/server/actors/thread.js#1740-1747

      this.sourcesManager.reset();
      this.clearDebuggees();
      this.dbg.enable();

We could check isFrameSwitching in both callbacks in order to bypass this cleanup. If I do that, the breakpoints seem to be preserved, however the Debugger Source Tree seems broken for me after a frame-switch.

So, yes there's an issue with the fact that the UI is not reflecting correctly what the backend knows. Fixing this might be easier than trying to fix all the issues I mentioned above.

I can't reproduce the initial issue with the addon.
Here's what I tried (with Fission and EFT enabled):

1. On http://janodvarko.cz/tests/fission/case1/index.html
2. Open the debugger
3. Set a breakpoint on odvarko.com.js, in the first line of postRequest (should be line 4)
4. In the iframe picker, select odvarko.com
5. Click on the POST button in the iframe

-> the debugger does stop

I don't think this issue is blocking Bug 1608054 now (but rather the opposite, the work done for it fixed this issue, as we don't fake any navigation with the EFT codepath)