Issue metadata
Sign in to add a comment
|
DevTools: elements inspection broken (body tag content is hidden) after refresh
Reported by
david.kl...@hsn.net,
Apr 6 2018
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.66 Safari/537.36 Steps to reproduce the problem: 1. Open https://www.hsn.com 2. Open developer tools, expand body tag and click on an element 3. Leave tab and dev tools window open for a long period of time (several hours, overnight, etc). Also seems to occur on tabs that are not open for a long period of time, but I notice it more on tabs that are open for a long period of time. 4. After the time has passed, refresh (F5) 5. On the Elements tab, the body tag arrow is pointing down to indicate that it is expanded, but no content appears What is the expected behavior? The DOM content in the body tag should appear and not be hidden. What went wrong? The DOM content in the body tag is hidden. Inspecting elements on the page does not resolve. Only resolution is to use Ctrl+R on the dev tools window, or to refresh the page. Did this work before? Yes 65 Chrome version: 66.0.3359.66 Channel: n/a OS Version: 10.0 Flash Version: I've noticed this in beta. I haven't yet encountered it in stable or canary, but I also don't use them regularly.
,
Apr 6 2018
Also, the resolution uses Alt+R in dev tools window, not Ctrl+R.
,
Apr 6 2018
Next time that happens, press Ctrl-Shift-i to invoke devtools-for-devtools and copy the errors from its console here. Note, the original devtools should be in an undocked mode for this to work.
,
Apr 6 2018
shell.js:7847 Main._showAppUI: 19.53515625ms
shell.js:7847 Main._createAppUI: 53.68896484375ms
shell.js:7847 Main._initializeTarget: 18.343017578125ms
shell.js:7847 Main._lateInitialization: 8.428955078125ms
elements_module.js:506 Uncaught TypeError: Cannot read property 'nodeType' of null
at Elements.ElementsTreeOutline.findTreeElement (elements_module.js:506)
at Elements.ElementsTreeOutline._innerUpdateChildren (elements_module.js:672)
at Elements.ElementsTreeOutline._updateChildren (elements_module.js:662)
at Elements.ElementsTreeOutline._updateModifiedParentNode (elements_module.js:631)
at Elements.ElementsTreeOutline._updateModifiedNodes (elements_module.js:623)
,
Apr 6 2018
Thanks for the report, and the trace. It seems there is a race condition in the update/populate logic in ElementsTreeOutline. I'll take a look.
,
Apr 12 2018
The issue also seems to not occur if I'm not on the Elements tab when refreshing, even if it has occurred on the same browser tab previously.
,
Apr 19 2018
Yes, I have the same problem.
,
Apr 20 2018
Issue 834657 has been merged into this issue.
,
Apr 26 2018
I'm having the exact same issue, I hadn't run into it before the latest update to 66.0.3359.117. I was able to make it happen consistently by: 1. Selecting a child of the body 2. Refreshing 3. Selecting the body tag 4. Refreshing The child I selected in step 1 is initialized through a backbone application, so it doesn't exist until ~1s after the backbone application has started (which is ~4 seconds into the performance profile after a page reload). I attached a gif of the element inspector when the bug occurs to this message.
,
Apr 27 2018
I think this is related to Issue 836390 . It seems like the DevTools are hanging on to the old page context while the refreshed page is being treated as a new context. When this happens, try just running "1 + 1" in the console and you'll see you can't press enter.
,
May 2 2018
I encountered this issue too, and tested in Canary - problem still exists there.
,
May 2 2018
Same problem here, any ideas on how to fix this or new update with the fix. Don't really want to switch to Firefox for developing.
,
May 5 2018
Same problem after update( I use this workaround, instead of updating the whole page: 1) Delete <body> in dev-inspector 2) Ctrl+z 3) <body> now created correctly
,
May 6 2018
Happens also to me, it's critical bug. Please fix it ASAP!!! For now I switch to FF, it's impossible to develop like this.
,
May 7 2018
Yes, It's absolutely inconvenient for developing.
,
May 8 2018
Issue 840458 has been merged into this issue.
,
May 8 2018
If this happens do you, a quick workaround is to press Alt+R to reload the DevTools. Then the elements panel will work properly (until the bug happens again at least).
,
May 8 2018
,
May 9 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2e5ad0a88b7d04fe1aac8b2fd0c26b2d3475e4c2 commit 2e5ad0a88b7d04fe1aac8b2fd0c26b2d3475e4c2 Author: Erik Luo <luoe@chromium.org> Date: Wed May 09 10:10:41 2018 DevTools: fix mismatch between DOMNode childNodeCount and children Expanding an ElementsTreeElement used to immediately set a populated flag to true before requesting getChildNodes(). If a ChildNodeCountUpdated event arrives before the children are set, we may call updateModifiedParentNode() and try to create visibleChildren when they are null, breaking the tree. This CL moves the place where 'populated' is set, so that updateModifiedParentNode() does not update tree children before they are available. Bug: 829884 Change-Id: Id68e71fb7a58336d781207b298a53354af3e5cfc Reviewed-on: https://chromium-review.googlesource.com/1049113 Commit-Queue: Erik Luo <luoe@chromium.org> Reviewed-by: Andrey Lushnikov <lushnikov@chromium.org> Reviewed-by: Joel Einbinder <einbinder@chromium.org> Cr-Commit-Position: refs/heads/master@{#557132} [add] https://crrev.com/2e5ad0a88b7d04fe1aac8b2fd0c26b2d3475e4c2/third_party/WebKit/LayoutTests/http/tests/devtools/elements/elements-child-node-count-mismatch-expected.txt [add] https://crrev.com/2e5ad0a88b7d04fe1aac8b2fd0c26b2d3475e4c2/third_party/WebKit/LayoutTests/http/tests/devtools/elements/elements-child-node-count-mismatch.js [modify] https://crrev.com/2e5ad0a88b7d04fe1aac8b2fd0c26b2d3475e4c2/third_party/blink/renderer/devtools/front_end/elements/ElementsTreeElement.js [modify] https://crrev.com/2e5ad0a88b7d04fe1aac8b2fd0c26b2d3475e4c2/third_party/blink/renderer/devtools/front_end/elements/ElementsTreeOutline.js
,
May 9 2018
Seems like this is regressed in M66 per comment #0. Is this indeed a blocker for M67 stable? If it is indeed a blocker for M67 stable, how safe is the fix listed at #19 to merge to M67?
,
May 9 2018
The fix in #19 has not landed in Canary yet (as of 68.0.3425). I'd like to wait for at least one or two Canaries before merging to M67. If others are fine, I would be comfortable with sending a merge request on Friday so that it can be on Beta-67 Monday.
,
May 9 2018
This is indeed an M67 blocker. The fix is a two-liner, should be safe unless we see any other regressions in upcoming Canary. Let's wait a day or two and then request a merge.
,
May 9 2018
Pls update the bug with canary result on Friday morning and request a merge to M67. Thank you.
,
May 10 2018
This bug is not restricted to windows. I am also frequently encountering it on OSX. Currently running OSX 10.13.4 High Sierra, and Chrome Version 66.0.3359.139
,
May 10 2018
,
May 10 2018
Thanks to everyone commenting on this report. The fix has landed on Canary channel (68.0.3426.0), so if you continue to see the issue on that version or later, please let us know.
,
May 10 2018
*** Bulk Edit *** M67 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. If fix is already merged to M67 and nothing else is pending, pls mark the bug as fixed. Thank you.
,
May 11 2018
The NextAction date has arrived: 2018-05-11
,
May 11 2018
Tested the issue on chrome reported version 66.0.3359.66 using Mac 10.12.6 with steps mentioned in Comment# 0 & 9: 1) Launched chrome reported version and navigated to URL: https://www.hsn.com 2) Opened Devtools, expand body tag, selected one element and left the system idle for 20-25 min, after that clicked on refresh, able to see all the elements in body expand mode Observation: Also tested the issue by the steps mentioned in comment#9, navigated to www.google.com, Opened Devtools, expand body tag, selected one element clicked on refresh, able to see all the elements and body tag in expand mode Erik Luo: Please find the attached screencast for your reference and let us know if we missed anything in reproducing the issue and help us in confirming the fix. Thanks!
,
May 11 2018
,
May 11 2018
,
May 11 2018
This bug requires manual review: M67 has already been promoted to the beta branch, so this requires manual review Please contact the milestone owner if you have questions. Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), govind@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 11 2018
To better reproduce the error, navigate to a page that adds DOM nodes on timer. If node is expanded in Elements panel concurrently with that timer, node shows as empty. The fix is safe, the test added with the fix tests this particular case. I also verified it locally.
,
May 11 2018
Thank you pfeldman@. Approving merge to M67 branch 3396 based on comment #35. Pls merge ASAP and mark bug as fixed if nothing else is pending.
,
May 11 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/31575732e47f1043ae1bc9386a8d4438a1802241 commit 31575732e47f1043ae1bc9386a8d4438a1802241 Author: Erik Luo <luoe@chromium.org> Date: Fri May 11 17:11:42 2018 Merge of DevTools: fix mismatch between DOMNode childNodeCount and children Expanding an ElementsTreeElement used to immediately set a populated flag to true before requesting getChildNodes(). If a ChildNodeCountUpdated event arrives before the children are set, we may call updateModifiedParentNode() and try to create visibleChildren when they are null, breaking the tree. This CL moves the place where 'populated' is set, so that updateModifiedParentNode() does not update tree children before they are available. Bug: 829884 Change-Id: Id68e71fb7a58336d781207b298a53354af3e5cfc Reviewed-on: https://chromium-review.googlesource.com/1049113 Commit-Queue: Erik Luo <luoe@chromium.org> Reviewed-by: Andrey Lushnikov <lushnikov@chromium.org> Reviewed-by: Joel Einbinder <einbinder@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#557132}(cherry picked from commit 2e5ad0a88b7d04fe1aac8b2fd0c26b2d3475e4c2) Reviewed-on: https://chromium-review.googlesource.com/1055707 Reviewed-by: Erik Luo <luoe@chromium.org> Cr-Commit-Position: refs/branch-heads/3396@{#567} Cr-Branched-From: 9ef2aa869bc7bc0c089e255d698cca6e47d6b038-refs/heads/master@{#550428} [add] https://crrev.com/31575732e47f1043ae1bc9386a8d4438a1802241/third_party/WebKit/LayoutTests/http/tests/devtools/elements/elements-child-node-count-mismatch-expected.txt [add] https://crrev.com/31575732e47f1043ae1bc9386a8d4438a1802241/third_party/WebKit/LayoutTests/http/tests/devtools/elements/elements-child-node-count-mismatch.js [modify] https://crrev.com/31575732e47f1043ae1bc9386a8d4438a1802241/third_party/blink/renderer/devtools/front_end/elements/ElementsTreeElement.js [modify] https://crrev.com/31575732e47f1043ae1bc9386a8d4438a1802241/third_party/blink/renderer/devtools/front_end/elements/ElementsTreeOutline.js
,
May 11 2018
,
May 14 2018
Issue 842849 has been merged into this issue.
,
May 17 2018
,
May 21 2018
,
May 24 2018
Issue 846216 has been merged into this issue.
,
May 28 2018
Issue 846744 has been merged into this issue.
,
May 28 2018
Issue 846979 has been merged into this issue. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by david.kl...@hsn.net
, Apr 6 2018