Closed Bug 1765760 Opened 3 years ago Closed 3 years ago

Blank inspector when opening DevTools on page with iframe stuck in "loading" readyState

Categories

(DevTools :: Inspector, defect, P1)

Product:
DevTools
Component:
Inspector
Platform:
Desktop
Unspecified
Type:
defect

Tracking

(firefox-esr91 unaffected, firefox99 wontfix, firefox100 wontfix, firefox101 verified)

Status:
VERIFIED FIXED
Milestone:
101 Branch
Tracking Flags:
Tracking Status
firefox-esr91 --- unaffected
firefox99 --- wontfix
firefox100 --- wontfix
firefox101 --- verified

People

(Reporter: rbucata, Assigned: jdescottes)

References

(Blocks 1 open bug, Regression,
URL
)

Details

(Keywords: regression)

Attachments

(3 files)

Screenshot_2.png
183.66 KB, image/png
Details
test_case.html
408 bytes, text/html
Details
Bug 1765760 - [devtools] Do not wait indefinitely for DOMContentLoaded in inspector actor getWalker
48 bytes, text/x-phabricator-request
Details | Review
Attached image Screenshot_2.png —

Environment:
Operating System: Windows 10 PRO x64
Operating System: Mac OSX 10.15.6
Firefox version:Firefox Nightly 101.0a1 (2022-04-21) (64-bit)

Preconditions:
ETP set to STRICT
Clean profile

Steps to reproduce:

  1. Navigate to: https://www.thetastebar.de/
  2. Trigger the DevTools "Inspect element" option.
  3. Observe the "Inspector" tab.

Expected Behavior:
DOM content is shown.

Actual Behavior:
DOM content is empty.

Notes:

  • Not reproducible with ETP set to OFF.
  • Works as expected using Chrome.
  • Screenshot is attached.
Priority: -- → P3

The issue seems intermittent and not ETP related. I'll move this to DevTools.

No longer blocks: tp-breakage
Component: Privacy: Anti-Tracking → Inspector
Product: Core → DevTools

The product::component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Priority: P3 → --

Seems to reproduce consistently on all operating system, will investigate.

Seems to work after reloading the page, so we only fail to open the inspector on first open.
The root node resource we expect is emitted, so not sure what blocks the initialization.

Severity: -- → S3
Flags: needinfo?(jdescottes)
Priority: -- → P2
See Also: → 1765389

Note that it seems to reproduce regardless of ETP (on, off, strict, standard, custom).

The only requirement is that the "chat" iframe button should be displayed on the bottom right. If you open devtools before that it will open correctly.

Flags: needinfo?(jdescottes)
Summary: DOM content is not shown in DevTools at with ETP set to STANDARD at thetastebar.de → DOM content is not shown in DevTools at thetastebar.de
Flags: needinfo?(jdescottes)

Some investigation from Alex.

The following call to watchResources never resolves: https://searchfox.org/mozilla-central/rev/6f6cf2810742d32454251afdb8e632c27999bea7/devtools/client/inspector/inspector.js#216-224, and on the server side, we can see that the inspector actor is stuck on a getWalker call: https://searchfox.org/mozilla-central/rev/6f6cf2810742d32454251afdb8e632c27999bea7/devtools/server/actors/inspector/inspector.js#144-149

The iframe for the "chat" widget never seems to get the DOMContentLoaded event on this page.

Also note that this issue only occurs when devtools.every-frame-target.enabled is set to true, so that's in practice a regression from Bug 1731740, but that's only a pref flip, and we probably don't want to back pedal here now.

Regressed by: 1731740
status-firefox100: --- → affected
status-firefox99: --- → affected
Flags: needinfo?(jdescottes)
Priority: P2 → P1
Summary: DOM content is not shown in DevTools at thetastebar.de → Blank inspector when opening DevTools on page with iframe stuck in "loading" readyState
Version: Firefox 101 → unspecified

Set release status flags based on info from the regressing bug 1731740

status-firefox-esr91: --- → unaffected

:nchevobbe, since you are the author of the regressor, bug 1731740, could you take a look?
For more information, please visit auto_nag documentation.

Flags: needinfo?(nchevobbe)

We are on it.

Assignee: nobody → jdescottes
Status: NEW → ASSIGNED
Flags: needinfo?(nchevobbe)

