Include relationship ARIA objects in serialized accessibility tree

Include relationship ARIA objects in serialized accessibility tree

Depends on cl/168243003

BUG=98976
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=258928

[dmazzoni, 2014-03-11 23:37:52]

lgtm with two style suggestions.

Nice!

https://codereview.chromium.org/175613002/diff/50001/content/browser/accessib...
File content/browser/accessibility/browser_accessibility_cocoa.mm (right):

https://codereview.chromium.org/175613002/diff/50001/content/browser/accessib...
content/browser/accessibility/browser_accessibility_cocoa.mm:870:
browserAccessibility_->GetIntListAttribute(ui::AX_ATTR_OWNS_IDS);
These are all analogous, maybe a helper function to call three times with
AX_ATTR_OWNS_IDS, ten AX_ATTR_CONTROLS_IDS, and so on?

You could call the same from titleUIElement, too - and then only return the
first one.

https://codereview.chromium.org/175613002/diff/50001/content/renderer/accessi...
File content/renderer/accessibility/accessibility_node_serializer.cc (right):

https://codereview.chromium.org/175613002/diff/50001/content/renderer/accessi...
content/renderer/accessibility/accessibility_node_serializer.cc:440: for(size_t
i = 0; i < describedby.size(); i++)
Maybe a helper function here too - that goes from WebVector<WebAXObject> and
calls AddIntListAttribute.

[David Tseng, 2014-03-12 00:30:56]

Comments for b_a_c.mm

https://codereview.chromium.org/175613002/diff/50001/content/browser/accessib...
File content/browser/accessibility/browser_accessibility_cocoa.mm (right):

https://codereview.chromium.org/175613002/diff/50001/content/browser/accessib...
content/browser/accessibility/browser_accessibility_cocoa.mm:290: {
@"AXLinkedUIElements", @"linkedUIElements" },
This is a native OS X attribute,s o let's use
NSAccessibilityLinkedUIElementsAttribute

