Finish all string attributes for Accessibility Object Model Phase 1.

Finish all string attributes for Accessibility Object Model Phase 1.

This is a pretty mechanical change. Next will come attributes of different
types.

BUG=680345
Review-Url: https://codereview.chromium.org/2788523002
Cr-Commit-Position: refs/heads/master@{#461820}
Committed: https://chromium.googlesource.com/chromium/src/+/e6b9e4ff7e481982e07848a0e2d20d9caf0f25c2

[dmazzoni, 2017-03-30 04:16:26]

dmazzoni@chromium.org changed reviewers:
+ aboxhall@chromium.org, esprehn@chromium.org

[dmazzoni, 2017-03-30 04:19:07]

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

[commit-bot: I haz the power, 2017-03-30 04:19:27]

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

[esprehn, 2017-03-30 04:38:34]

This patch is fine but there's no tests. Every one of these properties needs
tests. :)

[commit-bot: I haz the power, 2017-03-30 05:48:19]

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

[commit-bot: I haz the power, 2017-03-30 05:48:20]

Dry run: Try jobs failed on following builders:
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)

[dmazzoni, 2017-03-30 08:04:22]

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

[commit-bot: I haz the power, 2017-03-30 08:04:37]

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

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

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

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

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[dmazzoni, 2017-03-30 15:02:01]

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

[commit-bot: I haz the power, 2017-03-30 15:02:58]

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

[commit-bot: I haz the power, 2017-03-30 16:53:19]

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

[commit-bot: I haz the power, 2017-03-30 16:53:20]

Dry run: Try jobs failed on following builders:
  win_chromium_x64_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[dmazzoni, 2017-03-30 18:06:32]

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

[commit-bot: I haz the power, 2017-03-30 18:07:31]

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

[dmazzoni, 2017-03-30 19:45:31]

Covered by layout tests now, PTAL!

