Description: DevTools: Use real focus in TreeOutline
BUG=none
Affected files (+65, -77 lines): M third_party/WebKit/LayoutTests/http/tests/inspector/security/interstitial-sidebar-expected.txt M third_party/WebKit/Source/devtools/front_end/accessibility/accessibilityNode.css M third_party/WebKit/Source/devtools/front_end/components/ObjectPropertiesSection.js M third_party/WebKit/Source/devtools/front_end/elements/ElementsTreeElement.js M third_party/WebKit/Source/devtools/front_end/elements/ElementsTreeOutline.js M third_party/WebKit/Source/devtools/front_end/elements/elementsTreeOutline.css M third_party/WebKit/Source/devtools/front_end/network/RequestHeadersView.js M third_party/WebKit/Source/devtools/front_end/security/sidebar.css M third_party/WebKit/Source/devtools/front_end/ui/treeoutline.css M third_party/WebKit/Source/devtools/front_end/ui/treeoutline.js
pfel...@chromium.org
unread,
Jan 20, 2017, 11:57:35 PM1/20/17
Reply to author
Sign in to reply to author
Forward
Sign in to forward
Delete
You do not have permission to delete messages in this group
Copy link
Report message
Sign in to report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
General concern is around nested tree outlines - listItemElements could have nested focusable items in which case tab traversal within the tree becomes possible.
On 2017/01/21 at 04:58:56, pfeldman wrote: > General concern is around nested tree outlines - listItemElements could have nested focusable items in which case tab traversal within the tree becomes possible.
I don't see how this changes tab traversal. If you had tab stops inside the TreeOutline, you would be able to get to them regardless of whether your initial focus is on the TreeOutline or one of its listItemElements.
On 2017/01/21 at 04:57:34, pfeldman wrote: > background is a shorthand, it should reset everything. background: none should suffice.
I copy-pasted this from the code in InspectorCommon.css. Maybe someone had some clever reason why it was this way? It's hard to check if the icons all look how they are supposed to.
On 2017/01/21 at 04:57:34, pfeldman wrote: > I'm pretty sure this was happening :(, so removing the check is risky.
I don't see how this can happen, it just calls focus. On itself. Nothing overrides TreeOutline focus anymore. But I agree that focusing the TreeElement directly will be less risky.
On 2017/01/21 at 04:57:34, pfeldman wrote: > listItemElement can have focusable children, if listeners don't consume their event, you should execute it (inplace editing).
This was specifically to guard against that scenario. If you have an inplace editor, we don't want left and right arrow to move you in the treeoutline.
On 2017/01/30 at 18:43:07, pfeldman wrote: > Why are we losing focus that this becomes necessary? Does navigator inplace editing work with no need for modifications?
On 2017/01/30 at 18:43:07, pfeldman wrote: > lusha is replacing these with the use of UI.Icon all over the place. What is happening here, why is this only added and not removed anywhere?
I removed the focus event listener, which was adding a force-white-icons class. Without copying over the CSS, I'd have to juggle blur and focus event listeners on the selected TreeElements. Edit
On 2017/01/30 at 18:43:07, pfeldman wrote: > I'd remove this and only leave the setFocusable for the API sanity. Component would be focusable by default.
On 2017/01/30 at 18:43:07, pfeldman wrote: > What if there is no selected element? Can there be no selected element btw? Previously we could rely upon the fact that treeoutline would pick focus, we no longer can.
Selecting the contentElement now, and restoring focus to/from it.
On 2017/02/01 at 22:59:54, pfeldman wrote: > lgtm, please make sure this is in sync with Lusha's icon change. >
> -- > You received this message because you are subscribed to the Google Groups "Blink Reviews" group. > To unsubscribe from this group and stop receiving emails from it, send an email to blink-review...@chromium.org. >