2021329 - Dev tools inspector initially blank using some websites

Status: NEW

(DevTools :: General, defect, P2)

Description

[t31os]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:148.0) Gecko/20100101 Firefox/148.0

Steps to reproduce:

Opening a website, such as a fandom wiki, a wiki.gg wiki or stackoverflow, then opening the dev tools (must be closed initially).

I ran profiling in FF briefly on a test profile, with only stylus enabled and captured this issue occuring:

https://share.firefox.dev/3MK3vfB

Actual results:

The dev tools fails to render the dom in the inspector, it shows up completely blank. Refreshing the page once the dev tools are open then correctly shows the dom.

This is intermittent and won't always occur, and won't happen if the dev tools are already open on the page, and can be worked around by simply refreshing the page with dev tools open.

It appears there's some kind of race condition between stylus and the dev tools inspector, which doesn't occur in FF 147.

Expected results:

The inspector should show the dom, like it typically would for any website and did previously in FF 147, or with the stylus extension disabled.

Tested in fresh profiles, with and without other extensions, with and without styles active in stylus.

Sorry if this is a poor bug report, it's my first time.

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Rob Wu [:robwu]]

Reproduced in Firefox 148.0. I used the following STR:

1. Install Stylus add-on (version 2.3.19).
2. Visit stackoverflow.com, refresh page, Inspect Element.
3. If the bug did not reproduce, I opened a new tab, closed the previous one and repeated step 2.

Although the report claims that it worked in 147, when I ran mozregression, I could reproduce the issue on versions before 147. At first I tried to go back yet another version, but then I took larger steps, ultimately 128, and finally 115. I did not try older versions.

In the STR above I reload the page twice since I suspect content scripts to be relevant to the reproduction. Extension content scripts are compiled and cached in the process, which makes reproduction more deterministic. The Stylus extension has a content script that runs everywhere, I tried modified versions of Stylus (dropping "run_at": "document_start", "all_frames": true, "match_about_blank": true, "match_origin_as_fallback": true,), and still reproduced. The issue even continued to reproduce with "content_scripts": [{ "matches": ["*://stackoverflow.com/*"], "js": ["js/apply.js"]}] which rules out extension framework impact relating to document_start parser blocking, early script execution, etc. Dropping the content script entirely however makes the problem go away.

At this point I think that it is far more likely to be a DevTools issue than an extension issue.

The Browser Console shows the following with Multiprocess mode enabled:

Error while calling actor 'domwalker's method 'getNodeActorFromContentDomReference' can't access dead object
TypeError: can't access dead object in getDOMListeners at event-collector.js:278

In the parent process, the following is logged:

TypeError: can't access property "elt", this.getContainer(...) is undefined in maybeNavigateToNewSelection at markup.js:1284

Not sure if related, but during reproduction I also encountered the following once:

