Debugger not pausing in iframes on breakpoints set for the main page
Categories
(DevTools :: Debugger, defect, P3)
Tracking
(Not tracked)
People
(Reporter: a.minyukovich, Unassigned)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:88.0) Gecko/20100101 Firefox/88.0
Steps to reproduce:
- Have a content script loaded in both the main page and iframes (I work on an addon)
- Open dev tools, set a breakpoint
- Change the "targeted document" to an iframe
- Watch the breakpoint being shown, but ignored.
- 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.
Updated•3 years ago
|
Comment 1•3 years ago
|
||
Thanks for the report.
Any chance to get your add-on to try to reproduce the issue on our machines?
Honza
Reporter | ||
Comment 2•3 years ago
|
||
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.
Comment 3•3 years ago
|
||
- 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
Updated•3 years ago
|
Reporter | ||
Comment 4•3 years ago
|
||
Reporter | ||
Comment 5•3 years ago
|
||
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
Comment 6•3 years ago
•
|
||
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.
Comment 7•3 years ago
|
||
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.
Updated•3 years ago
|
Comment 8•3 years ago
|
||
I can't reproduce the initial issue with the addon.
Here's what I tried (with Fission and EFT enabled):
- On http://janodvarko.cz/tests/fission/case1/index.html
- Open the debugger
- Set a breakpoint on
odvarko.com.js
, in the first line ofpostRequest
(should be line 4) - In the iframe picker, select
odvarko.com
- 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)
Description
•