Fix behavior of HTMLInputElement.maxLength/minLength getter

Fix behavior of HTMLInputElement.maxLength/minLength getter

According to [1], the maxLength/minLength getter should "if the attribute
is absent, the default value must be returned instead, or −1 if there is
no default value". Since maxLength/minLength do not have a default value
indeed -1 should be used.

This fixes the imported w3c test:
http://w3c-test.org/html/semantics/forms/the-input-element/maxlength.html

Behavior matches Firefox.

[1] https://html.spec.whatwg.org/multipage/infrastructure.html#limited-to-only-non-negative-numbers

BUG=580301
Committed: https://crrev.com/380ad2fc4715faac624a03475fa5c3aa9e6cd7f1
Cr-Commit-Position: refs/heads/master@{#375497}

[rwlbuis, 2016-01-21 22:34:17]

Description was changed from

==========
maxlength WIP

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

to

==========
Fix behavior of HTMLInputElement.maxLength/minLength getter

According to [1], the maxLength/minLength getter should "if the attribute
is absent, the default value must be returned instead, or −1 if there is
no default value". Since maxLength/minLength do not have a default value
indeed -1 should be used.

This fixes the imported w3c test:
http://w3c-test.org/html/semantics/forms/the-input-element/maxlength.html

Behavior matches Firefox.

[1]
https://html.spec.whatwg.org/multipage/infrastructure.html#limited-to-only-no...
==========

[rwlbuis, 2016-01-21 22:34:45]

rob.buis@samsung.com changed reviewers:
+ tkent@chromium.org

[rwlbuis, 2016-01-21 22:34:46]

PTAL.

[tkent, 2016-01-22 05:03:30]

Please file new bug for this bug.

The code change LGTM.

https://codereview.chromium.org/1615003002/diff/20001/third_party/WebKit/Layo...
File third_party/WebKit/LayoutTests/fast/forms/text/input-maxlength.html
(right):

https://codereview.chromium.org/1615003002/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/forms/text/input-maxlength.html:49:
shouldBe("input.maxLength", "-1");
Let's remove line 49 and 50 because they are tested in web-platform-tests.

[rwlbuis, 2016-01-22 15:05:26]

Description was changed from

==========
Fix behavior of HTMLInputElement.maxLength/minLength getter

According to [1], the maxLength/minLength getter should "if the attribute
is absent, the default value must be returned instead, or −1 if there is
no default value". Since maxLength/minLength do not have a default value
indeed -1 should be used.

This fixes the imported w3c test:
http://w3c-test.org/html/semantics/forms/the-input-element/maxlength.html

Behavior matches Firefox.

[1]
https://html.spec.whatwg.org/multipage/infrastructure.html#limited-to-only-no...
==========

to

==========
Fix behavior of HTMLInputElement.maxLength/minLength getter

According to [1], the maxLength/minLength getter should "if the attribute
is absent, the default value must be returned instead, or −1 if there is
no default value". Since maxLength/minLength do not have a default value
indeed -1 should be used.

This fixes the imported w3c test:
http://w3c-test.org/html/semantics/forms/the-input-element/maxlength.html

Behavior matches Firefox.

BUG=580301

[1]
https://html.spec.whatwg.org/multipage/infrastructure.html#limited-to-only-no...
==========

[rwlbuis, 2016-01-22 15:05:27]

Description was changed from

==========
Fix behavior of HTMLInputElement.maxLength/minLength getter

According to [1], the maxLength/minLength getter should "if the attribute
is absent, the default value must be returned instead, or −1 if there is
no default value". Since maxLength/minLength do not have a default value
indeed -1 should be used.

This fixes the imported w3c test:
http://w3c-test.org/html/semantics/forms/the-input-element/maxlength.html

Behavior matches Firefox.

[1]
https://html.spec.whatwg.org/multipage/infrastructure.html#limited-to-only-no...
==========

to

==========
Fix behavior of HTMLInputElement.maxLength/minLength getter

According to [1], the maxLength/minLength getter should "if the attribute
is absent, the default value must be returned instead, or −1 if there is
no default value". Since maxLength/minLength do not have a default value
indeed -1 should be used.

This fixes the imported w3c test:
http://w3c-test.org/html/semantics/forms/the-input-element/maxlength.html

Behavior matches Firefox.

BUG=580301

[1]
https://html.spec.whatwg.org/multipage/infrastructure.html#limited-to-only-no...
==========

[rwlbuis, 2016-01-22 15:05:46]

The CQ bit was checked by rob.buis@samsung.com

[rwlbuis, 2016-01-22 15:05:46]

The patchset sent to the CQ was uploaded after l-g-t-m from tkent@chromium.org
Link to the patchset: https://codereview.chromium.org/1615003002/#ps40001
(title: "Patch for landing")

[commit-bot: I haz the power, 2016-01-22 15:06:04]

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

[rwlbuis, 2016-01-22 15:06:26]

Description was changed from

==========
Fix behavior of HTMLInputElement.maxLength/minLength getter

According to [1], the maxLength/minLength getter should "if the attribute
is absent, the default value must be returned instead, or −1 if there is
no default value". Since maxLength/minLength do not have a default value
indeed -1 should be used.

This fixes the imported w3c test:
http://w3c-test.org/html/semantics/forms/the-input-element/maxlength.html

Behavior matches Firefox.

BUG=580301

[1]
https://html.spec.whatwg.org/multipage/infrastructure.html#limited-to-only-no...
==========

to

==========
Fix behavior of HTMLInputElement.maxLength/minLength getter

According to [1], the maxLength/minLength getter should "if the attribute
is absent, the default value must be returned instead, or −1 if there is
no default value". Since maxLength/minLength do not have a default value
indeed -1 should be used.

This fixes the imported w3c test:
http://w3c-test.org/html/semantics/forms/the-input-element/maxlength.html

Behavior matches Firefox.

[1]
https://html.spec.whatwg.org/multipage/infrastructure.html#limited-to-only-no...

BUG=580301
==========

[rwlbuis, 2016-01-22 15:08:46]

On 2016/01/22 05:03:30, tkent wrote:
> Please file new bug for this bug.

Ouch, I made the bug but forgot to link it. Fixed.

>
https://codereview.chromium.org/1615003002/diff/20001/third_party/WebKit/Layo...
> File third_party/WebKit/LayoutTests/fast/forms/text/input-maxlength.html
> (right):
> 
>
https://codereview.chromium.org/1615003002/diff/20001/third_party/WebKit/Layo...
> third_party/WebKit/LayoutTests/fast/forms/text/input-maxlength.html:49:
> shouldBe("input.maxLength", "-1");
> Let's remove line 49 and 50 because they are tested in web-platform-tests.

Sounds good, done.

[commit-bot: I haz the power, 2016-01-22 15:54:34]

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

[commit-bot: I haz the power, 2016-01-22 15:54:35]

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

[rwlbuis, 2016-01-22 16:03:55]

The CQ bit was checked by rob.buis@samsung.com

[rwlbuis, 2016-01-22 16:03:55]

The patchset sent to the CQ was uploaded after l-g-t-m from tkent@chromium.org
Link to the patchset: https://codereview.chromium.org/1615003002/#ps60001
(title: "Adjust expected result as well")

[commit-bot: I haz the power, 2016-01-22 16:04:37]

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

[commit-bot: I haz the power, 2016-01-22 17:00:52]

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

[commit-bot: I haz the power, 2016-01-22 17:00:53]

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

[rwlbuis, 2016-01-22 17:51:00]

The CQ bit was checked by rob.buis@samsung.com

[commit-bot: I haz the power, 2016-01-22 17:51:12]

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

[commit-bot: I haz the power, 2016-01-22 18:39:50]

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

[commit-bot: I haz the power, 2016-01-22 18:39:51]

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

[rwlbuis, 2016-01-22 21:27:15]

On 2016/01/22 05:03:30, tkent wrote:
> Please file new bug for this bug.
> 
> The code change LGTM.
> 
>
https://codereview.chromium.org/1615003002/diff/20001/third_party/WebKit/Layo...
> File third_party/WebKit/LayoutTests/fast/forms/text/input-maxlength.html
> (right):
> 
>
https://codereview.chromium.org/1615003002/diff/20001/third_party/WebKit/Layo...
> third_party/WebKit/LayoutTests/fast/forms/text/input-maxlength.html:49:
> shouldBe("input.maxLength", "-1");
> Let's remove line 49 and 50 because they are tested in web-platform-tests.

Unfortunately the patch as-is has a problem when browser_tests are run. Some of
them use the maxLength constant(524288) but compare with the new returned value
(-1).

I think there are two solutions:
a) put the new code in maxlengthForBindings, only used for bindings, and keep
maxLength getter as before this CL.
b) start using -1 instead of 524288 for comparisons through use of
WebInputElement::defaultMaxLength. However that would also mean changing the
type here:
components/autofill/core/common/form_field_data.h:
size_t max_length;