The Web Developer Tools panel has crashed.
Error: Protocol error (SecurityError): Permission denied to access property "performance" on cross-origin object from: server0.conn0.watcher3 (resource://devtools/server/actors/resources/console-messages.js:93:7)

Comment 3

[Julian Descottes [:jdescottes]]

I can reproduce easily on Release 148 and DevEdition 149, but not on Nightly nor local builds. At the moment. Not sure if that relates to the channel or to something we fixed.

Comment 4

[Julian Descottes [:jdescottes]]

I tried with Nightly build from 149, and could reproduce the issue, so it might have been fixed in 150. We should still identify what fixed it and whether we might still have similar issues in the future.

Comment 5

[Julian Descottes [:jdescottes]]

Maybe it's just very intermittent, I can't find a regression (or fix) window, and now I can't even get the failure on any channel.
I looked at each of the errors reported here and the only one which seems to fully break the devtools is the events collector one.

On the client side, we must be in the following

onPacket resource://devtools/shared/protocol/Front.js:404
    DevTools RDP*request resource://devtools/shared/protocol/Front.js:320
    name resource://devtools/shared/protocol/Front/FrontClassWithSpec.js:57
    querySelector resource://devtools/client/fronts/walker.js:150
    defaultNodeSelectors resource://devtools/client/inspector/inspector.js:699
    #getDefaultNodeForSelection resource://devtools/client/inspector/inspector.js:706

We are waiting for #getDefaultNodeForSelection in order to initialize the markup view at https://searchfox.org/firefox-main/rev/e67dad5c526f22744f22e5e1173213c9c5811df8/devtools/client/inspector/inspector.js#421-440

try {
  const defaultNode = await this.#getDefaultNodeForSelection(rootNodeFront);
  if (!defaultNode) {
    return;
  }

  this.selection.setNodeFront(defaultNode, {
    reason:
      this.#defaultStartupNodeSelectionReason ??
      "inspector-default-selection",
  });
  this.#defaultStartupNodeSelectionReason = null;

  await this.#initMarkupView();

  // Setup the toolbar again, since its content may depend on the current document.
  this.#setupToolbar();
} catch (e) {
  this.#handleRejectionIfNotDestroyed(e);
}

So here the default node we try to select must be somehow a dead object. When building the form for the element, we throw when getting the listeners, and the RDP command is rejected.

I think it should be relatively safe to "retry" getting the default node.

It's also interesting to note that #getDefaultNodeForSelection tries several strategies to get a default node front, but it's not try catching around them (see here)

Comment 6

[Rob Wu [:robwu]]

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

Maybe it's just very intermittent, I can't find a regression (or fix) window, and now I can't even get the failure on any channel.

When I tried to bisect before it was not reproducing 100% all the time, so I just repeated the STR a few times if it did not immediately reproduce. I guess that you can try 10 times for good measure, and if it still does not work, conclude that it has really been fixed.

Comment 7

[Julian Descottes [:jdescottes]]

(In reply to Rob Wu [:robwu] from comment #6)

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

Maybe it's just very intermittent, I can't find a regression (or fix) window, and now I can't even get the failure on any channel.

When I tried to bisect before it was not reproducing 100% all the time, so I just repeated the STR a few times if it did not immediately reproduce. I guess that you can try 10 times for good measure, and if it still does not work, conclude that it has really been fixed.

I was testing around 20 times per version. But at some point it was never failing on any version, even when testing on versions where I did reproduce the issue an hour ago. Maybe that depends on the connection & various other parameters.

Comment 8

[t31os]

I was hopeful the update to v150 today was going to resolve this issue (as it seems to be marked as unaffected for v150), but testing a brand new profile with only stylus installed (no styles created/active) still results in the same render bug. I can consistently get this to trigger on pages of fandom wikis, so that's how i usually test.

Not sure what i can offer to help, but if there's anything not overly technical i can do to help this along, please let me know.

Comment 9

[Julian Descottes [:jdescottes]]

(In reply to t31os from comment #8)

I was hopeful the update to v150 today was going to resolve this issue (as it seems to be marked as unaffected for v150), but testing a brand new profile with only stylus installed (no styles created/active) still results in the same render bug.

Sorry about the 150 flag, I set those when trying to reproduce the issue initially before I realized this was too flaky (at least on my machine) for a typical non-regression test.

I can consistently get this to trigger on pages of fandom wikis, so that's how i usually test.

If you can share specifics: which URL are you using, and how exactly do you open DevTools (via right click Inspect Element?) this could help reproducing the issue. I was mostly testing on slack overflow, but maybe that's not the best test page.

Comment 10

[t31os]

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

If you can share specifics: which URL are you using, and how exactly do you open DevTools (via right click Inspect Element?) this could help reproducing the issue. I was mostly testing on slack overflow, but maybe that's not the best test page.

Most article pages on fandom wikis will trigger the issue, here's a couple to test on:

https://nomanssky.fandom.com
https://for-all-mankind.fandom.com

(i quickly checked these two as a test before writing this reply)

I regularly use both F12 and inspect (depending on what i'm doing), and it doesn't seem to have any inpact on whether the bug occurs.

The issue is not 100% consistent either, sometimes pages will load, i'll open up dev tools and the inspector will load correctly, but i'd ballpark it's around 5% or less of the time.

If you hop around a bunch of random article pages (Explore > Random Page from the nav) on one of the above wikis, making sure the dev tools is initially closed when loading the page, and then opening it after or during the page load, that should be enough to trigger it (at least if stylus is installed).

I also have nightly (with ubo and stylus) installed separately (fresh install/profile), exactly same issue there.

When firing up the second wiki above (and getting the bug) in nightly with the console from Browser Toolbox open, i can see the following in the console (if these are at all relevant):

[Error] NotFoundError: No such JSProcessActor 'DevToolsProcess

[Error]AbortError: Actor 'Conduits' destroyed before query 'RuntimeMessage' was resolved

[Warning] Couldn't retrieve node front from dom reference Object { browsingContextId: 34, id: 0.1917913262762505 } inspector.js:671:17

[Error] TypeError: can't access property "elt", this.getContainer(...) is undefined markup.js:1290:12