Fix initial focus of Task Manager for ChromeOS.

Fix initial focus of Task Manager for ChromeOS.

The current code appeared to work because a DialogDelegate actually
defaults to focusing the default button ("End Task") rather than nothing
(like a default WidgetDelegate). Thus when you press Shift+Escape the
row for the active tab is selected, and "End Task" is focused. This
"fixed" the blue line around the table.

But on ChromeOS it's possible to have no windows open and press
Shift+Escape, and then the Browser row is selected initially. You're not
allowed to end that task, so the button is disabled.
Widget::SetInitialFocus has code to advance focus if the initial focus
View can't actually receive focus, hence the table winds up receiving
focus.

BUG=702489
Review-Url: https://codereview.chromium.org/2784903002
Cr-Commit-Position: refs/heads/master@{#460611}
Committed: https://chromium.googlesource.com/chromium/src/+/b554454239ebb239fc7da684b70b6be8ae860c8b

[Evan Stade, 2017-03-29 18:34:38]

estade@chromium.org changed reviewers:
+ sky@chromium.org

[Evan Stade, 2017-03-29 18:34:39]

see CL desc for a good laugh.

[Evan Stade, 2017-03-29 18:35:03]

The CQ bit was checked by estade@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-29 18:36:00]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-29 19:25:47]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-29 19:25:48]

Dry run: This issue passed the CQ dry run.

[sky, 2017-03-29 20:35:13]

Is this bug saying they don't want the table to have focus? Why is it wrong that
the tab gets focus?

[Evan Stade, 2017-03-29 23:37:35]

On 2017/03/29 20:35:13, sky wrote:
> Is this bug saying they don't want the table to have focus? Why is it wrong
that
> the tab gets focus?

yes, the intended behavior is for nothing to have focus initially. When you
press tab once, the table will get focus. I'm not sure what you mean by the tab
in this case. Row selection is distinct from focus.

[sky, 2017-03-30 00:07:48]

LGTM

[Evan Stade, 2017-03-30 00:57:50]

The CQ bit was checked by estade@chromium.org

[commit-bot: I haz the power, 2017-03-30 00:58:36]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-30 01:07:42]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1490835470708290, "parent_rev":
"6298c71c94585f0eb01c9fc1b420d04e935b5239", "commit_rev":
"b554454239ebb239fc7da684b70b6be8ae860c8b"}

[commit-bot: I haz the power, 2017-03-30 01:08:35]

Description was changed from

==========
Fix initial focus of Task Manager for ChromeOS.

The current code appeared to work because a DialogDelegate actually
defaults to focusing the default button ("End Task") rather than nothing
(like a default WidgetDelegate). Thus when you press Shift+Escape the
row for the active tab is selected, and "End Task" is focused. This
"fixed" the blue line around the table.

But on ChromeOS it's possible to have no windows open and press
Shift+Escape, and then the Browser row is selected initially. You're not
allowed to end that task, so the button is disabled.
Widget::SetInitialFocus has code to advance focus if the initial focus
View can't actually receive focus, hence the table winds up receiving
focus.

BUG=702489
==========

to

==========
Fix initial focus of Task Manager for ChromeOS.

The current code appeared to work because a DialogDelegate actually
defaults to focusing the default button ("End Task") rather than nothing
(like a default WidgetDelegate). Thus when you press Shift+Escape the
row for the active tab is selected, and "End Task" is focused. This
"fixed" the blue line around the table.

But on ChromeOS it's possible to have no windows open and press
Shift+Escape, and then the Browser row is selected initially. You're not
allowed to end that task, so the button is disabled.
Widget::SetInitialFocus has code to advance focus if the initial focus
View can't actually receive focus, hence the table winds up receiving
focus.

BUG=702489

Review-Url: https://codereview.chromium.org/2784903002
Cr-Commit-Position: refs/heads/master@{#460611}
Committed:
https://chromium.googlesource.com/chromium/src/+/b554454239ebb239fc7da684b70b...
==========

[commit-bot: I haz the power, 2017-03-30 01:08:36]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/chromium/src/+/b554454239ebb239fc7da684b70b...