I guess a is the easier/cleaner fix. Let me know, thanks.

[tkent, 2016-01-25 01:21:09]

On 2016/01/22 at 21:27:15, rob.buis wrote:
> On 2016/01/22 05:03:30, tkent wrote:
> > Please file new bug for this bug.
> > 
> > The code change LGTM.
> > 
> >
https://codereview.chromium.org/1615003002/diff/20001/third_party/WebKit/Layo...
> > File third_party/WebKit/LayoutTests/fast/forms/text/input-maxlength.html
> > (right):
> > 
> >
https://codereview.chromium.org/1615003002/diff/20001/third_party/WebKit/Layo...
> > third_party/WebKit/LayoutTests/fast/forms/text/input-maxlength.html:49:
> > shouldBe("input.maxLength", "-1");
> > Let's remove line 49 and 50 because they are tested in web-platform-tests.
> 
> Unfortunately the patch as-is has a problem when browser_tests are run. Some
of them use the maxLength constant(524288) but compare with the new returned
value (-1).
> 
> I think there are two solutions:
> a) put the new code in maxlengthForBindings, only used for bindings, and keep
maxLength getter as before this CL.
> b) start using -1 instead of 524288 for comparisons through use of
WebInputElement::defaultMaxLength. However that would also mean changing the
type here:
> components/autofill/core/common/form_field_data.h:
> size_t max_length;
> 
> I guess a is the easier/cleaner fix. Let me know, thanks.

