1768475 - Inspector Empty - FF Developer Edition only - after Reload with deactivated Browser Cache the Inspector is Empty

Status: RESOLVED FIXED

(DevTools :: Inspector, defect, P1)

Description

[j.geiger]

Steps to reproduce:

Go to e.g. https://www.youtube.com

right click : Inspect Element ( Devtools - Inspector opens)
Inspector is filled with HTML Document.
Reload Website
Inspector is empty
(If you active the Browser-Cache under Network Panel, it loads correctly)

Actual results:

Inspector is when openend with deactivated Browsercache, after Reload empty.
Happens since Edition V 100 . Developer Edition.

Expected results:

See the HTML Structure

Comment 1

[j.geiger]

My Edition :
Windows 101.0b4 (64-Bit)

Comment 2

[Albert Scheiner [:alberts]]

Confirmed on macOS 12.3.1, 101.0b4

Edit: for me the inspector is empty either way on Youtube. I need to close and reopen the devtools panel to get the DOM back. Tested on a local example where I am having that issue rather randomly appear since yesterday.
I now just toggled the "Disable Cache" several times, straight going back to the Inspector tab and reloading as well as closing and reopening the Dev tools in between. The DOM was empty two out of ~12 times, but couldn't find a connection between the two.

Comment 3

[j.geiger]

After some more testing, i am relative sure, that there is a timeout problem with
the inspector. By toggling the cache - and the inspector can fast-load his content -
the problem is for the inspector away, but inside our development environment with
big / unpacked files this effect is a big problem.

there are some tickets:

https://bugzilla.mozilla.org/show_bug.cgi?id=1766279
Stop waiting on DOMContentLoaded to initialize the walker

https://bugzilla.mozilla.org/show_bug.cgi?id=1203718
Inspector tree view disappears after a period of use

which are pointing to the same directon.

@[e-mail]
But .. to solve it by a 500ms timeout is not the right path, because
if your environment is behind a slow connection or big-file sizes, that
effect / timeout will not catch.

I hope we find a fast solution, because by this effect its nearly impossible
to work / develop with this issue.

Comment 4

[s.stoqnov]

Happens for me too after v100. Toggling 'Disable cache' doesn't fix the issue. I need to close/open the DevTools, very annoying.

Windows 11, 101.0b7 (64-bit)

Comment 5

[Julian Descottes [:jdescottes]]

Thanks for the report, but even if the timeout is reached, initializing the inspector while the document is loading should not break. We want to wait for DOMContentLoaded when possible, but in theory the inspector should initialize fine even if the document is still loading.

That being said I can consistently reproduce on youtube, so let's figure out a fix quickly here and uplift this to beta.

Comment 6

[Julian Descottes [:jdescottes]]

I think the issue comes specifically from https://searchfox.org/mozilla-central/rev/da6a85e615827d353e5ca0e05770d8d346b761a9/devtools/server/actors/inspector/walker.js#294

The conditions to match to reproduce the race issue are:

• return early when we create the walker because of the 500ms timeout added in Bug 1765760
• legacy rootnode listener calls watchRootNode :
  • after the target actor emitted "window-ready"
  • but before the document reaches the interactive state (note that this does not necessarily match DOMContentLoaded)

In that case, WalkerActor:watchRootNode will not return any root node but there will be no event to emit a root node at a later time either.
We could remove the check for isDocumentReady(this.rootDoc), which would mean that if the walker has been initialized, we assume it's safe to return a root node. It would also be in line with the fix from Bug 1765760.

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 10

[Julian Descottes [:jdescottes]]

Attachment: Bug 1768475 - [devtools] WalkerActor watchRootNode should not check isDocumentReady

If the walker actor was initialized, we assume the document is ready enough and a root node can be returned if available.

A new test was added for a slow loading document.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f66a41bd559d
[devtools] WalkerActor watchRootNode should not check isDocumentReady r=devtools-reviewers,nchevobbe

Comment 12

[Julian Descottes [:jdescottes]]

Comment on attachment 9276734 [details]
Bug 1768475 - [devtools] WalkerActor watchRootNode should not check isDocumentReady

Beta/Release Uplift Approval Request

• User impact if declined: Reloading a "slow" page while the inspector is open leads to a blank inspector.

You can easily test this by opening youtube, opening the inspector and reloading the page. Depending on the load it might not always be blank, but on my machine it's pretty frequent.

(the patch is not on central yet, but the beta uplift window is almost over so I prefer to make this visible asap)

• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: Bug 1769701
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The change only impacts devtools users, is a small javascript change.

In Bug 1765760 we stopped waiting for documents to be fully initialized to start the DevTools Inspector. But there was one codepath left to update, which was not involved in the scenario we focused on for Bug 1765760. So we are just making the logic more consistent with Bug 1765760 here, and we are not introducing any new logic.

• String changes made/needed:
• Is Android affected?: No

Comment 13

[Julian Descottes [:jdescottes]]

I added Bug 1769701 in the List of other uplifts needed after the fact, it's a test-verify only failure so far (I think it's CHAOSMODE specific) but it might still be better to uplift it together with this patch. It's a test-only change.

Comment 14

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/f66a41bd559d

Comment 15

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9276734 [details]
Bug 1768475 - [devtools] WalkerActor watchRootNode should not check isDocumentReady

Approved for 101.0b8.

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/d80f76406016

Comment 18

[j.geiger]

Thanks for your work. The Bug is with 101.0b8 away.