Fix accessibility order of Android tabstrip

Fix accessibility order of Android tabstrip

This change alters the accessibility order of the tabstrip
on Android devices. It contains two changes:
- "Close tab" button will be selected after the tab itself
  during linear navigation
- Tabs are selected from left to right when using linear
  navigation, rather than basing the order on which tab is
  currently active

BUG=593111
Committed: https://crrev.com/1a4b51b68e4120a2e7008618ab627af94605f515
Cr-Commit-Position: refs/heads/master@{#387604}

[kraush, 2016-03-03 19:52:26]

kraush@amazon.com changed reviewers:
+ changwan@chromium.org

[kraush, 2016-03-03 19:52:27]

Hi Changwan,

This change aligns Chrome's linear navigation order on the TabStrip to recflect
order of the elements on the UI.
(as per
http://developer.android.com/training/accessibility/accessible-app.html#focus )

Without the change, the close button will always be considered "left" of the
tab's title, and the order of tabs if you keep swiping right is rather
unintuitive (selected tab first, then everything to the right of it, then
everything to the left of it, then the new tab button)

Can you please take a look?

Thanks! :)
Holger

[Changwan Ryu, 2016-03-08 04:20:30]

On 2016/03/03 19:52:27, kraush wrote:
> Hi Changwan,
> 
> This change aligns Chrome's linear navigation order on the TabStrip to
recflect
> order of the elements on the UI.
> (as per
> http://developer.android.com/training/accessibility/accessible-app.html#focus
)
> 
> Without the change, the close button will always be considered "left" of the
> tab's title, and the order of tabs if you keep swiping right is rather
> unintuitive (selected tab first, then everything to the right of it, then
> everything to the left of it, then the new tab button)
> 
> Can you please take a look?
> 
> Thanks! :)
> Holger

Some asks:
1. Could you file a crbug and have your patch point to it?
2. Could the current tab strip order will help you get the information about the
active tab better and quicker? (e.g. title)
(I'm not sure which is more important here: intuitiveness vs usability...)

3. If intuitiveness is more important, is there any way to check whether the
currently focused tab is selected or not?

[Changwan Ryu, 2016-03-08 04:22:44]

changwan@chromium.org changed reviewers:
+ dtrainor@chromium.org, rolfe@chromium.org

[Changwan Ryu, 2016-03-08 04:22:45]

rolfe@ and dtrainor@, do you know why we show the tab strip order as described
in the patchset? Is it designed for faster access to the active tab title
information?

[David Trainor- moved to gerrit, 2016-03-08 18:23:29]

This isn't really accurate either though.  If you have a lot of tabs, most of
those tabs won't be visible to the user in accessibility mode (which is why we
have the button to enter the accessibility switcher).

If we want this to work properly (and use this mode of selection) we probably
want to expand the strip to show whatever tab is focused by accessibility.

[David Trainor- moved to gerrit, 2016-03-08 18:27:23]

Ah sorry I replied to the CL, not directly to Rebecca's email.  Yeah
there's this interesting issue with stacking a bunch of tabs.  If we do
left to right and you have 50 tabs and the middle 10 are showing, you'll be
focused on a tab that is completely obscured.  We might want to slide that
tab into view as you use accessibility focus to traverse the tab strip.
This feels like what a ListView would do.  Then again, what is visible
might not be important in the same way to accessibility users, so yeah
Laura any insight here on what you think we should do would be great :).

On Tue, Mar 8, 2016 at 10:23 AM <dtrainor@chromium.org> wrote:

> This isn't really accurate either though. If you have a lot of tabs, most
> of
> those tabs won't be visible to the user in accessibility mode (which is
> why we
> have the button to enter the accessibility switcher).
>
> If we want this to work properly (and use this mode of selection) we
> probably
> want to expand the strip to show whatever tab is focused by accessibility.
>
> https://codereview.chromium.org/1763713003/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[kraush, 2016-03-08 19:48:58]

Description was changed from