B looks the right approach.  I looked the tests, and they don't need the
implicit maximum length.

[rwlbuis, 2016-01-26 22:40:28]

On 2016/01/25 01:21:09, tkent wrote:
> On 2016/01/22 at 21:27:15, rob.buis wrote:
> > I think there are two solutions:
> > a) put the new code in maxlengthForBindings, only used for bindings, and
keep
> maxLength getter as before this CL.
> > b) start using -1 instead of 524288 for comparisons through use of
> WebInputElement::defaultMaxLength. However that would also mean changing the
> type here:
> > components/autofill/core/common/form_field_data.h:
> > size_t max_length;
> > 
> > I guess a is the easier/cleaner fix. Let me know, thanks.
> 
> B looks the right approach.  I looked the tests, and they don't need the
> implicit maximum length.

@tkent it may seem now B is getting a bit too complicated. Consider
components/autofill/content/renderer/form_autofill_util.cc:881:

 881       // If the maxlength attribute contains a negative value, maxLength()
 882       // returns the default maxlength value.
 883       TruncateString(&value, input_element->maxLength());

The comment no longer applies. Furthermore, I am not sure how TruncateString
could keep having its current behavior, except for
duplicating the internal HTMLInputElement::maximumLength constant, or choosing
something close to that. Not truncating at all for
negative value sounds dangerous as well. Let me know if you have an idea here
(this looks like the final problem of plan B), but
otherwise plan A seems to save us from a lot of possible pitfalls, maybe even
regressions.

