DevTools: Styles focus problem after an interstitial dialog

By presenting an interstitial dialog (like Ctrl+P), keyboarding
users might get to a point where they can't put focus back into
the styles pane. This is because tabIndex is set to -1 for all
of the style blocks.  Typically, losing focus causes the styles
list to reset the first style block to tabIndex=0, but only if
the style container doesn't already have focus. Because of an
event ordering issue, the styles still have focus before the
interstitials receive focus. This change allows the styles tree
elements to reset the styles when they lose focus.

Bug: 963183
Change-Id: I227c48fd88dbe46bbebc982b0c6e10232769d860
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1842521Reviewed-by: Lorne Mitchell <lomitch@microsoft.com>
Commit-Queue: Robert Paveza <Rob.Paveza@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#704038}

third_party/blink/renderer/devtools/front_end/elements/StylePropertyTreeElement.js

@@ -1000,6 +1000,7 @@ Elements.StylePropertyTreeElement = class extends UI.TreeElement {
      */
     function moveToNextCallback(alreadyNew, valueChanged, section) {
       if (!moveDirection) {
+        this._parentPane.resetFocus();
         return;
       }
 

third_party/blink/renderer/devtools/front_end/elements/StylesSidebarPane.js

@@ -249,6 +249,10 @@ Elements.StylesSidebarPane = class extends Elements.ElementsSidebarPane {
   }
 
   _sectionsContainerFocusChanged() {
+    this.resetFocus();
+  }
+
+  resetFocus() {
     // When a styles section is focused, shift+tab should leave the section.
     // Leaving tabIndex = 0 on the first element would cause it to be focused instead.
     if (this._sectionBlocks[0] && this._sectionBlocks[0].sections[0]) {