Text controls should expose their value instead of their name via IAccessibleText

Text controls should expose their value instead of their name via IAccessibleText.

Otherwise the user could potentially cursor through their value while listenning to their name/label.
Example: data:text/html,<input type="text" role="combobox" value="test" aria-label="name">
This issue affects the NVDA screen reader.
TESTED=NVDA Python console,unit test,browser tests
BUG=440653
R=dmazzoni@chromium.org, aboxhall@chromium.org

Committed: https://crrev.com/ede890769a7bcc9dabb673f7332948946c76de99
Cr-Commit-Position: refs/heads/master@{#357849}

[nektarios, 2015-10-29 16:36:57]

Description was changed from

==========
Controls with a value should provide their value instead of their name when
retrieving their text using IAccessibleText.

Otherwise the user could potentially cursor through their value while listenning
to their name.
Example: data:text/html,<input type="text" role="combobox" value="test"
aria-label="name">
BUG=440653
R=dmazzoni@chromium.org
==========

to

==========
Controls with a value should provide their value instead of their name when
retrieving their text using IAccessibleText.

Otherwise the user could potentially cursor through their value while listenning
to their name/label.
Example: data:text/html,<input type="text" role="combobox" value="test"
aria-label="name">
This issue affects the NVDA screen reader.
TESTED=NVDA Python console,unit test,browser tests
BUG=440653
R=dmazzoni@chromium.org, aboxhall@chromium.org
==========

[nektarios, 2015-10-29 16:36:57]

nektar@chromium.org changed reviewers:
+ aboxhall@chromium.org

[aboxhall, 2015-10-29 17:58:49]

https://codereview.chromium.org/1416873015/diff/20001/content/browser/accessi...
File content/browser/accessibility/browser_accessibility.cc (left):

https://codereview.chromium.org/1416873015/diff/20001/content/browser/accessi...
content/browser/accessibility/browser_accessibility.cc:688: bool
BrowserAccessibility::IsControl() const {
So this method was never called previously?

https://codereview.chromium.org/1416873015/diff/20001/content/browser/accessi...
File content/browser/accessibility/browser_accessibility.cc (right):

https://codereview.chromium.org/1416873015/diff/20001/content/browser/accessi...
content/browser/accessibility/browser_accessibility.cc:688: // Some controls
(native or ARIA-based) expose a visible value which is
Put this comment in the header file instead.

https://codereview.chromium.org/1416873015/diff/20001/content/browser/accessi...
File content/browser/accessibility/browser_accessibility.h (right):

https://codereview.chromium.org/1416873015/diff/20001/content/browser/accessi...
content/browser/accessibility/browser_accessibility.h:278: bool
IsControlWithValue() const;
I would call this something like IsControlWithVisibleValue or
IsControlWithMeaningfulValue - checkboxes have a (checked/not checked) value,
but that value isn't interesting.

https://codereview.chromium.org/1416873015/diff/20001/content/browser/accessi...
File content/browser/accessibility/browser_accessibility_win.cc (left):

https://codereview.chromium.org/1416873015/diff/20001/content/browser/accessi...
content/browser/accessibility/browser_accessibility_win.cc:4027: case
ui::AX_ROLE_MENU_LIST_OPTION:
So behaviour will change for menu list option as well? We should probably have a
test for that.

https://codereview.chromium.org/1416873015/diff/20001/content/browser/accessi...
File content/browser/accessibility/browser_accessibility_win_unittest.cc (left):

https://codereview.chromium.org/1416873015/diff/20001/content/browser/accessi...
content/browser/accessibility/browser_accessibility_win_unittest.cc:532:
EXPECT_EQ(E_INVALIDARG, root_obj->get_hyperlink(29, hyperlink.Receive()));
Where did this go?

https://codereview.chromium.org/1416873015/diff/20001/content/browser/accessi...
File content/browser/accessibility/browser_accessibility_win_unittest.cc
(right):

https://codereview.chromium.org/1416873015/diff/20001/content/browser/accessi...
content/browser/accessibility/browser_accessibility_win_unittest.cc:555: const
base::string16 link_text_name = L"Blue";
Maybe add a radio button or check box here as well?

https://codereview.chromium.org/1416873015/diff/20001/content/browser/accessi...
content/browser/accessibility/browser_accessibility_win_unittest.cc:605:
root.child_ids.push_back(11);
suggestion only: this might be more readable if we used e.g.
root.child_ids.push_back(text1.id);

[dmazzoni, 2015-10-29 20:15:29]

https://codereview.chromium.org/1416873015/diff/40001/content/browser/accessi...
File content/browser/accessibility/browser_accessibility_win.cc (right):

https://codereview.chromium.org/1416873015/diff/40001/content/browser/accessi...
content/browser/accessibility/browser_accessibility_win.cc:3531: if
(IsControlWithValue())
I like the idea behind this change, but I don't think IsControlWithValue is the
correct semantics.

Only a *text* control should expose its value via IAccessibleText.

So a combo box or search box role, absolutely - that's a valid fix. Maybe a
couple of others.

A slider or listbox? No, I don't buy it. You can't arrow through the characters
in the values of those roles, so it doesn't make sense to expose anything via
IAccessibleText for those controls. We already have accValue for those.

[chromium-reviews, 2015-10-29 20:42:57]

I included sliders and scrollbars because the ARIA Spec has the 
aria-valuetext attribute which sounded like something that should be 
exposed in IAccessibleText.
Besides, I don't think it matters if you can arrow through the value or 
not because IAccessibleText is not used only for editable text which 
cursorring might imply. We have accValue for text boxes as well and 
IAccessibleText is also available.
You are right though, that it could be argued both ways. I think it's 
best to implement IAccessibleText everywhere for consistency.

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

[chromium-reviews, 2015-10-29 21:13:44]

On 10/29/2015 1:58 PM, aboxhall@chromium.org wrote:
>
>
https://codereview.chromium.org/1416873015/diff/20001/content/browser/accessi...

>
> File content/browser/accessibility/browser_accessibility.cc (left):
>
>
https://codereview.chromium.org/1416873015/diff/20001/content/browser/accessi...

>
> content/browser/accessibility/browser_accessibility.cc:688: bool
> BrowserAccessibility::IsControl() const {
> So this method was never called previously?
>
Re-introduced with an expanded list of controls after carefully looking 
through all AX roles.

>
https://codereview.chromium.org/1416873015/diff/20001/content/browser/accessi...

>
> File content/browser/accessibility/browser_accessibility.cc (right):
>
>
https://codereview.chromium.org/1416873015/diff/20001/content/browser/accessi...

>
> content/browser/accessibility/browser_accessibility.cc:688: // Some
> controls (native or ARIA-based) expose a visible value which is
> Put this comment in the header file instead.
>
I have a shorter comment in the header file. Since implementations 
describe the "why", I think I should leave it here?

>
https://codereview.chromium.org/1416873015/diff/20001/content/browser/accessi...

>
> File content/browser/accessibility/browser_accessibility.h (right):
>
>
https://codereview.chromium.org/1416873015/diff/20001/content/browser/accessi...

>
> content/browser/accessibility/browser_accessibility.h:278: bool
> IsControlWithValue() const;
> I would call this something like IsControlWithVisibleValue or
> IsControlWithMeaningfulValue - checkboxes have a (checked/not checked)
> value, but that value isn't interesting.
>
Done. IsControlWithVisibleValue.

>
https://codereview.chromium.org/1416873015/diff/20001/content/browser/accessi...

>
> File content/browser/accessibility/browser_accessibility_win.cc (left):
>
>
https://codereview.chromium.org/1416873015/diff/20001/content/browser/accessi...

>
> content/browser/accessibility/browser_accessibility_win.cc:4027: case
> ui::AX_ROLE_MENU_LIST_OPTION:
> So behaviour will change for menu list option as well? We should
> probably have a test for that.
>
Added many browser tests.

>
https://codereview.chromium.org/1416873015/diff/20001/content/browser/accessi...

>
> File content/browser/accessibility/browser_accessibility_win_unittest.cc
> (left):
>
>
https://codereview.chromium.org/1416873015/diff/20001/content/browser/accessi...

>
> content/browser/accessibility/browser_accessibility_win_unittest.cc:532:
> EXPECT_EQ(E_INVALIDARG, root_obj->get_hyperlink(29,
> hyperlink.Receive()));
> Where did this go?
>
I added it back but made test clearer.

>
https://codereview.chromium.org/1416873015/diff/20001/content/browser/accessi...

>
> File content/browser/accessibility/browser_accessibility_win_unittest.cc
> (right):
>
>
https://codereview.chromium.org/1416873015/diff/20001/content/browser/accessi...

>
> content/browser/accessibility/browser_accessibility_win_unittest.cc:555:
> const base::string16 link_text_name = L"Blue";
> Maybe add a radio button or check box here as well?
>
Done. A check box.

>
https://codereview.chromium.org/1416873015/diff/20001/content/browser/accessi...

>
> content/browser/accessibility/browser_accessibility_win_unittest.cc:605:
> root.child_ids.push_back(11);
> suggestion only: this might be more readable if we used e.g.
> root.child_ids.push_back(text1.id);
>
Done. In TestSimpleHypertext and TestComplexHypertext.

> https://codereview.chromium.org/1416873015/

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

[dmazzoni, 2015-10-29 21:39:03]

Perhaps the best would be to check what Firefox does.

I'd be really surprised if Firefox exposes the value of a slider or
scrollbar in IAccessibleText, but if they do, then that's fine.

Alternatively, have you tried navigating through some native slider and
ARIA sliders with this change patched in? Does it do what you expect?

On Thu, Oct 29, 2015 at 1:42 PM Nektarios Paisios <nektar@google.com> wrote:

> I included sliders and scrollbars because the ARIA Spec has the
> aria-valuetext attribute which sounded like something that should be
> exposed in IAccessibleText.
> Besides, I don't think it matters if you can arrow through the value or
> not because IAccessibleText is not used only for editable text which
> cursorring might imply. We have accValue for text boxes as well and
> IAccessibleText is also available.
> You are right though, that it could be argued both ways. I think it's
> best to implement IAccessibleText everywhere for consistency.
>
>

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

[chromium-reviews, 2015-10-29 21:47:44]

In any case, something would need to be changed because the current
implementation provides the label in IAccessibleText. Changing it to return
the empty string requires a patch too.
N

On Thursday, October 29, 2015, Nektarios Paisios <nektar@google.com> wrote:

> I included sliders and scrollbars because the ARIA Spec has the
> aria-valuetext attribute which sounded like something that should be
> exposed in IAccessibleText.
> Besides, I don't think it matters if you can arrow through the value or
> not because IAccessibleText is not used only for editable text which
> cursorring might imply. We have accValue for text boxes as well and
> IAccessibleText is also available.
> You are right though, that it could be argued both ways. I think it's best
> to implement IAccessibleText everywhere for consistency.
>
>

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

[dmazzoni, 2015-10-29 22:09:48]

Interesting. I'm not sure what it should return. I guess you could make the
argument it could return both, i.e. "label: value". Let's see what Firefox
does. Are you able to get accProbe to work enough to get that answer or
should I check for you?

On Thu, Oct 29, 2015 at 2:47 PM Nektarios Paisios <nektar@google.com> wrote:

> In any case, something would need to be changed because the current
> implementation provides the label in IAccessibleText. Changing it to return
> the empty string requires a patch too.
> N
>
>
> On Thursday, October 29, 2015, Nektarios Paisios <nektar@google.com>
> wrote:
>
>> I included sliders and scrollbars because the ARIA Spec has the
>> aria-valuetext attribute which sounded like something that should be
>> exposed in IAccessibleText.
>> Besides, I don't think it matters if you can arrow through the value or
>> not because IAccessibleText is not used only for editable text which
>> cursorring might imply. We have accValue for text boxes as well and
>> IAccessibleText is also available.
>> You are right though, that it could be argued both ways. I think it's
>> best to implement IAccessibleText everywhere for consistency.
>>
>>

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

[chromium-reviews, 2015-10-30 19:32:36]

I created a page in Firefox with multiple controls including native and 
ARIA-based combo boxes, search boxes, date and time fields, sliders and 
scroll bars, a color well and some list boxes.
Calling IAccessibleText.get_text(0, IA2_TEXT_LENGTH) using the NVDA 
Python Console ignores the aria-label and returns the value for all 
controls except sliders, scroll bars and native list boxes.
However, there is a lot of confusion. IAccessibleText is not implemented 
(not exposed) at all for some controls like scroll bars sliders, ARIA 
check boxes and native list boxes. For other controls such as scroll 
bars and sliders I think, IAccessibleText is only implemented if there 
is some text inside the div like in this example:
<div role="scrollbar" aria-valuenow="55">scroll bar</div>
In Chrome we do expose IAccessibleText and I don't think we should 
simply return emptyfor get_text. We should either return the value or 
stop exposing IAccessibleText for a set of controls.
I suggest that we return the value for all controls. Easier and more 
consistent. Also, it should be noted that Firefox, implementation is 
somewhat temperamental. I can't easily predict when IAccessibleText will 
be implemented and when not, unless the NVDA Python Console doesn't 
expose everything as Firefox presents it.

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

[aboxhall, 2015-10-30 19:40:46]

https://codereview.chromium.org/1416873015/diff/60001/content/browser/accessi...
File content/browser/accessibility/browser_accessibility.h (right):

https://codereview.chromium.org/1416873015/diff/60001/content/browser/accessi...
content/browser/accessibility/browser_accessibility.h:277: bool IsControl()
const;
Perhaps reinstate the method comment as well?

https://codereview.chromium.org/1416873015/diff/60001/content/test/data/acces...
File content/test/data/accessibility/html/input-radio-in-menu-expected-win.txt
(right):

https://codereview.chromium.org/1416873015/diff/60001/content/test/data/acces...
content/test/data/accessibility/html/input-radio-in-menu-expected-win.txt:3:
++++IA2_ROLE_RADIO_MENU_ITEM MIXED FOCUSABLE checkable:true
ia2_hypertext='Radio1'
This is interesting. I wouldn't expect a radio button value to be exposed.

[dmazzoni, 2015-10-30 19:42:31]

Thanks for doing the detailed test!

Note that in Chrome we can easily not expose IAccessibleText by role, by
modifying the QueryInterface implementation. So if you want to just not
support IAccessibleText on some control types, that seems fine too.

Sliders, scroll bars, and native list boxes are exactly the ones that worry
me. Firefox doesn't return those values in IAccessibleText and I'm not
quite sure why we should either. And if you test the patch with both NVDA
and JAWS, and don't see any problems then that'd make me feel better.


On Fri, Oct 30, 2015 at 12:32 PM Nektarios Paisios <nektar@google.com>
wrote:

> I created a page in Firefox with multiple controls including native and
> ARIA-based combo boxes, search boxes, date and time fields, sliders and
> scroll bars, a color well and some list boxes.
> Calling IAccessibleText.get_text(0, IA2_TEXT_LENGTH) using the NVDA
> Python Console ignores the aria-label and returns the value for all
> controls except sliders, scroll bars and native list boxes.
> However, there is a lot of confusion. IAccessibleText is not implemented
> (not exposed) at all for some controls like scroll bars sliders, ARIA
> check boxes and native list boxes. For other controls such as scroll
> bars and sliders I think, IAccessibleText is only implemented if there
> is some text inside the div like in this example:
> <div role="scrollbar" aria-valuenow="55">scroll bar</div>
> In Chrome we do expose IAccessibleText and I don't think we should
> simply return emptyfor get_text. We should either return the value or
> stop exposing IAccessibleText for a set of controls.
> I suggest that we return the value for all controls. Easier and more
> consistent. Also, it should be noted that Firefox, implementation is
> somewhat temperamental. I can't easily predict when IAccessibleText will
> be implemented and when not, unless the NVDA Python Console doesn't
> expose everything as Firefox presents it.
>
>

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

[chromium-reviews, 2015-10-30 19:45:22]

I'll test thoroughly before submitting, but this patch is not the end of 
the story. I think we should have a quick 1:1 and think through the 
options and possibly bring in the NVDA devs.

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

[chromium-reviews, 2015-10-30 20:45:33]

According to IA2 Spec:
> The IAccessibleText interface should be implemented by all components 
> that present textual information on the display 

So, sliders and scroll bars should be excluded because they don't 
present any textual information but list boxes would seem to be in.
The corner case is the one I discovered when testing with Firefox, i.e. 
when there is text within an ARIA-based slider or scroll bar, the text 
should be available through IAccessibleText because it appears on the 
display.
In short, for all controls what matters is the visible text that is 
inside the control. If this happens to be the value of the control, 
that's coincidental.
In the accessibility tree, the value attribute holds the text under the 
control, but it seems that for some controls we re-purpose it to mean 
the control's actual value and not the text inside it.

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

[chromium-reviews, 2015-10-30 23:08:41]

After discussing offline with dmazzoni, I have modified my patch to 
return the value for only text controls for now. Another patch that will 
return visible text under controls that could expose such text will be 
implemented in the future, but it might require changes to Blink and so 
it might not happen right away.
We also need to stop exposing IAccessibleText for controls that have no 
visible text under them. Again, this work will be moved to another patch.
Please have another look.

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

[chromium-reviews, 2015-10-30 23:12:30]

https://codereview.chromium.org/1416873015/diff/60001/content/browser/accessi...


> File content/browser/accessibility/browser_accessibility.h (right):
>
>
https://codereview.chromium.org/1416873015/diff/60001/content/browser/accessi...

>
> content/browser/accessibility/browser_accessibility.h:277: bool
> IsControl() const;
> Perhaps reinstate the method comment as well?
>
I would rather not because it sounds superfluous, unless it is not 
readily apparent what "control" stands for?


>
https://codereview.chromium.org/1416873015/diff/60001/content/test/data/acces...

>
> File
> content/test/data/accessibility/html/input-radio-in-menu-expected-win.txt
> (right):
>
>
https://codereview.chromium.org/1416873015/diff/60001/content/test/data/acces...

>
> content/test/data/accessibility/html/input-radio-in-menu-expected-win.txt:3: 
>
> ++++IA2_ROLE_RADIO_MENU_ITEM MIXED FOCUSABLE checkable:true
> ia2_hypertext='Radio1'
> This is interesting. I wouldn't expect a radio button value to be
> exposed.
>
Oh, I wanted to expose the text of the menu item.
I'll go through all my browser tests once more.

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

[nektarios, 2015-10-30 23:16:02]

Description was changed from

==========
Controls with a value should provide their value instead of their name when
retrieving their text using IAccessibleText.

Otherwise the user could potentially cursor through their value while listenning
to their name/label.
Example: data:text/html,<input type="text" role="combobox" value="test"
aria-label="name">
This issue affects the NVDA screen reader.
TESTED=NVDA Python console,unit test,browser tests
BUG=440653
R=dmazzoni@chromium.org, aboxhall@chromium.org
==========

to

==========
Text controls should expose their value instead of their name via
IAccessibleText.

Otherwise the user could potentially cursor through their value while listenning
to their name/label.
Example: data:text/html,<input type="text" role="combobox" value="test"
aria-label="name">
This issue affects the NVDA screen reader.
TESTED=NVDA Python console,unit test,browser tests
BUG=440653
R=dmazzoni@chromium.org, aboxhall@chromium.org
==========

[chromium-reviews, 2015-11-02 23:06:11]

Browser tests updated.
You may have another look.

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

[dmazzoni, 2015-11-02 23:17:48]

lgtm

[aboxhall, 2015-11-02 23:22:47]

lgtm

I'm still not clear on when hypertext should and should not show up, but I'm
happy to take your word on it at this point.

https://codereview.chromium.org/1416873015/diff/100001/content/test/data/acce...
File content/test/data/accessibility/html/input-radio-in-menu-expected-win.txt
(right):

https://codereview.chromium.org/1416873015/diff/100001/content/test/data/acce...
content/test/data/accessibility/html/input-radio-in-menu-expected-win.txt:3:
++++IA2_ROLE_RADIO_MENU_ITEM MIXED FOCUSABLE checkable:true
ia2_hypertext='Radio1'
This might be a more interesting check if we removed the menu text content
altogether in one or both cases, to ensure that the value is no longer exposed.

https://codereview.chromium.org/1416873015/diff/100001/content/test/data/acce...
File content/test/data/accessibility/html/input-search-expected-mac.txt (right):

https://codereview.chromium.org/1416873015/diff/100001/content/test/data/acce...
content/test/data/accessibility/html/input-search-expected-mac.txt:3:
++++AXTextField AXRoleDescription='text field' AXValue='Search terms'
No hypertext?

[chromium-reviews, 2015-11-03 02:37:50]

On 11/2/2015 6:22 PM, aboxhall@chromium.org wrote:
> I'm still not clear on when hypertext should and should not show up, 
> but I'm
> happy to take your word on it at this point.
>
> Don't worry, it took me a few days and re-reading the spec and a chat 
> with Dominic.
Hypertext should only appear when a control exposes visible text, either 
directly or through its children. Hypertext should also appear if there 
are any embedded objects, hence the hypertext on the section and 
document objects.
Sliders and scroll bars show no visible text, hence no hypertext.
The value of the check box or a radio button is not visible, hence it 
should not be in hypertext.
ARIA sliders and scroll bars that show visible text because their 
designers chose not to show the standard UI, should expose hypertext, 
but we chose to postpone this edge case for a future patch.
We also chose to behave like Firefox and don't include the label (even 
though it's visible text) as part of the hypertext when it comes to text 
boxes, search boxes and combo boxes. This is because if we do it would 
break compatibility with screen readers like NVDA which use hypertext to 
get the value of these controls, and because returning both the value 
and the label could be harder for them to parse. What format could we 
have chosen "label: value"?


>
https://codereview.chromium.org/1416873015/diff/100001/content/test/data/acce...

>
> File
> content/test/data/accessibility/html/input-radio-in-menu-expected-win.txt
> (right):
>
>
https://codereview.chromium.org/1416873015/diff/100001/content/test/data/acce...

>
> content/test/data/accessibility/html/input-radio-in-menu-expected-win.txt:3: 
>
> ++++IA2_ROLE_RADIO_MENU_ITEM MIXED FOCUSABLE checkable:true
> ia2_hypertext='Radio1'
> This might be a more interesting check if we removed the menu text
> content altogether in one or both cases, to ensure that the value is no
> longer exposed.
>
Done. Great idea.

>
https://codereview.chromium.org/1416873015/diff/100001/content/test/data/acce...

>
> File content/test/data/accessibility/html/input-search-expected-mac.txt
> (right):
>
>
https://codereview.chromium.org/1416873015/diff/100001/content/test/data/acce...

>
> content/test/data/accessibility/html/input-search-expected-mac.txt:3:
> ++++AXTextField AXRoleDescription='text field' AXValue='Search terms'
> No hypertext?
>
Hypertext is a Windows-only thing.

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

[nektarios, 2015-11-03 03:06:02]

The CQ bit was checked by nektar@chromium.org

[nektarios, 2015-11-03 03:06:02]

The patchset sent to the CQ was uploaded after l-g-t-m from
dmazzoni@chromium.org, aboxhall@chromium.org
Link to the patchset: https://codereview.chromium.org/1416873015/#ps120001
(title: "Fixed test expectations.")

[commit-bot: I haz the power, 2015-11-03 03:06:33]

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

[commit-bot: I haz the power, 2015-11-03 03:59:39]

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

[commit-bot: I haz the power, 2015-11-03 03:59:41]

Try jobs failed on following builders:
  ios_dbg_simulator_ninja on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_dbg_simulator...)

[nektarios, 2015-11-03 15:01:32]

The CQ bit was checked by nektar@chromium.org

[commit-bot: I haz the power, 2015-11-03 15:02:59]

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

[commit-bot: I haz the power, 2015-11-03 16:06:01]

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

[commit-bot: I haz the power, 2015-11-03 16:06:02]

Try jobs failed on following builders:
  win_chromium_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[nektarios, 2015-11-03 16:17:32]

The CQ bit was checked by nektar@chromium.org

[nektarios, 2015-11-03 16:17:32]

The patchset sent to the CQ was uploaded after l-g-t-m from
dmazzoni@chromium.org, aboxhall@chromium.org
Link to the patchset: https://codereview.chromium.org/1416873015/#ps140001
(title: "Fixed test expectations.")

[commit-bot: I haz the power, 2015-11-03 16:18:39]

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

[commit-bot: I haz the power, 2015-11-03 18:29:57]

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

[commit-bot: I haz the power, 2015-11-03 18:29:58]

Try jobs failed on following builders:
  linux_android_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_android_r...)

[nektarios, 2015-11-03 22:26:54]

The CQ bit was checked by nektar@chromium.org

[nektarios, 2015-11-03 22:26:54]

The patchset sent to the CQ was uploaded after l-g-t-m from
dmazzoni@chromium.org, aboxhall@chromium.org
Link to the patchset: https://codereview.chromium.org/1416873015/#ps160001
(title: "Fixed radio menu items test on Android.")

[commit-bot: I haz the power, 2015-11-03 22:27:57]

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

[commit-bot: I haz the power, 2015-11-04 02:35:42]

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

[commit-bot: I haz the power, 2015-11-04 02:35:43]

Try jobs failed on following builders:
  win_chromium_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[nektarios, 2015-11-04 16:26:05]

The CQ bit was checked by nektar@chromium.org

[commit-bot: I haz the power, 2015-11-04 16:26:54]

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

[commit-bot: I haz the power, 2015-11-04 18:05:03]

Committed patchset #9 (id:160001)

[commit-bot: I haz the power, 2015-11-04 18:06:15]

Patchset 9 (id:??) landed as
https://crrev.com/ede890769a7bcc9dabb673f7332948946c76de99
Cr-Commit-Position: refs/heads/master@{#357849}