==========
Fix accessibility order of Android tabstrip

This change alters the accessibility order of the tabstrip
on Android devices. It contains two changes:
- "Close tab" button will be selected after the tab itself
  during linear navigation
- Tabs are selected from left to right when using linear
  navigation, rather than basing the order on which tab is
  currently active

BUG=
==========

to

==========
Fix accessibility order of Android tabstrip

This change alters the accessibility order of the tabstrip
on Android devices. It contains two changes:
- "Close tab" button will be selected after the tab itself
  during linear navigation
- Tabs are selected from left to right when using linear
  navigation, rather than basing the order on which tab is
  currently active

BUG=593111
==========

[kraush, 2016-03-08 19:59:13]

Added Bug as suggested by Changwan.

Not sure I agree with it being easier to use if it's considering the active tab
to be on the left - other apps as well as Android views don't change
accessibility order based on selected objects (e.g. in radio groups), so this
might be unexpected to the user.
I'm also hesitant to simulate a click on tabs as soon as they get accessibility
focus. This seems unexpected when looking at how TalkBack usually works.

That's only my take on it though - I'd be interested in Laura's opinion (Is
Laura rolfe@ ? If not, could either of you add her to the CL please? :D)

Thanks!
Holger

[David Trainor- moved to gerrit, 2016-03-08 21:52:15]

On 2016/03/08 19:59:13, kraush wrote:
> Added Bug as suggested by Changwan.
> 
> Not sure I agree with it being easier to use if it's considering the active
tab
> to be on the left - other apps as well as Android views don't change
> accessibility order based on selected objects (e.g. in radio groups), so this
> might be unexpected to the user.
> I'm also hesitant to simulate a click on tabs as soon as they get
accessibility
> focus. This seems unexpected when looking at how TalkBack usually works.

Do list views scroll to the top if you cycle into them or just to the top
visible item?  I'm not suggesting we simulate clicks, we can still scroll the
tab strip to make the 'focused' tab visible.

> 
> That's only my take on it though - I'd be interested in Laura's opinion (Is
> Laura rolfe@ ? If not, could either of you add her to the CL please? :D)
> 
> Thanks!
> Holger

[David Trainor- moved to gerrit, 2016-03-08 21:52:34]

dtrainor@chromium.org changed reviewers:
+ lpalmaro@google.com

[David Trainor- moved to gerrit, 2016-03-08 21:52:34]

+Laura

[Changwan Ryu, 2016-03-21 09:01:32]

On 2016/03/08 21:52:34, David Trainor wrote:
> +Laura

Ok, I just tried this patch locally and here are my observations:

1) It is much easier to navigate among tab strips using left and right swipes
with this patch.

2) Even when there are many tabs stacking up in the back, we correctly show the
tab position using the transparent green box.
Once green box is on our desired tab strip, we can double tap to activate the
tab.

3) When you're not looking at the screen at all, it may be difficult to get to
the active tab and close it if there are many open tabs.

Without the patch it is still somewhat difficult to do this: the active tab
strip is at the beginning of focus order, you were focusing on something else
you'll need to keep swiping left all the way to get to the active tab strip. On
the other hand, if you were focusing on the bottom then you can keep swiping
right a few times to cycle to the active tab strip. The problem here is that the
starting focus element seems to be somewhat inconsistent: if you have a
previously focused element, Android seems to remember it. If you cleared
TalkBack and set it again, focus element will be removed.

In any case, it might help to note 'activeness' of the strip, but I feel that
it's orthogonal to this change.

4) This works correctly for RTL mode such as Arabic language settings.

5) I could not find a good ListView example, but PlayStore's Games category tab
works the same as this patch. It does not change focus order when you move to
another category.

In this sense, I'm ok with the change. David, is there any other concern you
have about this change?
(I wish that there are some tests to verify the behavior, but I didn't want to
request a contributor to add new tests.)

[kraush, 2016-03-21 16:44:37]

On 2016/03/21 09:01:32, Changwan Ryu wrote:
> (I wish that there are some tests to verify the behavior, but I didn't want to
> request a contributor to add new tests.)

The fact that I'm not an internal contributor shouldn't mean I don't have to add
tests! :)
I'd be happy to add some.
I'm thinking JUnit test that sets up some mock tabs and calls getVirtualViews,
verifying order and tab content. (With variants like RTL)
Do you think that'd be appropriate?
Or would you prefer another type of test? (Not sure how viable instrumentation
tests are since this feature relies on TalkBack being on)

[Changwan Ryu, 2016-03-22 00:04:33]

On 2016/03/21 16:44:37, kraush wrote:
> On 2016/03/21 09:01:32, Changwan Ryu wrote:
> > (I wish that there are some tests to verify the behavior, but I didn't want
to
> > request a contributor to add new tests.)
> 
> The fact that I'm not an internal contributor shouldn't mean I don't have to
add
> tests! :)
> I'd be happy to add some.
> I'm thinking JUnit test that sets up some mock tabs and calls getVirtualViews,
> verifying order and tab content. (With variants like RTL)
> Do you think that'd be appropriate?
Yes, that sounds most appropriate to me.

> Or would you prefer another type of test? (Not sure how viable instrumentation
> tests are since this feature relies on TalkBack being on)

[kraush, 2016-03-22 00:14:10]

On 2016/03/22 00:04:33, Changwan Ryu wrote:
> On 2016/03/21 16:44:37, kraush wrote:
> > On 2016/03/21 09:01:32, Changwan Ryu wrote:
> > > (I wish that there are some tests to verify the behavior, but I didn't
want
> to
> > > request a contributor to add new tests.)
> > 
> > The fact that I'm not an internal contributor shouldn't mean I don't have to
> add
> > tests! :)
> > I'd be happy to add some.
> > I'm thinking JUnit test that sets up some mock tabs and calls
getVirtualViews,
> > verifying order and tab content. (With variants like RTL)
> > Do you think that'd be appropriate?
> Yes, that sounds most appropriate to me.
> 
> > Or would you prefer another type of test? (Not sure how viable
instrumentation
> > tests are since this feature relies on TalkBack being on)

Great, will do!
Since this will still be testing a UI component, it'll require a dependency from
the JUnit target to chrome_public_apk_java to give it access to R.java.
I don't think there is a problem with that, but please let me know if you see
any concern with that.

[kraush, 2016-03-22 02:22:55]

Added some tests.
Please let me know whether or not you think the approach I used to write them
makes sense and if the scope is acceptable (e.g. introducing the new dependency)

I haven't build this in GN yet (have to figure out how jar wrapping works in
GN).
--> Figured I'd give an early version to get early feedback on the change
itself.

[Changwan Ryu, 2016-03-22 05:33:18]

On 2016/03/22 02:22:55, kraush wrote:
> Added some tests.
> Please let me know whether or not you think the approach I used to write them
> makes sense and if the scope is acceptable (e.g. introducing the new
dependency)
> 
> I haven't build this in GN yet (have to figure out how jar wrapping works in
> GN).
> --> Figured I'd give an early version to get early feedback on the change
> itself.

compositor/ lgtm

[kraush, 2016-03-22 19:57:38]

On 2016/03/22 05:33:18, Changwan Ryu wrote:
> On 2016/03/22 02:22:55, kraush wrote:
> > Added some tests.
> > Please let me know whether or not you think the approach I used to write
them
> > makes sense and if the scope is acceptable (e.g. introducing the new
> dependency)
> > 
> > I haven't build this in GN yet (have to figure out how jar wrapping works in
> > GN).
> > --> Figured I'd give an early version to get early feedback on the change
> > itself.
> 
> compositor/ lgtm

Hey David, can you take a look at the rest of the Android code?

[chromium-reviews, 2016-03-28 16:15:03]

Really sorry for my delay here, but I do agree David -- if the tab has
accessibility focus, I do think that it should be brought into visible view
on the screen. We need to keep in mind that not all people who use Talkback
are fully blind -- there are plenty of people with low vision who may rely
on a combination of spoken feedback and magnification or contrast
adjustments to see and interact with the UI.

On Tue, Mar 8, 2016 at 1:52 PM, <dtrainor@chromium.org> wrote:

> +Laura
>
> https://codereview.chromium.org/1763713003/
>



-- 
*Laura Palmaro*
Program Manager, Chrome Accessibility
Email: lpalmaro@google.com
Cell: (973) 714-2599

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[kraush, 2016-03-29 01:35:17]

kraush@amazon.com changed reviewers:
+ perezju@chromium.org

[kraush, 2016-03-29 01:35:18]

Finally got around to fix the GN build. Successfully building and testing in GN
and gyp now.

@perezju: Can you please take a look at the Manifest change? So far there was no
consumer of this build target so it went unnoticed that the generated R.java
could not be consumed due to being in the wrong package.

@Laura: I think it's a good idea to automatically show selected tabs. However,
I'm not sure this should be combined with this CL. I thinkg fixing the tabstrip
selection order and automatically changing the UI when the accessibility focus
changes are two different issues and we might want to address them separately.
Would you agree?

@Everyone:
Since David is out till 4-11, any suggestions on a reviewer for the
chrome/android pieces?

[perezju, 2016-03-29 10:56:46]

rubberstamp lgtm on build/andorid

adding jbudorick FYI

[kraush, 2016-03-29 15:40:15]

kraush@amazon.com changed reviewers:
+ miguelg@chromium.org

[kraush, 2016-03-29 15:40:16]

With David OOO, adding Miguel for the remaining changes:
    chrome/android/BUILD.gn
    chrome/android/java/src/org/chromium/chrome/browser/tab/Tab.java
   
chrome/android/junit/src/org/chromium/chrome/browser/compositor/overlays/strip/StripLayoutHelperTest.java
    ui/android/java/src/org/chromium/ui/base/LocalizationUtils.java

[Changwan Ryu, 2016-04-05 06:19:56]

changwan@chromium.org changed reviewers:
+ tedchoc@chromium.org

[Changwan Ryu, 2016-04-05 06:19:57]

tedchoc@, would it be ok to make Tab non-final?
It is needed for Mockito.

[jbudorick, 2016-04-05 13:26:53]

jbudorick@chromium.org changed reviewers:
+ jbudorick@chromium.org

[jbudorick, 2016-04-05 13:26:54]

https://codereview.chromium.org/1763713003/diff/60001/build/android/AndroidMa...
File build/android/AndroidManifest.xml (right):

https://codereview.chromium.org/1763713003/diff/60001/build/android/AndroidMa...
build/android/AndroidManifest.xml:16: package="org.chromium.chrome">
What's the motivation here? It's not obvious from your gyp/gn changes why this
was necessary, and if you need a particular package name here, then this is
liable to break for other targets.

https://codereview.chromium.org/1763713003/diff/60001/chrome/android/junit/sr...
File
chrome/android/junit/src/org/chromium/chrome/browser/compositor/overlays/strip/StripLayoutHelperTest.java
(right):

https://codereview.chromium.org/1763713003/diff/60001/chrome/android/junit/sr...
chrome/android/junit/src/org/chromium/chrome/browser/compositor/overlays/strip/StripLayoutHelperTest.java:7:
import static org.junit.Assert.assertEquals;
import static? :(

[kraush, 2016-04-05 15:48:04]

Good points jbudorick, thanks! :)

Replies / follow up questions inline.

https://codereview.chromium.org/1763713003/diff/60001/build/android/AndroidMa...
File build/android/AndroidManifest.xml (right):

https://codereview.chromium.org/1763713003/diff/60001/build/android/AndroidMa...
build/android/AndroidManifest.xml:16: package="org.chromium.chrome">
On 2016/04/05 13:26:54, jbudorick wrote:
> What's the motivation here? It's not obvious from your gyp/gn changes why this
> was necessary, and if you need a particular package name here, then this is
> liable to break for other targets.