So as pointed out in Bug 1765389, this actually comes from the shopify chat iframe. This iframe remains in loading state until you click on the button to open the chat/

Reduced test case:

<!DOCTYPE html>
<html lang="en">
  <body>
    <script type="text/javascript">
      const iframe = document.createElement("iframe");
      iframe.src = "about:blank";
      iframe.addEventListener('load', () => {
        iframe.contentDocument.write('<!DOCTYPE html><html lang='.concat('en', '></html>'));
      }, true);
      document.body.appendChild(iframe);
    </script>
  </body>
</html>
Attached file test_case.html —
Attachment #9273300 - Attachment filename: file_1765760.txt → file_1765760.html
Attachment #9273300 - Attachment mime type: text/plain → text/html

So basically this is just another manifestation of Bug 1311694, the shopify chat uses document.write in an iframe, and never calls close.
I guess this rarely happens for the main document nowadays, but is much more likely to be done when building iframes dynamically. That on top of enabling devtools.every-frame-target.enabled which makes it so that any frame has the potential to brick the initialization of the inspector.

See Also: 1765389 → 1311694

Fixes the issue by waiting only 500ms max for the event

Has Regression Range: --- → yes

Short status: the issue is confirmed to be linked to the initialization of the inspector front of the target created for the chat iframe.
This iframe will remain indefinitely in loading state (called document.write without calling document.close), which breaks the getWalker method at https://searchfox.org/mozilla-central/rev/6f6cf2810742d32454251afdb8e632c27999bea7/devtools/server/actors/inspector/inspector.js#144-149

Based on that we have an easy workaround, which is just to cap the time we wait for the DOMContentLoaded event. This fixes the issue and doesn't seem to create new intermittents on try.

However it means that it's not clear why we are actually waiting for the event here. In theory, both the inspector and the walker should still be able to work with a "loading" document. But fully removing the event from this logic leads to various intermittent failures on try, which I can't reproduce locally for now. I will investigate a bit in that direction. Particularly I wonder if the new intermittents are not related to another spot which waits for iframe loads: nodeActor's waitForFrameLoad. For this helper it actually makes sense to wait: we use it amongst other things to be able to reselect a node, so we really would like the iframe to have a "stable" markup, so we can maximize the chances to find the node. But at the same time we also don't want to wait forever for the iframe, so adding some timeout would make sense.

So I think the fix for this issue will be one of the 2 options explained above:

  • either add a timeout for InspectorActor.getWalker
  • or to stop waiting completely for DOMContentLoaded in InspectorActor.getWalker

The second option seems preferable, but it's not clear to me if we can address the related intermittents quickly enough. It also feels more risky, and I would not feel confident asking for uplifts for this.

I think this bug also highlights an overall issue with the fact that a failure in a single actor for a single target can completely block one of our panels. We'll need to understand a bit more why the inspector is impacted so badly and if that is something which might also happen for other panels.

(In reply to Julian Descottes [:jdescottes] from comment #15)

I think this bug also highlights an overall issue with the fact that a failure in a single actor for a single target can completely block one of our panels. We'll need to understand a bit more why the inspector is impacted so badly and if that is something which might also happen for other panels.

After tracking this in a bit more details, this is probably quite specific to the inspector and the fact that we are using a legacy resource to watch for the ROOT_NODE:

If we had a real resource, this client side setup would not be necessary and the inspector initialization would be less fragile. Quite possibly the part of the markup view corresponding to the iframe would still have been broken/missing, but it would not have resulted in a fully blank panel.

Blocks: 1766279
Pushed by jdescottes@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/7cae87d1af62 [devtools] Do not wait indefinitely for DOMContentLoaded in inspector actor getWalker r=devtools-reviewers,nchevobbe

https://hg.mozilla.org/mozilla-central/rev/7cae87d1af62

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
status-firefox101: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 101 Branch
Flags: qe-verify+

Reproducible on Firefox 100.0(20220428192727) on Win10 64-bits. Verified as fixed on Firefox 101.0b6(20220512193916), Nightly 102.0a1(20220512213051) on Ubuntu 20.04, Win10 64-bits and macOS 11.

Status: RESOLVED → VERIFIED
status-firefox101: fixed → verified
Flags: qe-verify+
Regressions: 1768475
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: