In pages with heavy use of frames, a frame might trigger restore of a selected element after the inspected element has been highlighted. <rdar://problem/17971908>
Created attachment 236682 [details] [PATCH] Attempted fix.
Comment on attachment 236682 [details] [PATCH] Attempted fix. View in context: https://bugs.webkit.org/attachment.cgi?id=236682&action=review > Source/WebInspectorUI/ChangeLog:11 > + Change so if an element is inspected, restoreSelectedNodeIsAllowed is set to false > + and kept in that state until the main resource changes or is refreshed. This way an > + attempt by a frame on a page to restore a node will not change the highlighted > + element unexpectedly. There is a lot of ambiguity in this ChangeLog comment! How about something like: (emphasis mine and can be removed) Change so if an element is inspected *via the Inspect Element context menu*, selected node restoration is disallowed until the main resource *in the main frame* changes. This way an attempt by a *sub-frame* will not change the highlighted element in the Main Frame's DOM tree unexpectedly. > Source/WebInspectorUI/UserInterface/Controllers/DOMTreeManager.js:272 > + _mainResourceDidChange: function(event) { > + if (event.target.isMainFrame()) > + this._restoreSelectedNodeIsAllowed = true; > + }, Style: Opening brace should be on its own line Style: This function should be down at the bottom of this file in the Private section.
> until the main resource *in the main frame* changes Can just be until a page navigation / reload.
Created attachment 236695 [details] [PATCH] Attempted fix, review feedback.
Comment on attachment 236695 [details] [PATCH] Attempted fix, review feedback. Clearing flags on attachment: 236695 Committed r172662: <http://trac.webkit.org/changeset/172662>
All reviewed patches have been landed. Closing bug.