https://codereview.chromium.org/175613002/diff/50001/content/browser/accessib...
content/browser/accessibility/browser_accessibility_cocoa.mm:857: if
(labelledby_ids.size() == 1) {
This is an interesting case.

Mac, unfortunately, doesn't have a good match for labelled by. The closest is
ServesAsTitleForUIElements
which maps from the label to an array of ui elements it labels. Perhaps we could
fill in that relationship using labelled by when a BAC/BAMac gets initialized.
(i.e. get the object pointed to by labelled by and fill in the elements it
labels as the originating object). The only disadvantage besides having to keep
more state around is that this won't work if the labelled by object hasn't
itself been initialized.

https://codereview.chromium.org/175613002/diff/50001/content/browser/accessib...
content/browser/accessibility/browser_accessibility_cocoa.mm:867: -
(NSArray*)linkedUIElements {
Keep these methods sorted.

https://codereview.chromium.org/175613002/diff/50001/content/browser/accessib...
content/browser/accessibility/browser_accessibility_cocoa.mm:1301:
@"AXLinkedUIElements",
Ditto.

https://codereview.chromium.org/175613002/diff/50001/content/browser/accessib...
content/browser/accessibility/browser_accessibility_cocoa.mm:1402:
browserAccessibility_->HasIntListAttribute(ui::AX_ATTR_LABELLEDBY_IDS)) {
Technically, only if there's exactly one labelled by id.

[aboxhall, 2014-03-12 17:50:46]

https://codereview.chromium.org/175613002/diff/50001/content/browser/accessib...
File content/browser/accessibility/browser_accessibility_cocoa.mm (right):

https://codereview.chromium.org/175613002/diff/50001/content/browser/accessib...
content/browser/accessibility/browser_accessibility_cocoa.mm:290: {
@"AXLinkedUIElements", @"linkedUIElements" },
On 2014/03/12 00:30:56, David Tseng wrote:
> This is a native OS X attribute,s o let's use
> NSAccessibilityLinkedUIElementsAttribute

Done.

https://codereview.chromium.org/175613002/diff/50001/content/browser/accessib...
content/browser/accessibility/browser_accessibility_cocoa.mm:857: if
(labelledby_ids.size() == 1) {
On 2014/03/12 00:30:56, David Tseng wrote:
> This is an interesting case.
> 
> Mac, unfortunately, doesn't have a good match for labelled by. The closest is
> ServesAsTitleForUIElements
> which maps from the label to an array of ui elements it labels. Perhaps we
could
> fill in that relationship using labelled by when a BAC/BAMac gets initialized.
> (i.e. get the object pointed to by labelled by and fill in the elements it
> labels as the originating object). The only disadvantage besides having to
keep
> more state around is that this won't work if the labelled by object hasn't
> itself been initialized.

I don't completely follow, sorry. The spec says:
If aria-labelledby references a single element, expose the labeling relationship
as element AXTitleUIElement.

If aria-labelledby references multiple elements, or if the labeling element is
invisible or otherwise not exposed in the accessibility tree, use in calculating
the accessible name as described in Name Computation and expose value as string
AXDescription.

I believe we're already doing the latter in Blink?

https://codereview.chromium.org/175613002/diff/50001/content/browser/accessib...
content/browser/accessibility/browser_accessibility_cocoa.mm:867: -
(NSArray*)linkedUIElements {
On 2014/03/12 00:30:56, David Tseng wrote:
> Keep these methods sorted.

Done.

https://codereview.chromium.org/175613002/diff/50001/content/browser/accessib...
content/browser/accessibility/browser_accessibility_cocoa.mm:870:
browserAccessibility_->GetIntListAttribute(ui::AX_ATTR_OWNS_IDS);
On 2014/03/11 23:37:52, dmazzoni wrote:
> These are all analogous, maybe a helper function to call three times with
> AX_ATTR_OWNS_IDS, ten AX_ATTR_CONTROLS_IDS, and so on?

Done.

> You could call the same from titleUIElement, too - and then only return the
> first one.

I don't think that's accurate, since the spec says it should only be exposed as
TitleUIElement if there is exactly one.

https://codereview.chromium.org/175613002/diff/50001/content/browser/accessib...
content/browser/accessibility/browser_accessibility_cocoa.mm:1301:
@"AXLinkedUIElements",
On 2014/03/12 00:30:56, David Tseng wrote:
> Ditto.

Done.

https://codereview.chromium.org/175613002/diff/50001/content/browser/accessib...
content/browser/accessibility/browser_accessibility_cocoa.mm:1301:
@"AXLinkedUIElements",
On 2014/03/12 00:30:56, David Tseng wrote:
> Ditto.

Done.

https://codereview.chromium.org/175613002/diff/50001/content/browser/accessib...
content/browser/accessibility/browser_accessibility_cocoa.mm:1402:
browserAccessibility_->HasIntListAttribute(ui::AX_ATTR_LABELLEDBY_IDS)) {
On 2014/03/12 00:30:56, David Tseng wrote:
> Technically, only if there's exactly one labelled by id.

True. I'll change it, but would there be an issue if it always "supported" it
but sometimes returned nil?

https://codereview.chromium.org/175613002/diff/50001/content/renderer/accessi...
File content/renderer/accessibility/accessibility_node_serializer.cc (right):

https://codereview.chromium.org/175613002/diff/50001/content/renderer/accessi...
content/renderer/accessibility/accessibility_node_serializer.cc:440: for(size_t
i = 0; i < describedby.size(); i++)
On 2014/03/11 23:37:52, dmazzoni wrote:
> Maybe a helper function here too - that goes from WebVector<WebAXObject> and
> calls AddIntListAttribute.

Done.

[David Tseng, 2014-03-12 18:30:17]

https://codereview.chromium.org/175613002/diff/50001/content/browser/accessib...
File content/browser/accessibility/browser_accessibility_cocoa.mm (right):

https://codereview.chromium.org/175613002/diff/50001/content/browser/accessib...
content/browser/accessibility/browser_accessibility_cocoa.mm:857: if
(labelledby_ids.size() == 1) {
On 2014/03/12 17:50:47, aboxhall wrote:
> On 2014/03/12 00:30:56, David Tseng wrote:
> > This is an interesting case.
> > 
> > Mac, unfortunately, doesn't have a good match for labelled by. The closest
is
> > ServesAsTitleForUIElements
> > which maps from the label to an array of ui elements it labels. Perhaps we
> could
> > fill in that relationship using labelled by when a BAC/BAMac gets
initialized.
> > (i.e. get the object pointed to by labelled by and fill in the elements it
> > labels as the originating object). The only disadvantage besides having to
> keep
> > more state around is that this won't work if the labelled by object hasn't
> > itself been initialized.
> 
> I don't completely follow, sorry. The spec says:
> If aria-labelledby references a single element, expose the labeling
relationship
> as element AXTitleUIElement.
> 
> If aria-labelledby references multiple elements, or if the labeling element is
> invisible or otherwise not exposed in the accessibility tree, use in
calculating
> the accessible name as described in Name Computation and expose value as
string
> AXDescription.
> 
> I believe we're already doing the latter in Blink?

No; this is Mac specific:
NSString *const NSAccessibilityServesAsTitleForUIElementsAttribute;

https://developer.apple.com/library/mac/documentation/cocoa/reference/applica...

https://codereview.chromium.org/175613002/diff/50001/content/browser/accessib...
content/browser/accessibility/browser_accessibility_cocoa.mm:1402:
browserAccessibility_->HasIntListAttribute(ui::AX_ATTR_LABELLEDBY_IDS)) {
On 2014/03/12 17:50:47, aboxhall wrote:
> On 2014/03/12 00:30:56, David Tseng wrote:
> > Technically, only if there's exactly one labelled by id.
> 
> True. I'll change it, but would there be an issue if it always "supported" it
> but sometimes returned nil?

Well, a client could request the attributes supported by this accessibility node
and react in some way, so I would say it could make a difference.

[aboxhall1, 2014-03-12 18:50:25]

On Mar 12, 2014 11:30 AM, <dtseng@chromium.org> wrote:
>
>
>
https://codereview.chromium.org/175613002/diff/50001/content/browser/accessib...
> File content/browser/accessibility/browser_accessibility_cocoa.mm
> (right):
>
>
https://codereview.chromium.org/175613002/diff/50001/content/browser/accessib...
> content/browser/accessibility/browser_accessibility_cocoa.mm:857: if
> (labelledby_ids.size() == 1) {
> On 2014/03/12 17:50:47, aboxhall wrote:
>>
>> On 2014/03/12 00:30:56, David Tseng wrote:
>> > This is an interesting case.
>> >
>> > Mac, unfortunately, doesn't have a good match for labelled by. The
>
> closest is
>>
>> > ServesAsTitleForUIElements
>> > which maps from the label to an array of ui elements it labels.
>
> Perhaps we
>>
>> could
>> > fill in that relationship using labelled by when a BAC/BAMac gets
>
> initialized.
>>
>> > (i.e. get the object pointed to by labelled by and fill in the
>
> elements it
>>
>> > labels as the originating object). The only disadvantage besides
>
> having to
>>
>> keep
>> > more state around is that this won't work if the labelled by object
>
> hasn't
>>
>> > itself been initialized.
>
>
>> I don't completely follow, sorry. The spec says:
>> If aria-labelledby references a single element, expose the labeling
>
> relationship
>>
>> as element AXTitleUIElement.
>
>
>> If aria-labelledby references multiple elements, or if the labeling
>
> element is
>>
>> invisible or otherwise not exposed in the accessibility tree, use in
>
> calculating
>>
>> the accessible name as described in Name Computation and expose value
>
> as string
>>
>> AXDescription.
>
>
>> I believe we're already doing the latter in Blink?
>
>
> No; this is Mac specific:
> NSString *const NSAccessibilityServesAsTitleForUIElementsAttribute;
>
>
https://developer.apple.com/library/mac/documentation/cocoa/reference/applica...

I still don't follow: this spec is mac specific as well.
>
>
>
https://codereview.chromium.org/175613002/diff/50001/content/browser/accessib...
> content/browser/accessibility/browser_accessibility_cocoa.mm:1402:
> browserAccessibility_->HasIntListAttribute(ui::AX_ATTR_LABELLEDBY_IDS))
> {
> On 2014/03/12 17:50:47, aboxhall wrote:
>>
>> On 2014/03/12 00:30:56, David Tseng wrote:
>> > Technically, only if there's exactly one labelled by id.
>
>
>> True. I'll change it, but would there be an issue if it always
>
> "supported" it
>>
>> but sometimes returned nil?
>
>
> Well, a client could request the attributes supported by this
> accessibility node and react in some way, so I would say it could make a
> difference.
>
> https://codereview.chromium.org/175613002/

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[David Tseng, 2014-03-12 19:16:56]

On Wed, Mar 12, 2014 at 11:50 AM, Alice Boxhall <aboxhall@google.com> wrote:

>
> On Mar 12, 2014 11:30 AM, <dtseng@chromium.org> wrote:
> >
> >
> >
>
https://codereview.chromium.org/175613002/diff/50001/content/browser/accessib...
> > File content/browser/accessibility/browser_accessibility_cocoa.mm
> > (right):
> >
> >
>
https://codereview.chromium.org/175613002/diff/50001/content/browser/accessib...
> > content/browser/accessibility/browser_accessibility_cocoa.mm:857: if
> > (labelledby_ids.size() == 1) {
> > On 2014/03/12 17:50:47, aboxhall wrote:
> >>
> >> On 2014/03/12 00:30:56, David Tseng wrote:
> >> > This is an interesting case.
> >> >
> >> > Mac, unfortunately, doesn't have a good match for labelled by. The
> >
> > closest is
> >>
> >> > ServesAsTitleForUIElements
> >> > which maps from the label to an array of ui elements it labels.
> >
> > Perhaps we
> >>
> >> could
> >> > fill in that relationship using labelled by when a BAC/BAMac gets
> >
> > initialized.
> >>
> >> > (i.e. get the object pointed to by labelled by and fill in the
> >
> > elements it
> >>
> >> > labels as the originating object). The only disadvantage besides
> >
> > having to
> >>
> >> keep
> >> > more state around is that this won't work if the labelled by object
> >
> > hasn't
> >>
> >> > itself been initialized.
> >
> >
> >> I don't completely follow, sorry. The spec says:
> >> If aria-labelledby references a single element, expose the labeling
> >
> > relationship
> >>
> >> as element AXTitleUIElement.
> >
> >
> >> If aria-labelledby references multiple elements, or if the labeling
> >
> > element is
> >>
> >> invisible or otherwise not exposed in the accessibility tree, use in
> >
> > calculating
> >>
> >> the accessible name as described in Name Computation and expose value
> >
> > as string
> >>
> >> AXDescription.
> >
> >
> >> I believe we're already doing the latter in Blink?
> >
> >
> > No; this is Mac specific:
> > NSString *const NSAccessibilityServesAsTitleForUIElementsAttribute;
> >
> >
>
https://developer.apple.com/library/mac/documentation/cocoa/reference/applica...
>
> I still don't follow: this spec is mac specific as well.
>

Yes. Perhaps a chat? We need to support this attribute just as you
supported linkedUIElements, and we previously supported titleUIElement.

So, the task is to add NSAccessibilityServesAsTitleForUIElements under
accessibilityAttributeNames and add a mapping for that attribute to a
method.

I guess if you want, we could add a TODO to support that attribute.

> >
> >
> >
>
https://codereview.chromium.org/175613002/diff/50001/content/browser/accessib...
> > content/browser/accessibility/browser_accessibility_cocoa.mm:1402:
> > browserAccessibility_->HasIntListAttribute(ui::AX_ATTR_LABELLEDBY_IDS))
> > {
> > On 2014/03/12 17:50:47, aboxhall wrote:
> >>
> >> On 2014/03/12 00:30:56, David Tseng wrote:
> >> > Technically, only if there's exactly one labelled by id.
> >
> >
> >> True. I'll change it, but would there be an issue if it always
> >
> > "supported" it
> >>
> >> but sometimes returned nil?
> >
> >
> > Well, a client could request the attributes supported by this
> > accessibility node and react in some way, so I would say it could make a
> > difference.
> >
> > https://codereview.chromium.org/175613002/
>
>  To unsubscribe from this group and stop receiving emails from it, send an
> email to chromium-reviews+unsubscribe@chromium.org.
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[aboxhall, 2014-03-12 20:51:46]

https://codereview.chromium.org/175613002/diff/50001/content/browser/accessib...
File content/browser/accessibility/browser_accessibility_cocoa.mm (right):

https://codereview.chromium.org/175613002/diff/50001/content/browser/accessib...
content/browser/accessibility/browser_accessibility_cocoa.mm:857: if
(labelledby_ids.size() == 1) {
On 2014/03/12 18:30:17, David Tseng wrote:
> On 2014/03/12 17:50:47, aboxhall wrote:
> > On 2014/03/12 00:30:56, David Tseng wrote:
> > > This is an interesting case.
> > > 
> > > Mac, unfortunately, doesn't have a good match for labelled by. The closest
> is
> > > ServesAsTitleForUIElements
> > > which maps from the label to an array of ui elements it labels. Perhaps we
> > could
> > > fill in that relationship using labelled by when a BAC/BAMac gets
> initialized.
> > > (i.e. get the object pointed to by labelled by and fill in the elements it
> > > labels as the originating object). The only disadvantage besides having to
> > keep
> > > more state around is that this won't work if the labelled by object hasn't
> > > itself been initialized.
> > 
> > I don't completely follow, sorry. The spec says:
> > If aria-labelledby references a single element, expose the labeling
> relationship
> > as element AXTitleUIElement.
> > 
> > If aria-labelledby references multiple elements, or if the labeling element
is
> > invisible or otherwise not exposed in the accessibility tree, use in
> calculating
> > the accessible name as described in Name Computation and expose value as
> string
> > AXDescription.
> > 
> > I believe we're already doing the latter in Blink?
> 
> No; this is Mac specific:
> NSString *const NSAccessibilityServesAsTitleForUIElementsAttribute;
> 
>
https://developer.apple.com/library/mac/documentation/cocoa/reference/applica...

Added TODO as discussed.

[David Tseng, 2014-03-12 21:00:19]

LGTM

https://codereview.chromium.org/175613002/diff/90001/content/browser/accessib...
File content/browser/accessibility/browser_accessibility_cocoa.mm (right):

https://codereview.chromium.org/175613002/diff/90001/content/browser/accessib...
content/browser/accessibility/browser_accessibility_cocoa.mm:1402: // for
elements which are referred to by labelledby or are labels
nit: period.

Not sure if we should suggest this attribute to be speced in aria? Not sure how
that's done.

[aboxhall, 2014-03-13 03:07:20]

On 2014/03/12 21:00:19, David Tseng wrote:
> LGTM
> 
>
https://codereview.chromium.org/175613002/diff/90001/content/browser/accessib...
> File content/browser/accessibility/browser_accessibility_cocoa.mm (right):
> 
>
https://codereview.chromium.org/175613002/diff/90001/content/browser/accessib...
> content/browser/accessibility/browser_accessibility_cocoa.mm:1402: // for
> elements which are referred to by labelledby or are labels
> nit: period.
> 
> Not sure if we should suggest this attribute to be speced in aria? Not sure
how
> that's done.

Yeah, would be nice - Dominic might have some suggestions on who to contact. 

Would someone be able to CQ this once blink DEPS rolls past 169076?
http://src.chromium.org/viewvc/chrome/trunk/src/DEPS?view=log#revHEAD 
I'll be out of commission for the next 24 hours or so; hopefully by tomorrow
morning this will be committable.

[aboxhall, 2014-03-14 09:54:07]

The CQ bit was checked by aboxhall@chromium.org

[commit-bot: I haz the power, 2014-03-14 09:54:15]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/aboxhall@chromium.org/175613002/90001

[commit-bot: I haz the power, 2014-03-14 09:55:12]

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

[commit-bot: I haz the power, 2014-03-14 09:55:12]

Try jobs failed on following builders:
  tryserver.chromium on linux_chromium_clang_dbg

[aboxhall, 2014-03-14 10:01:37]

The CQ bit was checked by aboxhall@chromium.org

[commit-bot: I haz the power, 2014-03-14 10:01:45]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/aboxhall@chromium.org/175613002/90001

[commit-bot: I haz the power, 2014-03-14 10:03:15]

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

[commit-bot: I haz the power, 2014-03-14 10:03:16]

Try jobs failed on following builders:
  tryserver.chromium on linux_chromium_clang_dbg

[aboxhall, 2014-03-14 10:23:39]

The CQ bit was checked by aboxhall@chromium.org

[commit-bot: I haz the power, 2014-03-14 10:23:46]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/aboxhall@chromium.org/175613002/90001

[commit-bot: I haz the power, 2014-03-14 10:59:42]

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

[commit-bot: I haz the power, 2014-03-14 10:59:43]

Try jobs failed on following builders:
  tryserver.chromium on mac_chromium_rel

[aboxhall, 2014-03-17 10:01:13]

The CQ bit was checked by aboxhall@chromium.org

[commit-bot: I haz the power, 2014-03-17 10:01:16]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/aboxhall@chromium.org/175613002/110001

[commit-bot: I haz the power, 2014-03-17 10:02:36]

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

[commit-bot: I haz the power, 2014-03-17 10:02:37]

Try jobs failed on following builders:
  tryserver.chromium on linux_chromium_clang_dbg

[dmazzoni, 2014-03-17 14:50:31]

The CQ bit was checked by dmazzoni@chromium.org

[commit-bot: I haz the power, 2014-03-17 14:50:33]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/aboxhall@chromium.org/175613002/110001

[commit-bot: I haz the power, 2014-03-17 23:16:56]

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

[commit-bot: I haz the power, 2014-03-17 23:16:57]

The commit queue went berserk retrying too often for a
seemingly flaky test on builder android_dbg:
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_db...
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_db...
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_db...
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_db...
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_db...

[aboxhall, 2014-03-18 13:39:22]

On 2014/03/17 23:16:57, I haz the power (commit-bot) wrote:
> The commit queue went berserk retrying too often for a
> seemingly flaky test on builder android_dbg:
>
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_db...
>
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_db...
>
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_db...
>
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_db...
>
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_db...

This is running the test on Android despite having #<skip in the expectation
file:

Value of: is_different
  Actual: true
Expected: false
* Line Expected
- ---- --------
*    1 <-- End-of-file -->

Actual
------
android.webkit.WebView focusable focused scrollable
    android.view.View clickable name='Lorem ipsum'
    android.view.View clickable name='dolor sit amet'

../../content/browser/accessibility/dump_accessibility_tree_browsertest.cc:239:
Failure
Failed
No expectation found. Create it by doing:
mv
/storage/emulated/0/content/test/data/accessibility/aria-flowto-actual-android.txt
/storage/emulated/0/content/test/data/accessibility/aria-flowto-expected-android.txt

vs 

% cat content/test/data/accessibility/aria-flowto-expected-android.txt
#<skip - need to generate expectation>

@dmazzoni: Have I done something wrong here? Why is this happening?

[aboxhall, 2014-03-18 13:40:39]

On 2014/03/18 13:39:22, aboxhall wrote:
> On 2014/03/17 23:16:57, I haz the power (commit-bot) wrote:
> > The commit queue went berserk retrying too often for a
> > seemingly flaky test on builder android_dbg:
> >
>
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_db...
> >
>
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_db...
> >
>
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_db...
> >
>
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_db...
> >
>
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_db...
> 
> This is running the test on Android despite having #<skip in the expectation
> file:
> 
> Value of: is_different
>   Actual: true
> Expected: false
> * Line Expected
> - ---- --------
> *    1 <-- End-of-file -->
> 
> Actual
> ------
> android.webkit.WebView focusable focused scrollable
>     android.view.View clickable name='Lorem ipsum'
>     android.view.View clickable name='dolor sit amet'
> 
>
../../content/browser/accessibility/dump_accessibility_tree_browsertest.cc:239:
> Failure
> Failed
> No expectation found. Create it by doing:
> mv
>
/storage/emulated/0/content/test/data/accessibility/aria-flowto-actual-android.txt
>
/storage/emulated/0/content/test/data/accessibility/aria-flowto-expected-android.txt
> 
> vs 
> 
> % cat content/test/data/accessibility/aria-flowto-expected-android.txt
> #<skip - need to generate expectation>
> 
> @dmazzoni: Have I done something wrong here? Why is this happening?

It seems like it's not finding the expectation there, but it's there in the CL,
so I don't understand why this is happening.

[dmazzoni, 2014-03-19 07:22:00]

If all else fails, you can disable the test (in the C++ code) on Android only
for now.

[aboxhall, 2014-03-20 14:33:56]

The CQ bit was checked by aboxhall@chromium.org

[commit-bot: I haz the power, 2014-03-20 14:35:55]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/aboxhall@chromium.org/175613002/130001

[commit-bot: I haz the power, 2014-03-20 14:38:07]

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

[commit-bot: I haz the power, 2014-03-20 14:38:08]

Try jobs failed on following builders:
  tryserver.chromium on linux_chromium_clang_dbg

[aboxhall, 2014-03-20 15:17:08]

The CQ bit was checked by aboxhall@chromium.org

[commit-bot: I haz the power, 2014-03-20 15:17:49]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/aboxhall@chromium.org/175613002/130001

[commit-bot: I haz the power, 2014-03-20 16:10:53]

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

[commit-bot: I haz the power, 2014-03-20 16:10:54]

Try jobs failed on following builders:
  tryserver.chromium on mac_chromium_rel

[aboxhall, 2014-03-20 16:23:08]

The CQ bit was checked by aboxhall@chromium.org

[commit-bot: I haz the power, 2014-03-20 16:23:55]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/aboxhall@chromium.org/175613002/130001

[commit-bot: I haz the power, 2014-03-21 02:18:14]

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

[commit-bot: I haz the power, 2014-03-21 02:18:14]

The commit queue went berserk retrying too often for a
seemingly flaky test on builder android_dbg:
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_db...
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_db...
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_db...
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_db...
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_db...
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_db...

[aboxhall, 2014-03-24 10:16:16]

The CQ bit was checked by aboxhall@chromium.org

[commit-bot: I haz the power, 2014-03-24 10:16:18]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/aboxhall@chromium.org/175613002/150001

[commit-bot: I haz the power, 2014-03-24 12:02:36]

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

[commit-bot: I haz the power, 2014-03-24 12:02:37]

Retried try job too often on win_rel for step(s) browser_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_rel&nu...

[aboxhall, 2014-03-24 12:14:46]

The CQ bit was checked by aboxhall@chromium.org

[commit-bot: I haz the power, 2014-03-24 12:14:49]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/aboxhall@chromium.org/175613002/150001

[commit-bot: I haz the power, 2014-03-24 14:40:44]

Change committed as 258928