DevTools: accessibility fix for tab from prompt

DevTools: accessibility fix for tab from prompt

TextPrompt used to always consume 'Tab' keys, preventing the use of tab to
navigate from a prompt to checkboxes.  This CL makes the handler consume only if
autocomplete is handled.

BUG=668161

[luoe, 2016-12-02 20:16:10]

Description was changed from

==========
DevTools: accessibility fix for tab from prompt

BUG=668161
==========

to

==========
DevTools: accessibility fix for tab from prompt

TextPrompt used to always consume 'Tab' keys, preventing the use of tab to
navigate from a prompt to checkboxes.  This CL makes the handler consume only if
autocomplete is handled.

BUG=668161
==========

[luoe, 2016-12-02 21:41:15]

luoe@chromium.org changed reviewers:
+ einbinder@chromium.org, lushnikov@chromium.org

[luoe, 2016-12-02 21:41:15]

Please take a look.

[lushnikov, 2016-12-03 01:23:39]

does this change preserve the tab behavior in Styles sidebar pane?

[luoe, 2016-12-03 01:57:39]

On 2016/12/03 01:23:39, lushnikov wrote:
> does this change preserve the tab behavior in Styles sidebar pane?

Yes, SSP.js contains logic that preserves its behavior where pressing tab will
always move to the next field.  This logic is also covered by an existing test:
LayoutTests/inspector/elements/styles-3/styles-add-new-rule-tab.html

One effect of this CL is that pressing tab in a FilteredListWidget's prompt may
leave focus.  I believe einbinder@ has a plan to have FilteredListWidget
intercept keyDown on its prompt, though.

[dgozman, 2016-12-04 18:59:55]

> One effect of this CL is that pressing tab in a FilteredListWidget's prompt
may
> leave focus.  I believe einbinder@ has a plan to have FilteredListWidget
> intercept keyDown on its prompt, though.

Where does the focus go then? I think this is a big regression.

[luoe, 2016-12-05 18:53:20]

I'm not sure what I was thinking, I don't intend to introduce this regression. 
Focus will move into the browser URL bar and even the target page.  Let me
revise this CL first.