[tkent, 2016-01-28 00:14:07]

On 2016/01/26 at 22:40:28, rob.buis wrote:
> @tkent it may seem now B is getting a bit too complicated. Consider
components/autofill/content/renderer/form_autofill_util.cc:881:
> 
>  881       // If the maxlength attribute contains a negative value,
maxLength()
>  882       // returns the default maxlength value.
>  883       TruncateString(&value, input_element->maxLength());
> 
> The comment no longer applies. Furthermore, I am not sure how TruncateString
could keep having its current behavior, except for
> duplicating the internal HTMLInputElement::maximumLength constant, or choosing
something close to that. Not truncating at all for
> negative value sounds dangerous as well. Let me know if you have an idea here
(this looks like the final problem of plan B), but
> otherwise plan A seems to save us from a lot of possible pitfalls, maybe even
regressions.

I guess the intention of the code is:
  if maxlength attribute is specified, truncate autofill value.
so I think we should do nothing if maxlength attribute is not specified.  Also,
an autofill values are not so large and truncation by 524k doesn't make sense
practically.
The code would be:

    if (input_element->maxLength() >= 0)
      TruncateString(&value, input_element->maxLength());

[rwlbuis, 2016-01-28 03:38:02]

Patchset #7 (id:120001) has been deleted

[rwlbuis, 2016-02-08 19:16:44]

On 2016/01/28 00:14:07, tkent wrote:
> I guess the intention of the code is:
>   if maxlength attribute is specified, truncate autofill value.
> so I think we should do nothing if maxlength attribute is not specified. 
Also,
> an autofill values are not so large and truncation by 524k doesn't make sense
> practically.
> The code would be:
> 
>     if (input_element->maxLength() >= 0)
>       TruncateString(&value, input_element->maxLength());

Finally got it to show up green :) Do you think we should add reviewers for the
chromium part? If so, can you think of any?

[tkent, 2016-02-08 23:48:21]

> Do you think we should add reviewers for the chromium part? If so, can you
think of any?

Of course.  I'm not an owner of components/autofill/.
Please choose someone from components/autofill/OWNERS.

https://codereview.chromium.org/1615003002/diff/240001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/html/HTMLInputElement.cpp (right):

https://codereview.chromium.org/1615003002/diff/240001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/html/HTMLInputElement.cpp:1368: if
(!hasAttribute(maxlengthAttr) || m_maxLength == maximumLength)
input.maxLength for <input maxlength="524288"> returns -1.  It's not right.

https://codereview.chromium.org/1615003002/diff/240001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/html/HTMLInputElement.cpp:1375: if
(!hasAttribute(minlengthAttr))
We should have a test for this change.

I think we can change the initial value of m_minLength to -1.

[rwlbuis, 2016-02-09 16:17:05]

Patchset #13 (id:260001) has been deleted

[rwlbuis, 2016-02-11 21:58:04]

On 2016/02/08 23:48:21, tkent wrote:
> > Do you think we should add reviewers for the chromium part? If so, can you
> think of any?
> 
> Of course.  I'm not an owner of components/autofill/.
> Please choose someone from components/autofill/OWNERS.

Thanks.

>
https://codereview.chromium.org/1615003002/diff/240001/third_party/WebKit/Sou...
> File third_party/WebKit/Source/core/html/HTMLInputElement.cpp (right):
> 
>
https://codereview.chromium.org/1615003002/diff/240001/third_party/WebKit/Sou...
> third_party/WebKit/Source/core/html/HTMLInputElement.cpp:1368: if
> (!hasAttribute(maxlengthAttr) || m_maxLength == maximumLength)
> input.maxLength for <input maxlength="524288"> returns -1.  It's not right.