This is the package the R.java this Manifest is used for will be generated in.
You are right - as soon as there is a second user of this Manifest for R
generation, the package will no longer work (apk's have their own Manifests, but
JUnit tests for something else than ChromePublic could run into this issue)

Would you prefer me to change it to replace the file with a jinja template (with
a package parameter) instead to prevent such future problems?

https://codereview.chromium.org/1763713003/diff/60001/chrome/android/junit/sr...
File
chrome/android/junit/src/org/chromium/chrome/browser/compositor/overlays/strip/StripLayoutHelperTest.java
(right):

https://codereview.chromium.org/1763713003/diff/60001/chrome/android/junit/sr...
chrome/android/junit/src/org/chromium/chrome/browser/compositor/overlays/strip/StripLayoutHelperTest.java:7:
import static org.junit.Assert.assertEquals;
On 2016/04/05 13:26:54, jbudorick wrote:
> import static? :(

I wasn't sure which pattern to use as both import static for asserts as well as
regular imports existed in the current JUnit tests.
In the end I decided to go with the majority (15/18 chrome/JUnit tests that use
assertEquals import it statically, 3 have non-static imports of Assert)

Is it in general a preferred pattern to use regular imports for Asserts?
If so, what about the mockito matchers? Should I make them non-static as well?

[jbudorick, 2016-04-05 15:52:03]

https://codereview.chromium.org/1763713003/diff/60001/build/android/AndroidMa...
File build/android/AndroidManifest.xml (right):

https://codereview.chromium.org/1763713003/diff/60001/build/android/AndroidMa...
build/android/AndroidManifest.xml:16: package="org.chromium.chrome">
On 2016/04/05 15:48:04, kraush wrote:
> On 2016/04/05 13:26:54, jbudorick wrote:
> > What's the motivation here? It's not obvious from your gyp/gn changes why
this
> > was necessary, and if you need a particular package name here, then this is
> > liable to break for other targets.
> 
> This is the package the R.java this Manifest is used for will be generated in.
> You are right - as soon as there is a second user of this Manifest for R
> generation, the package will no longer work (apk's have their own Manifests,
but
> JUnit tests for something else than ChromePublic could run into this issue)
> 
> Would you prefer me to change it to replace the file with a jinja template
(with
> a package parameter) instead to prevent such future problems?

Yeah, that'd be great.

https://codereview.chromium.org/1763713003/diff/60001/chrome/android/junit/sr...
File
chrome/android/junit/src/org/chromium/chrome/browser/compositor/overlays/strip/StripLayoutHelperTest.java
(right):

https://codereview.chromium.org/1763713003/diff/60001/chrome/android/junit/sr...
chrome/android/junit/src/org/chromium/chrome/browser/compositor/overlays/strip/StripLayoutHelperTest.java:7:
import static org.junit.Assert.assertEquals;
On 2016/04/05 15:48:04, kraush wrote:
> On 2016/04/05 13:26:54, jbudorick wrote:
> > import static? :(
> 
> I wasn't sure which pattern to use as both import static for asserts as well
as
> regular imports existed in the current JUnit tests.
> In the end I decided to go with the majority (15/18 chrome/JUnit tests that
use
> assertEquals import it statically, 3 have non-static imports of Assert)
> 
> Is it in general a preferred pattern to use regular imports for Asserts?
> If so, what about the mockito matchers? Should I make them non-static as well?

Hm. I don't personally like import statics, but I didn't realize that they've
become the predominant way of importing from org.junit. I'd prefer non-static
imports, but I'll defer to the owners here.

[Ted C, 2016-04-05 17:29:05]

On 2016/04/05 06:19:57, Changwan Ryu wrote:
> tedchoc@, would it be ok to make Tab non-final?
> It is needed for Mockito.

Yeah.  We might be able to make it final again by exposing a tab
for testing while making the constructor for tab non-visible to anything
but that.  But we can do that in a separate patch and for now, this is
fine (a couple people have asked in the last two weeks, so let's do this).

[kraush, 2016-04-05 18:57:47]

https://codereview.chromium.org/1763713003/diff/60001/build/android/AndroidMa...
File build/android/AndroidManifest.xml (right):

https://codereview.chromium.org/1763713003/diff/60001/build/android/AndroidMa...
build/android/AndroidManifest.xml:16: package="org.chromium.chrome">
On 2016/04/05 15:52:03, jbudorick wrote:
> On 2016/04/05 15:48:04, kraush wrote:
> > On 2016/04/05 13:26:54, jbudorick wrote:
> > > What's the motivation here? It's not obvious from your gyp/gn changes why
> this
> > > was necessary, and if you need a particular package name here, then this
is
> > > liable to break for other targets.
> > 
> > This is the package the R.java this Manifest is used for will be generated
in.
> > You are right - as soon as there is a second user of this Manifest for R
> > generation, the package will no longer work (apk's have their own Manifests,
> but
> > JUnit tests for something else than ChromePublic could run into this issue)
> > 
> > Would you prefer me to change it to replace the file with a jinja template
> (with
> > a package parameter) instead to prevent such future problems?
> 
> Yeah, that'd be great.

I just looked into this some more and just realized that a mechanism for this
already exists (which will effectively use a different Manifest)
I'll update the CL using the "custom_package" attribute rather than modifying
the Manifest.

[kraush, 2016-04-05 19:03:15]

Patch Set 5 is up, removing the Manifest change and instead defining
custom_package on the chrome_public_apk_resources GN target.

Please take a look! :)

[David Trainor- moved to gerrit, 2016-04-13 17:57:10]

lgtm!

[kraush, 2016-04-13 18:52:35]

The CQ bit was checked by kraush@amazon.com

[kraush, 2016-04-13 18:52:35]

The patchset sent to the CQ was uploaded after l-g-t-m from
changwan@chromium.org, perezju@chromium.org
Link to the patchset: https://codereview.chromium.org/1763713003/#ps80001
(title: "Removed Manifest changes in favor of GN change")

[commit-bot: I haz the power, 2016-04-13 18:52:55]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1763713003/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1763713003/80001

[commit-bot: I haz the power, 2016-04-13 18:55:47]

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

[commit-bot: I haz the power, 2016-04-13 18:55:48]

Try jobs failed on following builders:
  ios_dbg_simulator_gn on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_dbg_simulator...)
  ios_dbg_simulator_ninja on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_dbg_simulator...)
  ios_rel_device_gn on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device_gn...)
  ios_rel_device_ninja on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device_ni...)
  mac_chromium_compile_dbg_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[kraush, 2016-04-13 19:08:38]

