SpokenFeedbackTest.NavigateAppLaunchers: Fix for experimental app list.

SpokenFeedbackTest.NavigateAppLaunchers: Fix for experimental app list.

Disabled the part of the test that presses the down key in the
experimental app list; we do not handle keyboard navigation on the start
page, so this part of the test was hanging. A separate bug has been
filed to properly fix this test for experimental app list
(crbug.com/438138).

BUG=438115
Committed: https://crrev.com/56b7ecd01dc722ca369fa726ce1c81557475b074
Cr-Commit-Position: refs/heads/master@{#306586}

[Matt Giuca, 2014-12-02 09:23:06]

mgiuca@chromium.org changed reviewers:
+ plundblad@chromium.org

[Peter Lundblad, 2014-12-02 10:55:39]

Since this tests important functionality, it'd be great to know if the breakage
is because the test is brittle or spoken feedback is actually broken in the new
launcher. Feel free to contact me offline if you don't know how to test this and
I can give you some tips.

[Matt Giuca, 2014-12-03 00:40:34]

Hi Peter,

I did a brief investigation. It's a little of both (the tests are brittle AND
the new launcher behaves differently).

First, the app list (both the classic and new app list) is pretty bad at
ChromeVox. For example, the classic app list reads out "Chromium, text box",
because the first app item is "Chromium" and a text box is selected. But the
text box is not called Chromium. It should say "Search, text box". (I have a bug
on this: http://crbug.com/386826).

Second, the test is very brittle and seems to be results-driven testing: it's
checking that the current behaviour (which is rubbish) is happening. You can see
the assertion:

  EXPECT_TRUE(MatchPattern(speech_monitor_.GetNextUtterance(), "Chrom*,"));
  EXPECT_EQ("text box", speech_monitor_.GetNextUtterance());

Is basically testing the current broken behaviour.

The new app list also has similar (but different) broken behaviour. It reads out
the name of a different app ("Web Store") which is based on a heuristic (we no
longer show apps in a standard order, but a most recently used order). So we
could update the test to check for "Web Store", but I think that may be flaky,
or at best brittle. And we don't support keyboard navigation properly so the
second part of the test will do nothing.

So, not ideal, but I think it will take some effort to make things right, and we
don't want to block flipping the flag to go to dev users on this test. In
response to this investigation, I have updated the test so that it passes in
both the classic and experimental modes. It's still pretty bad, but I've added
some TODOs with references to bugs so we can fix this as part of an
accessibility audit of the app list in the near future.

[Matt Giuca, 2014-12-03 07:37:02]

Rebased the test off:
https://codereview.chromium.org/770813004/
(which also had to update this test).

[Peter Lundblad, 2014-12-03 10:39:35]

lgtm

crbug.com/438568 tracks adding keyboard accessibility to the new launcher
which should allow to revert this cl (modulo new behaviour).

[Matt Giuca, 2014-12-03 10:41:52]

Thanks. Before I land this, I will update the TODO comment to refer to that bug
(crbug.com/438568) instead of the test failure bug.

[Matt Giuca, 2014-12-03 10:49:02]

The CQ bit was checked by mgiuca@chromium.org

[commit-bot: I haz the power, 2014-12-03 10:49:23]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/762113004/100001

[commit-bot: I haz the power, 2014-12-03 11:27:09]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2014-12-03 11:27:56]

Patchset 6 (id:??) landed as
https://crrev.com/56b7ecd01dc722ca369fa726ce1c81557475b074
Cr-Commit-Position: refs/heads/master@{#306586}