Bug 208025

<rdar://problem/59640305>

Created attachment 391322 [details]
Patch

Created attachment 391324 [details]
[Video] Before the patch

Created attachment 391327 [details]
[Video] After the patch

Comment on attachment 391322 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=391322&action=review

> Source/WebInspectorUI/UserInterface/Views/ConsoleTabContentView.js:61
> +            WI.consoleContentView.prompt.focus();

How does VO properly access the Console tab title if focus stays with the prompt element?

Comment on attachment 391322 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=391322&action=review

>> Source/WebInspectorUI/UserInterface/Views/ConsoleTabContentView.js:61
>> +            WI.consoleContentView.prompt.focus();
> 
> How does VO properly access the Console tab title if focus stays with the prompt element?

Can you explain why a rAF is needed?  Is it because the element isn't in the DOM tree, or some other reason?  Rather than rely on the uncertain firing order of rAFs, how about we set some state on `WI.consoleContentView` (or use a "cookie" object passed to `showContentView`) that will focus the prompt in the next `layout()`?  I'm imagining something along the lines of `WI.SourcesTabContentView.prototype.showScopeChainDetailsSidebarPanel`.

> Source/WebInspectorUI/UserInterface/Views/TabBar.js:-635
> -        event.preventDefault();
> -        event.stopPropagation();

Removing this now means that dragging on the tab bar (e.g. reordering tabs) is treated like normal selection, meaning that you can continue a drag to select text.  We don't want that.

Comment on attachment 391322 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=391322&action=review

>> Source/WebInspectorUI/UserInterface/Views/ConsoleTabContentView.js:61
>> +            WI.consoleContentView.prompt.focus();
> 
> How does VO properly access the Console tab title if focus stays with the prompt element?

It doesn't for Console. It just reads "Console prompt".

I think ideally when switching to the Console tab, it should:
1. Immediately focus on the console prompt so if I start typing it should go to the right place.
2. Yet read the Console tab title.

I don't know how to satisfy both requirements. With this patch it just reads "Console Prompt" instead of "console tab", "Console Prompt".

Comment on attachment 391322 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=391322&action=review

>>>> Source/WebInspectorUI/UserInterface/Views/ConsoleTabContentView.js:61
>>>> +            WI.consoleContentView.prompt.focus();
>>> 
>>> How does VO properly access the Console tab title if focus stays with the prompt element?
>> 
>> Can you explain why a rAF is needed?  Is it because the element isn't in the DOM tree, or some other reason?  Rather than rely on the uncertain firing order of rAFs, how about we set some state on `WI.consoleContentView` (or use a "cookie" object passed to `showContentView`) that will focus the prompt in the next `layout()`?  I'm imagining something along the lines of `WI.SourcesTabContentView.prototype.showScopeChainDetailsSidebarPanel`.
> 
> It doesn't for Console. It just reads "Console prompt".
> 
> I think ideally when switching to the Console tab, it should:
> 1. Immediately focus on the console prompt so if I start typing it should go to the right place.
> 2. Yet read the Console tab title.
> 
> I don't know how to satisfy both requirements. With this patch it just reads "Console Prompt" instead of "console tab", "Console Prompt".

I don't think we want to do this.  Automatically focusing the Console prompt means that as soon as the user selects the Console Tab, they're unable to immediately change tabs again (e.g. if they mistakenly selected it).  They'd have to tab all the way back to the tab bar to switch tabs again.

Comment on attachment 391322 [details]
Patch

This patch focuses on the tab element when clicking on it. MacOS Safari doesn't focus on click, and we shouldn't either.

ScopeBar and NavigationBar don't steal the focus on click either. However, there's one exception: when a ScopeBar or NavigationBar item is already focused, clicking on the other item within the same group moves the focus. We should do the same for the tab bar. Perhaps, unify this logic in the future.

This is no longer relevant. The underlining issue has been addressed in a different (and proper) way in Bug 208542 - Web Inspector: AXI: annotate tab panels.