Rebased on master and resolved merge conflict in BUILD.gn
Will try to commit this revision.

[kraush, 2016-04-13 19:08:45]

The CQ bit was checked by kraush@amazon.com

[kraush, 2016-04-13 19:08:46]

The patchset sent to the CQ was uploaded after l-g-t-m from
perezju@chromium.org, dtrainor@chromium.org, changwan@chromium.org
Link to the patchset: https://codereview.chromium.org/1763713003/#ps100001
(title: "Rebased on master")

[commit-bot: I haz the power, 2016-04-13 19:09:12]

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

[commit-bot: I haz the power, 2016-04-13 19:24:15]

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

[commit-bot: I haz the power, 2016-04-13 19:24:18]

Try jobs failed on following builders:
  android_chromium_gn_compile_rel on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_chro...)

[kraush, 2016-04-13 19:48:07]

On 2016/04/13 19:24:18, commit-bot: I haz the power wrote:
> Try jobs failed on following builders:
>   android_chromium_gn_compile_rel on tryserver.chromium.android (JOB_FAILED,
>
https://build.chromium.org/p/tryserver.chromium.android/builders/android_chro...)

[kraush, 2016-04-13 19:48:52]

On 2016/04/13 19:48:07, kraush wrote:
> On 2016/04/13 19:24:18, commit-bot: I haz the power wrote:
> > Try jobs failed on following builders:
> >   android_chromium_gn_compile_rel on tryserver.chromium.android (JOB_FAILED,
> >
>
https://build.chromium.org/p/tryserver.chromium.android/builders/android_chro...)

Didn't rebuild after the rebase.
I'll wait for all the testers to finish and then build the respective targets
locally.
From what I can tell so far it only looks like an interface changed since the
rebase -> Shouldn't be much of a change.

[kraush, 2016-04-15 14:28:32]

- Rebased on master
- Adjusted to new interface (passing 1 null rather than 2 in the test)
- Someone else created a Chrome GN target in the meantime. Using that one
instead.
- Reran a GN build and ran the tests from there (will try to verify gyp via
trybot before committing)

[kraush, 2016-04-15 14:32:48]

The CQ bit was checked by kraush@amazon.com to run a CQ dry run

[commit-bot: I haz the power, 2016-04-15 14:32:58]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1763713003/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1763713003/120001

[commit-bot: I haz the power, 2016-04-15 15:29:11]

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

[commit-bot: I haz the power, 2016-04-15 15:29:13]

Dry run: This issue passed the CQ dry run.

[kraush, 2016-04-15 15:29:41]

The CQ bit was unchecked by kraush@amazon.com

[kraush, 2016-04-15 15:29:42]

The CQ bit was checked by kraush@amazon.com

[kraush, 2016-04-15 15:29:42]

The patchset sent to the CQ was uploaded after l-g-t-m from
perezju@chromium.org, dtrainor@chromium.org, changwan@chromium.org
Link to the patchset: https://codereview.chromium.org/1763713003/#ps120001
(title: "Rebased and fixed Java and GN")

[commit-bot: I haz the power, 2016-04-15 15:29:54]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1763713003/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1763713003/120001

[commit-bot: I haz the power, 2016-04-15 15:34:17]

Description was changed from

==========
Fix accessibility order of Android tabstrip

This change alters the accessibility order of the tabstrip
on Android devices. It contains two changes:
- "Close tab" button will be selected after the tab itself
  during linear navigation
- Tabs are selected from left to right when using linear
  navigation, rather than basing the order on which tab is
  currently active

BUG=593111
==========

to

==========
Fix accessibility order of Android tabstrip

This change alters the accessibility order of the tabstrip
on Android devices. It contains two changes:
- "Close tab" button will be selected after the tab itself
  during linear navigation
- Tabs are selected from left to right when using linear
  navigation, rather than basing the order on which tab is
  currently active

BUG=593111
==========

[commit-bot: I haz the power, 2016-04-15 15:34:19]

Committed patchset #7 (id:120001)

[commit-bot: I haz the power, 2016-04-15 15:36:23]

Description was changed from

==========
Fix accessibility order of Android tabstrip

This change alters the accessibility order of the tabstrip
on Android devices. It contains two changes:
- "Close tab" button will be selected after the tab itself
  during linear navigation
- Tabs are selected from left to right when using linear
  navigation, rather than basing the order on which tab is
  currently active

BUG=593111
==========

to

==========
Fix accessibility order of Android tabstrip

This change alters the accessibility order of the tabstrip
on Android devices. It contains two changes:
- "Close tab" button will be selected after the tab itself
  during linear navigation
- Tabs are selected from left to right when using linear
  navigation, rather than basing the order on which tab is
  currently active

BUG=593111

Committed: https://crrev.com/1a4b51b68e4120a2e7008618ab627af94605f515
Cr-Commit-Position: refs/heads/master@{#387604}
==========

[commit-bot: I haz the power, 2016-04-15 15:36:24]

Patchset 7 (id:??) landed as
https://crrev.com/1a4b51b68e4120a2e7008618ab627af94605f515
Cr-Commit-Position: refs/heads/master@{#387604}