Issue metadata
Sign in to add a comment
|
Regression: Elements are no longer selected in devTools after page refresh
Reported by
zrubinra...@gmail.com,
Sep 9 2016
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.101 Safari/537.36 Steps to reproduce the problem: 1) Go to http://images.google.com 2) Right click the logo and click 'inspect element' to see it selected in the elements panel of the devtools 3) Press CMD + R to refresh the page 4) After refresh, in the elements panel of the devtools, the selected element becomes the <html> element and not the one selected in step 2 What is the expected behavior? It should select the same element in the devtools element panel after refresh What went wrong? Chrome selected the <html> element instead of the one previously selected before the page refresh. Did this work before? Yes I want to say below Chrome 49 but I can't recall specifically Chrome version: 53.0.2785.101 Channel: stable OS Version: OS X 10.11.2 Flash Version: Shockwave Flash 22.0 r0 I've noticed this was a bug the past few releases and thought it would've been patched. Would be great to have this feature back! It would save web devs a lot of time hunting for the same element after a page refresh.
,
Sep 12 2016
Yup! Thanks for reporting. This is a regression, and a really inconvenient one. Thanks for setting P1, phistuck.
<div style="background-size:272px 92px;height:92px;width:272px" title="Google Images" align="left" id="hplogo" onload="window.lol&&lol()">
Is definitely in the HTML, so we shouldn't have any problem restoring the element selection.
+lushnikov to triage
,
Oct 11 2016
This is a really bad bug....any plans on fixing this?
,
Oct 13 2016
Hey, i got the same issue after i refresh the page - the selected item was no more longer selected. Please help, this is very important feature of the element-tab. Im on osx 10.11.x with latest chrome from today. best regards - alex
,
Oct 13 2016
As you can see no one cares even to reply if this will be addressed or not, after all it's a free product, so it looks like bugs like that tend to get ignored :))))
,
Oct 15 2016
Ohh, this is huge! Sorry, this slipped through my inbox - I'll take a look. We would need to merge this into M-55
,
Oct 17 2016
I have started using Firefox again, even though I really like the device emulation in Chrome. Please find a fix for this problem
,
Oct 17 2016
Just updated to the latest version, still the issue is present!!! any ETA when we might expect this annoying bug to be fixed?
,
Oct 20 2016
Still present, major issue. back to firefox developer for the time being
,
Oct 20 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9cb88eeb6589fb10e8b7e87c76b54ee16d2f844e commit 9cb88eeb6589fb10e8b7e87c76b54ee16d2f844e Author: lushnikov <lushnikov@chromium.org> Date: Thu Oct 20 17:54:45 2016 DevTools: properly restore selected DOMNode in Elements panel. Since the http://crrev.com/b4d6bf98e, we started sending two "documentUpdated" events for every page reload. It's not a bad thing by itself (but probably needs addressing in a follow-up), but the element restoration logic is unprepared for this. This patch re-writes the element restoring logic in the elements panel. BUG= 645645 Review-Url: https://chromiumcodereview.appspot.com/2428823002 Cr-Commit-Position: refs/heads/master@{#426525} [add] https://crrev.com/9cb88eeb6589fb10e8b7e87c76b54ee16d2f844e/third_party/WebKit/LayoutTests/inspector/elements/elements-panel-restore-selection-when-node-comes-later-expected.txt [add] https://crrev.com/9cb88eeb6589fb10e8b7e87c76b54ee16d2f844e/third_party/WebKit/LayoutTests/inspector/elements/elements-panel-restore-selection-when-node-comes-later.html [modify] https://crrev.com/9cb88eeb6589fb10e8b7e87c76b54ee16d2f844e/third_party/WebKit/LayoutTests/inspector/elements/elements-panel-rewrite-href-expected.txt [modify] https://crrev.com/9cb88eeb6589fb10e8b7e87c76b54ee16d2f844e/third_party/WebKit/LayoutTests/inspector/elements/elements-panel-rewrite-href.html [modify] https://crrev.com/9cb88eeb6589fb10e8b7e87c76b54ee16d2f844e/third_party/WebKit/Source/devtools/front_end/elements/ElementsPanel.js
,
Oct 20 2016
So when this fix will implemented into an new update, since you guys in case you didn't know make our life a leaving hell? Can you give an ETA when this will be fixed? And next time, make sure you test your updates before offering them up to the general public!
,
Oct 20 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/33eab73eaa7dc9020ca00a3fe1bcbf7ab131e0a0 commit 33eab73eaa7dc9020ca00a3fe1bcbf7ab131e0a0 Author: mathp <mathp@chromium.org> Date: Thu Oct 20 20:12:13 2016 Revert of DevTools: properly restore selected DOMNode in Elements panel. (patchset #6 id:100001 of https://chromiumcodereview.appspot.com/2428823002/ ) Reason for revert: inspector/elements/elements-panel-restore-selection-when-node-comes-later.html failed on two bots (and perhaps more). One example: https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Mac10.11%20%28dbg%29/builds/5419/steps/webkit_tests Original issue's description: > DevTools: properly restore selected DOMNode in Elements panel. > > Since the http://crrev.com/b4d6bf98e, we started > sending two "documentUpdated" events for every > page reload. > > It's not a bad thing by itself (but probably needs > addressing in a follow-up), but the element restoration > logic is unprepared for this. > > This patch re-writes the element restoring logic in the > elements panel. > > BUG= 645645 TBR=pfeldman@chromium.org,dgozman@chromium.org,lushnikov@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= 645645 Review-Url: https://chromiumcodereview.appspot.com/2434343002 Cr-Commit-Position: refs/heads/master@{#426577} [delete] https://crrev.com/5afeb69d7607d1d31b98b16d1cfcfc98dd2b0f0b/third_party/WebKit/LayoutTests/inspector/elements/elements-panel-restore-selection-when-node-comes-later-expected.txt [delete] https://crrev.com/5afeb69d7607d1d31b98b16d1cfcfc98dd2b0f0b/third_party/WebKit/LayoutTests/inspector/elements/elements-panel-restore-selection-when-node-comes-later.html [modify] https://crrev.com/33eab73eaa7dc9020ca00a3fe1bcbf7ab131e0a0/third_party/WebKit/LayoutTests/inspector/elements/elements-panel-rewrite-href-expected.txt [modify] https://crrev.com/33eab73eaa7dc9020ca00a3fe1bcbf7ab131e0a0/third_party/WebKit/LayoutTests/inspector/elements/elements-panel-rewrite-href.html [modify] https://crrev.com/33eab73eaa7dc9020ca00a3fe1bcbf7ab131e0a0/third_party/WebKit/Source/devtools/front_end/elements/ElementsPanel.js
,
Oct 21 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/247328a16045ca03a0684b76cf1f7de988550453 commit 247328a16045ca03a0684b76cf1f7de988550453 Author: lushnikov <lushnikov@chromium.org> Date: Fri Oct 21 05:14:13 2016 DevTools: properly restore selected DOMNode in Elements panel. Since the http://crrev.com/b4d6bf98e, we started sending two "documentUpdated" events for every page reload. It's not a bad thing by itself (but probably needs addressing in a follow-up), but the element restoration logic is unprepared for this. This patch re-writes the element restoring logic in the elements panel. BUG= 645645 Review-Url: https://chromiumcodereview.appspot.com/2428823002 Cr-Commit-Position: refs/heads/master@{#426732} [add] https://crrev.com/247328a16045ca03a0684b76cf1f7de988550453/third_party/WebKit/LayoutTests/inspector/elements/elements-panel-restore-selection-when-node-comes-later-expected.txt [add] https://crrev.com/247328a16045ca03a0684b76cf1f7de988550453/third_party/WebKit/LayoutTests/inspector/elements/elements-panel-restore-selection-when-node-comes-later.html [modify] https://crrev.com/247328a16045ca03a0684b76cf1f7de988550453/third_party/WebKit/LayoutTests/inspector/elements/elements-panel-rewrite-href-expected.txt [modify] https://crrev.com/247328a16045ca03a0684b76cf1f7de988550453/third_party/WebKit/LayoutTests/inspector/elements/elements-panel-rewrite-href.html [modify] https://crrev.com/247328a16045ca03a0684b76cf1f7de988550453/third_party/WebKit/Source/devtools/front_end/elements/ElementsPanel.js
,
Oct 23 2016
So grateful this is fixed! Thank you everyone so much!! For whom do I buy the coffee??
,
Oct 24 2016
Strange, I'm using the latest version and still the same stupid bug is still present, can you please let me know how can I fix it on my end? Thank you in advance Best Regards.
,
Oct 24 2016
Very odd - it was working for me yesterday. I did the same test in the OP. I guess this still needs to be fixed! :(
,
Oct 24 2016
Yeah, looks like the fix is not perfect. Let me work on it a bit more
,
Oct 26 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/882009f9a7c57c3351930bd768fb9bbe859d4d31 commit 882009f9a7c57c3351930bd768fb9bbe859d4d31 Author: lushnikov <lushnikov@chromium.org> Date: Wed Oct 26 08:49:29 2016 Revert of DevTools: properly restore selected DOMNode in Elements panel. (patchset #7 id:120001 of https://chromiumcodereview.appspot.com/2428823002/ ) Reason for revert: Reverting this patch since it doesn't eliminate issue. Original issue's description: > DevTools: properly restore selected DOMNode in Elements panel. > > Since the http://crrev.com/b4d6bf98e, we started > sending two "documentUpdated" events for every > page reload. > > It's not a bad thing by itself (but probably needs > addressing in a follow-up), but the element restoration > logic is unprepared for this. > > This patch re-writes the element restoring logic in the > elements panel. > > BUG= 645645 > > Committed: https://crrev.com/247328a16045ca03a0684b76cf1f7de988550453 > Cr-Commit-Position: refs/heads/master@{#426732} TBR=pfeldman@chromium.org,dgozman@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG= 645645 Review-Url: https://codereview.chromium.org/2446163004 Cr-Commit-Position: refs/heads/master@{#427640} [delete] https://crrev.com/da2fbf1044f2628db304a54dce0141a2d40b2d1f/third_party/WebKit/LayoutTests/inspector/elements/elements-panel-restore-selection-when-node-comes-later-expected.txt [delete] https://crrev.com/da2fbf1044f2628db304a54dce0141a2d40b2d1f/third_party/WebKit/LayoutTests/inspector/elements/elements-panel-restore-selection-when-node-comes-later.html [modify] https://crrev.com/882009f9a7c57c3351930bd768fb9bbe859d4d31/third_party/WebKit/LayoutTests/inspector/elements/elements-panel-rewrite-href-expected.txt [modify] https://crrev.com/882009f9a7c57c3351930bd768fb9bbe859d4d31/third_party/WebKit/LayoutTests/inspector/elements/elements-panel-rewrite-href.html [modify] https://crrev.com/882009f9a7c57c3351930bd768fb9bbe859d4d31/third_party/WebKit/Source/devtools/front_end/elements/ElementsPanel.js
,
Oct 26 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f19c680112d1d6fc029b1463ceeb35b7a54297a4 commit f19c680112d1d6fc029b1463ceeb35b7a54297a4 Author: lushnikov <lushnikov@chromium.org> Date: Wed Oct 26 16:49:43 2016 Reland of DevTools: properly restore selected DOMNode in Elements panel. This patch is a reland of https://crrev.com/2428823002/, merged with https://crrev.com/2448963003. Since the http://crrev.com/b4d6bf98e, we started sending two "documentUpdated" events for every page reload. It's not a bad thing by itself (but probably needs addressing in a follow-up), but the element restoration logic is unprepared for this. This patch re-writes the element restoring logic in the elements panel so that we will try to restore to the last focused selected element. BUG= 645645 R=dgozman Review-Url: https://codereview.chromium.org/2449963004 Cr-Commit-Position: refs/heads/master@{#427715} [modify] https://crrev.com/f19c680112d1d6fc029b1463ceeb35b7a54297a4/third_party/WebKit/LayoutTests/http/tests/inspector/inspect-element.html [add] https://crrev.com/f19c680112d1d6fc029b1463ceeb35b7a54297a4/third_party/WebKit/LayoutTests/inspector/elements/elements-panel-restore-selection-when-node-comes-later-expected.txt [add] https://crrev.com/f19c680112d1d6fc029b1463ceeb35b7a54297a4/third_party/WebKit/LayoutTests/inspector/elements/elements-panel-restore-selection-when-node-comes-later.html [modify] https://crrev.com/f19c680112d1d6fc029b1463ceeb35b7a54297a4/third_party/WebKit/LayoutTests/inspector/elements/elements-panel-rewrite-href-expected.txt [modify] https://crrev.com/f19c680112d1d6fc029b1463ceeb35b7a54297a4/third_party/WebKit/LayoutTests/inspector/elements/elements-panel-rewrite-href.html [modify] https://crrev.com/f19c680112d1d6fc029b1463ceeb35b7a54297a4/third_party/WebKit/LayoutTests/inspector/elements/reveal-whitespace-text-node.html [modify] https://crrev.com/f19c680112d1d6fc029b1463ceeb35b7a54297a4/third_party/WebKit/LayoutTests/inspector/elements/shadow/inspect-deep-shadow-element.html [modify] https://crrev.com/f19c680112d1d6fc029b1463ceeb35b7a54297a4/third_party/WebKit/LayoutTests/inspector/elements/shadow/reveal-shadow-dom-node.html [modify] https://crrev.com/f19c680112d1d6fc029b1463ceeb35b7a54297a4/third_party/WebKit/Source/devtools/front_end/elements/ElementsPanel.js [modify] https://crrev.com/f19c680112d1d6fc029b1463ceeb35b7a54297a4/third_party/WebKit/Source/devtools/front_end/elements/ElementsTreeOutline.js
,
Oct 27 2016
Ok guys, now this seems to be working. Please, check it out in the latest Canary!
,
Oct 27 2016
,
Oct 27 2016
seems to be working in canary for me. can anyone else confirm?
,
Oct 27 2016
Working in Canary for me too. Thanks Devs! was starting to be a bit annoying. Another question regarding this. Using a front-end framework (like React or Angular) where the app DOM elements are created after the initial render, is there a way to reselect the DOM node in the app which was previously selected? As in: 1. Check if the previously selected DOM node exists 2. No, goto 1 3. Yes, goto 4 4. Select it 5. Profit! Currently it seems to check once on initial load and if it fails to locate the previously select node, that's it.
,
Oct 28 2016
We can try to restore the selected element during, say, 500ms after the page load. Would it work for you? This, however, is outside of the scope of this bug; let's continue discussion under crbug.com/592214
,
Oct 28 2016
Seems to be working fine for me on Chrome Mac Canary. Would be nice to have in M-55!
,
Oct 28 2016
Your change meets the bar and is auto-approved for M55 (branch: 2883)
,
Oct 28 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/36953eb34894422291cafa59f499fc27a74d7adf commit 36953eb34894422291cafa59f499fc27a74d7adf Author: Andrey Lushnikov <lushnikov@chromium.org> Date: Fri Oct 28 22:28:49 2016 Reland of DevTools: properly restore selected DOMNode in Elements panel. This patch is a reland of https://crrev.com/2428823002/, merged with https://crrev.com/2448963003. Since the http://crrev.com/b4d6bf98e, we started sending two "documentUpdated" events for every page reload. It's not a bad thing by itself (but probably needs addressing in a follow-up), but the element restoration logic is unprepared for this. This patch re-writes the element restoring logic in the elements panel so that we will try to restore to the last focused selected element. BUG= 645645 R=dgozman Review-Url: https://codereview.chromium.org/2449963004 Cr-Commit-Position: refs/heads/master@{#427715} (cherry picked from commit f19c680112d1d6fc029b1463ceeb35b7a54297a4) Review URL: https://codereview.chromium.org/2460953003 . Cr-Commit-Position: refs/branch-heads/2883@{#366} Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768} [modify] https://crrev.com/36953eb34894422291cafa59f499fc27a74d7adf/third_party/WebKit/LayoutTests/http/tests/inspector/inspect-element.html [add] https://crrev.com/36953eb34894422291cafa59f499fc27a74d7adf/third_party/WebKit/LayoutTests/inspector/elements/elements-panel-restore-selection-when-node-comes-later-expected.txt [add] https://crrev.com/36953eb34894422291cafa59f499fc27a74d7adf/third_party/WebKit/LayoutTests/inspector/elements/elements-panel-restore-selection-when-node-comes-later.html [modify] https://crrev.com/36953eb34894422291cafa59f499fc27a74d7adf/third_party/WebKit/LayoutTests/inspector/elements/elements-panel-rewrite-href-expected.txt [modify] https://crrev.com/36953eb34894422291cafa59f499fc27a74d7adf/third_party/WebKit/LayoutTests/inspector/elements/elements-panel-rewrite-href.html [modify] https://crrev.com/36953eb34894422291cafa59f499fc27a74d7adf/third_party/WebKit/LayoutTests/inspector/elements/reveal-whitespace-text-node.html [modify] https://crrev.com/36953eb34894422291cafa59f499fc27a74d7adf/third_party/WebKit/LayoutTests/inspector/elements/shadow/inspect-deep-shadow-element.html [modify] https://crrev.com/36953eb34894422291cafa59f499fc27a74d7adf/third_party/WebKit/LayoutTests/inspector/elements/shadow/reveal-shadow-dom-node.html [modify] https://crrev.com/36953eb34894422291cafa59f499fc27a74d7adf/third_party/WebKit/Source/devtools/front_end/elements/ElementsPanel.js [modify] https://crrev.com/36953eb34894422291cafa59f499fc27a74d7adf/third_party/WebKit/Source/devtools/front_end/elements/ElementsTreeOutline.js
,
Oct 28 2016
,
Oct 30 2016
Tested with the latest version of Chanary, on Mac Os, and it looks like it's working. when we will see this also resolved in the latest version of Chrome? Thank you in advance Best Regards.
,
Oct 31 2016
This was merged to the Chrome 55, which is in Beta now. Chrome 55 is estimated to be promoted to stable in the beginning of December, 2016. More on the dates and calendar: http://www.chromium.org/developers/calendar |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by phistuck@chromium.org
, Sep 9 2016Labels: -Type-Bug -Pri-2 OS-Windows Pri-1 Type-Bug-Regression
Status: Untriaged (was: Unconfirmed)