You are right, fixed now.

>
https://codereview.chromium.org/1615003002/diff/240001/third_party/WebKit/Sou...
> third_party/WebKit/Source/core/html/HTMLInputElement.cpp:1375: if
> (!hasAttribute(minlengthAttr))
> We should have a test for this change.

Added in Patch Set 16. Sadly Firefox does not seem to support this attribute :(

> I think we can change the initial value of m_minLength to -1.

Done, good idea.

I also made Patch Set #17, which makes the chromium side work as before and is
less intrusive. I personally like it better, anyway now we have something to
choose from. Let me know what you think?

[tkent, 2016-02-12 01:55:10]

> I also made Patch Set #17, which makes the chromium side work as before and is
less intrusive. I personally like it better, anyway now we have something to
choose from. Let me know what you think?

It's acceptable.  However we should add a comment that
WebInputElement::maxLength is different from 'maxLength' IDL attribute, in
WebInputElement.h.

https://codereview.chromium.org/1615003002/diff/360001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/html/HTMLInputElement.cpp (right):

https://codereview.chromium.org/1615003002/diff/360001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/html/HTMLInputElement.cpp:1698: if
(!parseHTMLInteger(value, minLength) || minLength < 0)
We need to reset m_minLength to -1 if we had a parse error.

[rwlbuis, 2016-02-12 19:35:30]

On 2016/02/12 01:55:10, tkent wrote:
> > I also made Patch Set #17, which makes the chromium side work as before and
is
> less intrusive. I personally like it better, anyway now we have something to
> choose from. Let me know what you think?
> 
> It's acceptable.  However we should add a comment that
> WebInputElement::maxLength is different from 'maxLength' IDL attribute, in
> WebInputElement.h.

Done.

>
https://codereview.chromium.org/1615003002/diff/360001/third_party/WebKit/Sou...
> File third_party/WebKit/Source/core/html/HTMLInputElement.cpp (right):
> 
>
https://codereview.chromium.org/1615003002/diff/360001/third_party/WebKit/Sou...
> third_party/WebKit/Source/core/html/HTMLInputElement.cpp:1698: if
> (!parseHTMLInteger(value, minLength) || minLength < 0)
> We need to reset m_minLength to -1 if we had a parse error.

Done.

PTAL. Sorry this has taken so many iterations!

[tkent, 2016-02-14 23:28:12]

https://codereview.chromium.org/1615003002/diff/380001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/html/HTMLInputElement.cpp (right):

https://codereview.chromium.org/1615003002/diff/380001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/html/HTMLInputElement.cpp:1685: maxLength =
maximumLength;
Similar to parseMinLengthAttribute(), we need to reset |m_maxLength| to |-1| if
maxlegth content attribute value is not a number.

I think web-platform-tests/html/semantics/forms/the-input-element/maxlength.html
is broken.  type= attributes in the test should be maxlegnth=.

[rwlbuis, 2016-02-15 21:15:12]

PTAL.

https://codereview.chromium.org/1615003002/diff/380001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/html/HTMLInputElement.cpp (right):

https://codereview.chromium.org/1615003002/diff/380001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/html/HTMLInputElement.cpp:1685: maxLength =
maximumLength;
On 2016/02/14 23:28:11, tkent wrote:
> Similar to parseMinLengthAttribute(), we need to reset |m_maxLength| to |-1|
if
> maxlegth content attribute value is not a number.

Done.

> I think
web-platform-tests/html/semantics/forms/the-input-element/maxlength.html
> is broken.  type= attributes in the test should be maxlegnth=.

I noticed the same thing. Do you want this fixed as part of this patch? I
suppose the best thing would be if it gets fixed at the source though...

[tkent, 2016-02-15 22:54:06]

The CQ bit was checked by tkent@chromium.org

[tkent, 2016-02-15 22:54:07]

lgtm

https://codereview.chromium.org/1615003002/diff/380001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/html/HTMLInputElement.cpp (right):

https://codereview.chromium.org/1615003002/diff/380001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/html/HTMLInputElement.cpp:1685: maxLength =
maximumLength;
On 2016/02/15 at 21:15:10, rwlbuis wrote:
> On 2016/02/14 23:28:11, tkent wrote:
> > Similar to parseMinLengthAttribute(), we need to reset |m_maxLength| to |-1|
if
> > maxlegth content attribute value is not a number.
> 
> Done.
> 
> > I think
web-platform-tests/html/semantics/forms/the-input-element/maxlength.html
> > is broken.  type= attributes in the test should be maxlegnth=.
> 
> I noticed the same thing. Do you want this fixed as part of this patch? I
suppose the best thing would be if it gets fixed at the source though...

We can't fix the imported test in Chromium repository.

[commit-bot: I haz the power, 2016-02-15 22:54:24]

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

[commit-bot: I haz the power, 2016-02-16 00:04:51]

Description was changed from

==========
Fix behavior of HTMLInputElement.maxLength/minLength getter

According to [1], the maxLength/minLength getter should "if the attribute
is absent, the default value must be returned instead, or −1 if there is
no default value". Since maxLength/minLength do not have a default value
indeed -1 should be used.

This fixes the imported w3c test:
http://w3c-test.org/html/semantics/forms/the-input-element/maxlength.html

Behavior matches Firefox.

[1]
https://html.spec.whatwg.org/multipage/infrastructure.html#limited-to-only-no...

BUG=580301
==========

to

==========
Fix behavior of HTMLInputElement.maxLength/minLength getter

According to [1], the maxLength/minLength getter should "if the attribute
is absent, the default value must be returned instead, or −1 if there is
no default value". Since maxLength/minLength do not have a default value
indeed -1 should be used.

This fixes the imported w3c test:
http://w3c-test.org/html/semantics/forms/the-input-element/maxlength.html

Behavior matches Firefox.

[1]
https://html.spec.whatwg.org/multipage/infrastructure.html#limited-to-only-no...

BUG=580301
==========

[commit-bot: I haz the power, 2016-02-16 00:04:52]

Committed patchset #19 (id:400001)

[commit-bot: I haz the power, 2016-02-16 22:50:58]

Description was changed from

==========
Fix behavior of HTMLInputElement.maxLength/minLength getter

According to [1], the maxLength/minLength getter should "if the attribute
is absent, the default value must be returned instead, or −1 if there is
no default value". Since maxLength/minLength do not have a default value
indeed -1 should be used.

This fixes the imported w3c test:
http://w3c-test.org/html/semantics/forms/the-input-element/maxlength.html

Behavior matches Firefox.

[1]
https://html.spec.whatwg.org/multipage/infrastructure.html#limited-to-only-no...

BUG=580301
==========

to

==========
Fix behavior of HTMLInputElement.maxLength/minLength getter

According to [1], the maxLength/minLength getter should "if the attribute
is absent, the default value must be returned instead, or −1 if there is
no default value". Since maxLength/minLength do not have a default value
indeed -1 should be used.

This fixes the imported w3c test:
http://w3c-test.org/html/semantics/forms/the-input-element/maxlength.html

Behavior matches Firefox.

[1]
https://html.spec.whatwg.org/multipage/infrastructure.html#limited-to-only-no...

BUG=580301

Committed: https://crrev.com/380ad2fc4715faac624a03475fa5c3aa9e6cd7f1
Cr-Commit-Position: refs/heads/master@{#375497}
==========

[commit-bot: I haz the power, 2016-02-16 22:50:59]

Patchset 19 (id:??) landed as
https://crrev.com/380ad2fc4715faac624a03475fa5c3aa9e6cd7f1
Cr-Commit-Position: refs/heads/master@{#375497}