A subsequent change (https://codereview.chromium.org/2787843003/)
sets us up to write tests in content/ too.

[commit-bot: I haz the power, 2017-03-30 20:05:05]

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

[commit-bot: I haz the power, 2017-03-30 20:05:06]

Dry run: This issue passed the CQ dry run.

[dmazzoni, 2017-03-30 23:55:08]

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

[commit-bot: I haz the power, 2017-03-30 23:56:25]

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

[dmazzoni, 2017-03-30 23:58:15]

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

[commit-bot: I haz the power, 2017-03-30 23:58:38]

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

[commit-bot: I haz the power, 2017-03-31 00:10:29]

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

[commit-bot: I haz the power, 2017-03-31 00:10:30]

Dry run: Try jobs failed on following builders:
  linux_chromium_tsan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[aboxhall, 2017-03-31 00:23:39]

https://codereview.chromium.org/2788523002/diff/80001/content/shell/test_runn...
File content/shell/test_runner/web_ax_object_proxy.cc (right):

https://codereview.chromium.org/2788523002/diff/80001/content/shell/test_runn...
content/shell/test_runner/web_ax_object_proxy.cc:1083: std::string
WebAXObjectProxy::Autocomplete() {
Why some token values using enums but not this others?

https://codereview.chromium.org/2788523002/diff/80001/third_party/WebKit/Layo...
File third_party/WebKit/LayoutTests/accessibility/aom-string-properties.html
(right):

https://codereview.chromium.org/2788523002/diff/80001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/accessibility/aom-string-properties.html:25:
assert_equals(axNode.autocomplete, "");
Is this equivalent to "none"? Per
https://www.w3.org/TR/wai-aria/states_and_properties#aria-autocomplete

https://codereview.chromium.org/2788523002/diff/80001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/accessibility/aom-string-properties.html:38:
node.accessibleNode.checked = "true";
Do we want to enable using boolean true/false as a shorthand for "true"/"false"?
I think that would be intuitive.

https://codereview.chromium.org/2788523002/diff/80001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/accessibility/aom-string-properties.html:126:
assert_equals(axNode.name, "Placeholder");
Why not check axNode.placeholder directly here (as well)?

https://codereview.chromium.org/2788523002/diff/80001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/accessibility/aom-string-properties.html:149:
node.accessibleNode.role = "combobox";
Test role fallback as well, i.e. node.accessibleNode.role = "banana combobox"?

https://codereview.chromium.org/2788523002/diff/80001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/accessibility/aom-string-properties.html:172:
assert_equals(axNode.sort, "");
Similarly, should this be explicitly "none"? Maybe not necessary now since this
is internal only, but for phase 5 we'll need to map this.

https://codereview.chromium.org/2788523002/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/accessibility/AXNodeObject.cpp (right):

https://codereview.chromium.org/2788523002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/accessibility/AXNodeObject.cpp:1644: if
(!attributeValue.isEmpty())
This doesn't seem right. This is a token value; if it's not a valid token then
it should be the default value (false in this case), right?

[dmazzoni, 2017-03-31 04:34:58]

https://codereview.chromium.org/2788523002/diff/80001/content/shell/test_runn...
File content/shell/test_runner/web_ax_object_proxy.cc (right):

https://codereview.chromium.org/2788523002/diff/80001/content/shell/test_runn...
content/shell/test_runner/web_ax_object_proxy.cc:1083: std::string
WebAXObjectProxy::Autocomplete() {
On 2017/03/31 00:23:38, aboxhall wrote:
> Why some token values using enums but not this others?

Just historical - the new ones we've switched to returning enums
from WebAXObject.h but this one hasn't been updated yet

https://codereview.chromium.org/2788523002/diff/80001/third_party/WebKit/Layo...
File third_party/WebKit/LayoutTests/accessibility/aom-string-properties.html
(right):

https://codereview.chromium.org/2788523002/diff/80001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/accessibility/aom-string-properties.html:25:
assert_equals(axNode.autocomplete, "");
On 2017/03/31 00:23:38, aboxhall wrote:
> Is this equivalent to "none"? Per
> https://www.w3.org/TR/wai-aria/states_and_properties#aria-autocomplete

Yes, if we had an enum this would be the same as "none" - I think what's
most important for now is that this is consistent with aria-autocomplete

https://codereview.chromium.org/2788523002/diff/80001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/accessibility/aom-string-properties.html:38:
node.accessibleNode.checked = "true";
On 2017/03/31 00:23:38, aboxhall wrote:
> Do we want to enable using boolean true/false as a shorthand for
"true"/"false"?
> I think that would be intuitive.

Hmmm, not sure I like that since this is actually a tristate. Setting it to
either true or "mixed" seems weird to me.

https://codereview.chromium.org/2788523002/diff/80001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/accessibility/aom-string-properties.html:126:
assert_equals(axNode.name, "Placeholder");
On 2017/03/31 00:23:39, aboxhall wrote:
> Why not check axNode.placeholder directly here (as well)?

We actually don't return anything from "placeholder" when the placeholder was
returned as the name or description. That was one of the nice side effects of
the new name calc code. We never duplicate stuff anymore.

However, I can assert that nameFrom=="placeholder". Done.

https://codereview.chromium.org/2788523002/diff/80001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/accessibility/aom-string-properties.html:149:
node.accessibleNode.role = "combobox";
On 2017/03/31 00:23:38, aboxhall wrote:
> Test role fallback as well, i.e. node.accessibleNode.role = "banana combobox"?

Done.

https://codereview.chromium.org/2788523002/diff/80001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/accessibility/aom-string-properties.html:172:
assert_equals(axNode.sort, "");
On 2017/03/31 00:23:39, aboxhall wrote:
> Similarly, should this be explicitly "none"? Maybe not necessary now since
this
> is internal only, but for phase 5 we'll need to map this.

Yeah, this is just supposed to match what we return now. The LayoutTest
interface is a real
hodgepodge and isn't really supposed to be consistent with anything. Again, what
I care about
the most for now is if it matches what we get with aria.

Also see the next change where I'm working on testing these in content/ - I
think that's
almost better because what matters the most is what we get in AXNodeData.

https://codereview.chromium.org/2788523002/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/accessibility/AXNodeObject.cpp (right):

https://codereview.chromium.org/2788523002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/accessibility/AXNodeObject.cpp:1644: if
(!attributeValue.isEmpty())
On 2017/03/31 00:23:39, aboxhall wrote:
> This doesn't seem right. This is a token value; if it's not a valid token then
> it should be the default value (false in this case), right?

The spec says: "Any value not recognized in the list of allowed values must be
treated by user agents as if the value true had been provided."

Perhaps for future expansion, to allow future truthy values?

[dmazzoni, 2017-03-31 04:35:28]

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

[commit-bot: I haz the power, 2017-03-31 04:35:54]

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

[aboxhall, 2017-03-31 04:41:54]

https://codereview.chromium.org/2788523002/diff/80001/third_party/WebKit/Layo...
File third_party/WebKit/LayoutTests/accessibility/aom-string-properties.html
(right):

https://codereview.chromium.org/2788523002/diff/80001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/accessibility/aom-string-properties.html:38:
node.accessibleNode.checked = "true";
On 2017/03/31 04:34:58, dmazzoni wrote:
> On 2017/03/31 00:23:38, aboxhall wrote:
> > Do we want to enable using boolean true/false as a shorthand for
> "true"/"false"?
> > I think that would be intuitive.
> 
> Hmmm, not sure I like that since this is actually a tristate. Setting it to
> either true or "mixed" seems weird to me.

Yeah, I realise it's a tristate, but "mixed" is so seldom used that I think it'd
be a net win to allow setting the "true"/"false" values via boolean values.

If we don't do this, I foresee much developer moaning about it :)

[dmazzoni, 2017-03-31 05:30:03]

On 2017/03/31 04:41:54, aboxhall wrote:
>
https://codereview.chromium.org/2788523002/diff/80001/third_party/WebKit/Layo...
> File third_party/WebKit/LayoutTests/accessibility/aom-string-properties.html
> (right):
> 
>
https://codereview.chromium.org/2788523002/diff/80001/third_party/WebKit/Layo...
> third_party/WebKit/LayoutTests/accessibility/aom-string-properties.html:38:
> node.accessibleNode.checked = "true";
> On 2017/03/31 04:34:58, dmazzoni wrote:
> > On 2017/03/31 00:23:38, aboxhall wrote:
> > > Do we want to enable using boolean true/false as a shorthand for
> > "true"/"false"?
> > > I think that would be intuitive.
> > 
> > Hmmm, not sure I like that since this is actually a tristate. Setting it to
> > either true or "mixed" seems weird to me.
> 
> Yeah, I realise it's a tristate, but "mixed" is so seldom used that I think
it'd
> be a net win to allow setting the "true"/"false" values via boolean values.
> 
> If we don't do this, I foresee much developer moaning about it :)

Are you suggesting I write element.accessibleNode.checked = true? That would
work, it would convert to the string "true".

But if you're suggesting the actual type should be boolean, then I don't
understand how to handle mixed...what would the IDL signature be?

[aboxhall, 2017-03-31 05:31:29]

On 2017/03/31 05:30:03, dmazzoni wrote:
> On 2017/03/31 04:41:54, aboxhall wrote:
> >
>
https://codereview.chromium.org/2788523002/diff/80001/third_party/WebKit/Layo...
> > File third_party/WebKit/LayoutTests/accessibility/aom-string-properties.html
> > (right):
> > 
> >
>
https://codereview.chromium.org/2788523002/diff/80001/third_party/WebKit/Layo...
> > third_party/WebKit/LayoutTests/accessibility/aom-string-properties.html:38:
> > node.accessibleNode.checked = "true";
> > On 2017/03/31 04:34:58, dmazzoni wrote:
> > > On 2017/03/31 00:23:38, aboxhall wrote:
> > > > Do we want to enable using boolean true/false as a shorthand for
> > > "true"/"false"?
> > > > I think that would be intuitive.
> > > 
> > > Hmmm, not sure I like that since this is actually a tristate. Setting it
to
> > > either true or "mixed" seems weird to me.
> > 
> > Yeah, I realise it's a tristate, but "mixed" is so seldom used that I think
> it'd
> > be a net win to allow setting the "true"/"false" values via boolean values.
> > 
> > If we don't do this, I foresee much developer moaning about it :)
> 
> Are you suggesting I write element.accessibleNode.checked = true? That would
> work, it would convert to the string "true".
> 
> But if you're suggesting the actual type should be boolean, then I don't
> understand how to handle mixed...what would the IDL signature be?

No, definitely not suggesting the type should be boolean: "Do we want to enable
using boolean true/false as a shorthand for "true"/"false"?"

Agreed, it should "just work" with javascript types.

[commit-bot: I haz the power, 2017-03-31 06:24:35]

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

[commit-bot: I haz the power, 2017-03-31 06:24:36]

Dry run: This issue passed the CQ dry run.

[dmazzoni, 2017-03-31 15:11:54]

On 2017/03/31 05:31:29, aboxhall wrote:
> On 2017/03/31 05:30:03, dmazzoni wrote:
> > On 2017/03/31 04:41:54, aboxhall wrote:
> > >
> >
>
https://codereview.chromium.org/2788523002/diff/80001/third_party/WebKit/Layo...
> > > File
third_party/WebKit/LayoutTests/accessibility/aom-string-properties.html
> > > (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/2788523002/diff/80001/third_party/WebKit/Layo...
> > >
third_party/WebKit/LayoutTests/accessibility/aom-string-properties.html:38:
> > > node.accessibleNode.checked = "true";
> > > On 2017/03/31 04:34:58, dmazzoni wrote:
> > > > On 2017/03/31 00:23:38, aboxhall wrote:
> > > > > Do we want to enable using boolean true/false as a shorthand for
> > > > "true"/"false"?
> > > > > I think that would be intuitive.
> > > > 
> > > > Hmmm, not sure I like that since this is actually a tristate. Setting it
> to
> > > > either true or "mixed" seems weird to me.
> > > 
> > > Yeah, I realise it's a tristate, but "mixed" is so seldom used that I
think
> > it'd
> > > be a net win to allow setting the "true"/"false" values via boolean
values.
> > > 
> > > If we don't do this, I foresee much developer moaning about it :)
> > 
> > Are you suggesting I write element.accessibleNode.checked = true? That would
> > work, it would convert to the string "true".
> > 
> > But if you're suggesting the actual type should be boolean, then I don't
> > understand how to handle mixed...what would the IDL signature be?
> 
> No, definitely not suggesting the type should be boolean: "Do we want to
enable
> using boolean true/false as a shorthand for "true"/"false"?"
> 
> Agreed, it should "just work" with javascript types.

OK, I added some additional asserts to the test to show that it works fine to
do that. I didn't have to make any changes to the code, it just worked.

[dmazzoni, 2017-03-31 15:12:26]

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

[commit-bot: I haz the power, 2017-03-31 15:12:45]

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

[commit-bot: I haz the power, 2017-03-31 17:06:40]

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

[commit-bot: I haz the power, 2017-03-31 17:06:41]

Dry run: Try jobs failed on following builders:
  linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[aboxhall, 2017-04-03 23:20:24]

lgtm

https://codereview.chromium.org/2788523002/diff/80001/third_party/WebKit/Layo...
File third_party/WebKit/LayoutTests/accessibility/aom-string-properties.html
(right):

https://codereview.chromium.org/2788523002/diff/80001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/accessibility/aom-string-properties.html:126:
assert_equals(axNode.name, "Placeholder");
On 2017/03/31 04:34:57, dmazzoni wrote:
> On 2017/03/31 00:23:39, aboxhall wrote:
> > Why not check axNode.placeholder directly here (as well)?
> 
> We actually don't return anything from "placeholder" when the placeholder was
> returned as the name or description. That was one of the nice side effects of
> the new name calc code. We never duplicate stuff anymore.
> 
> However, I can assert that nameFrom=="placeholder". Done.

Oh nice :)

[esprehn, 2017-04-04 06:22:30]

lgtm, I think you want to refactor that code into a private method so you can
avoid the same incantation repeatedly. I also noticed some other things that
need fixing but you can do that in a future patch.

https://codereview.chromium.org/2788523002/diff/140001/content/shell/test_run...
File content/shell/test_runner/web_ax_object_proxy.cc (right):

https://codereview.chromium.org/2788523002/diff/140001/content/shell/test_run...
content/shell/test_runner/web_ax_object_proxy.cc:1099: case
blink::WebAXAriaCurrentStateLocation:
It'd be really nice if you'd onion soup all this stuff and remove all the
plumbing

https://codereview.chromium.org/2788523002/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/dom/AccessibleNode.cpp (right):

https://codereview.chromium.org/2788523002/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/AccessibleNode.cpp:63: default:
If you remove the default it'll fail to compile if you forgot a case, we prefer
that and instead put the NOTREACHED() and return nullAtom below it outside the
switch

https://codereview.chromium.org/2788523002/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/AccessibleNode.cpp:76: if (AXObjectCache*
cache = m_element->document().axObjectCache())
You do this same thing everywhere, maybe you want a shared private method?

notifyAttributeChanged(HTMLNames::aria_autocompleteAttr)

we also sometimes do using namespace HTMLNames at the top of the .cpp file so
you can avoid writing HTMLNames:: repeatedly

https://codereview.chromium.org/2788523002/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/modules/accessibility/AXNodeObject.cpp (right):

https://codereview.chromium.org/2788523002/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/modules/accessibility/AXNodeObject.cpp:1635: if
(equalIgnoringCase(attributeValue, "false"))
fwiw I think all of these should use ASCII case instead

[dmazzoni, 2017-04-04 18:48:13]

The CQ bit was checked by dmazzoni@chromium.org

[dmazzoni, 2017-04-04 18:48:13]

The patchset sent to the CQ was uploaded after l-g-t-m from
esprehn@chromium.org, aboxhall@chromium.org
Link to the patchset: https://codereview.chromium.org/2788523002/#ps160001
(title: "notifyAttributeChanged")

[commit-bot: I haz the power, 2017-04-04 18:49:36]

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

[dmazzoni, 2017-04-04 18:59:17]

https://codereview.chromium.org/2788523002/diff/140001/content/shell/test_run...
File content/shell/test_runner/web_ax_object_proxy.cc (right):

https://codereview.chromium.org/2788523002/diff/140001/content/shell/test_run...
content/shell/test_runner/web_ax_object_proxy.cc:1099: case
blink::WebAXAriaCurrentStateLocation:
On 2017/04/04 06:22:30, esprehn wrote:
> It'd be really nice if you'd onion soup all this stuff and remove all the
> plumbing

Sounds great. I threw a quick meeting on your calendar to
go over the high-level design, I'll write a doc from that.

https://codereview.chromium.org/2788523002/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/dom/AccessibleNode.cpp (right):

https://codereview.chromium.org/2788523002/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/AccessibleNode.cpp:63: default:
On 2017/04/04 06:22:30, esprehn wrote:
> If you remove the default it'll fail to compile if you forgot a case, we
prefer
> that and instead put the NOTREACHED() and return nullAtom below it outside the
> switch

Done.

https://codereview.chromium.org/2788523002/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/AccessibleNode.cpp:76: if (AXObjectCache*
cache = m_element->document().axObjectCache())
On 2017/04/04 06:22:30, esprehn wrote:
> You do this same thing everywhere, maybe you want a shared private method?
>
> notifyAttributeChanged(HTMLNames::aria_autocompleteAttr)

Done.

Actually, glad I looked at this. We should be calling
Document.existingAXObjectCache() here.

> we also sometimes do using namespace HTMLNames at the top of the .cpp file so
> you can avoid writing HTMLNames:: repeatedly

Done.

https://codereview.chromium.org/2788523002/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/modules/accessibility/AXNodeObject.cpp (right):

https://codereview.chromium.org/2788523002/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/modules/accessibility/AXNodeObject.cpp:1635: if
(equalIgnoringCase(attributeValue, "false"))
On 2017/04/04 06:22:30, esprehn wrote:
> fwiw I think all of these should use ASCII case instead

I can change this throughout modules/accessibility, I sent
you an email to clarify exactly what you want here.

[commit-bot: I haz the power, 2017-04-04 20:38:12]

CQ is committing da patch.

Bot data: {"patchset_id": 160001, "attempt_start_ts": 1491331693106080,
"parent_rev": "9c32cf8a6e0185d51a16fbe3904e77043758e7ce", "commit_rev":
"e6b9e4ff7e481982e07848a0e2d20d9caf0f25c2"}

[commit-bot: I haz the power, 2017-04-04 20:39:06]

Description was changed from

==========
Finish all string attributes for Accessibility Object Model Phase 1.

This is a pretty mechanical change. Next will come attributes of different
types.

BUG=680345
==========

to

==========
Finish all string attributes for Accessibility Object Model Phase 1.

This is a pretty mechanical change. Next will come attributes of different
types.

BUG=680345

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

[commit-bot: I haz the power, 2017-04-04 20:39:08]

Committed patchset #9 (id:160001) as
https://chromium.googlesource.com/chromium/src/+/e6b9e4ff7e481982e07848a0e2d2...