Skip to content

V
V8
Switch branch/tag
  1. 24 Sep, 2020 3 commits
  3. 22 Sep, 2020 1 commit
  5. 08 Sep, 2020 1 commit
  7. 18 Aug, 2020 2 commits
  9. 03 Aug, 2020 1 commit
  11. 24 Jun, 2020 1 commit
  13. 22 Jun, 2020 1 commit
  15. 09 Jun, 2020 1 commit
  17. 28 Apr, 2020 2 commits
  19. 24 Apr, 2020 3 commits
    • Shu-yu Guo's avatar
      Allow Proxy constructor to take revoked Proxies as targets and handlers · ce43feb5
      Shu-yu Guo authored 
      Normative spec change: https://github.com/tc39/ecma262/pull/1814

Bug: v8:10382
Change-Id: Ib17ece9f0c8f75702c828b5336e75cab5d173e5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2163876
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67376}
      ce43feb5
    • Timothy Gu's avatar
      Reland "[builtins] Clean up the use of class_name / ES5 [[Class]]" · 1aa51b49
      Timothy Gu authored 
      This is a reland of 29c1eab9

Original change's description:
> [builtins] Clean up the use of class_name / ES5 [[Class]]
>
> Before ES2015, the ES spec had a [[Class]] internal slot for all
> objects, which Object.prototype.toString() would use to figure the
> returned string. Post-ES2015, the [[Class]] slot was removed in spec for
> all objects, with the @@toStringTag well-known symbol the proper way to
> change Object.prototype.toString() output.
>
> At the time, spec-identical handling without the use of [[Class]] was
> implemented in V8 for all objects other than API objects, where issues
> with the Web IDL spec [1] prevented Blink, and hence V8, to totally
> migrate to @@toStringTag. However, since 2016 [2] Blink has been setting
> @@toStringTag on API class prototypes to manage the
> Object.prototype.toString() output, so the legacy [[Class]] handling in
> V8 has not been necessary for the past couple of years.
>
> This CL removes the remaining legacy [[Class]] handling in
> Object.prototype.toString(), JSReceiver::class_name(), and
> GetConstructorName(). However, it does not remove the class_name field
> in FunctionTemplateInfo, as it is still used for the `name` property of
> created functions.
>
> This CL also cleans up other places in the codebase that still reference
> [[Class]].
>
> This change should have minimal impact on web-compatibility. For the
> change to be observable, a script must do one of the following:
>
> 1. delete APIConstructor.prototype[Symbol.toStringTag];
> 2. Object.setPrototypeOf(apiObject, somethingElse);
>
> Before this CL, these changes will not change the apiObject.toString()
> output. But after this CL, they will make apiObject.toString() show
> "[object Object]" (in the first case) or the @@toStringTag of the other
> prototype (in the latter case).
>
> However, both are deemed unlikely. @@toStringTag is not well-known
> feature of JavaScript, nor does it get tampered much on API
> constructors. In the second case, setting the prototype of an API object
> would effectly render the object useless, as all its methods (including
> property getters/setters) would no longer be accessible.
>
> Currently, @@toStringTag-based API object branding is not yet
> implemented by other browsers. This V8 bug in particular has been an
> impediment to standardizing toString behavior. Fixing this bug will
> unblock [3] and lead to a better Web IDL spec, and better toString()
> compatibility for all.
>
> [1]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244
> [2]: https://crrev.com/909c0d7d5a53c8526ded351683c65ea7d17531d4
> [3]: https://github.com/heycam/webidl/pull/357
>
> Bug: chromium:793406
> Cq-Include-Trybots: luci.chromium.try:linux-rel
> Change-Id: Iceded24e37afa2646ec385d5018909f55b177f93
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2146996
> Commit-Queue: Timothy Gu <timothygu@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67327}

Bug: chromium:793406
Change-Id: Ia5d97bd4e1c44cadc6f18a17ffc9d06b038cf8f1
Cq-Include-Trybots: luci.chromium.try:linux-rel
Cq-Include-Trybots: luci.v8.try:v8_linux_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2163881
Auto-Submit: Timothy Gu <timothygu@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67361}
      1aa51b49
    • Bill Budge's avatar
      Revert "[builtins] Clean up the use of class_name / ES5 [[Class]]" · 213016d6
      Bill Budge authored 
      This reverts commit 29c1eab9.

Reason for revert: Causes Blink test failures:
https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/4222

Original change's description:
> [builtins] Clean up the use of class_name / ES5 [[Class]]
> 
> Before ES2015, the ES spec had a [[Class]] internal slot for all
> objects, which Object.prototype.toString() would use to figure the
> returned string. Post-ES2015, the [[Class]] slot was removed in spec for
> all objects, with the @@toStringTag well-known symbol the proper way to
> change Object.prototype.toString() output.
> 
> At the time, spec-identical handling without the use of [[Class]] was
> implemented in V8 for all objects other than API objects, where issues
> with the Web IDL spec [1] prevented Blink, and hence V8, to totally
> migrate to @@toStringTag. However, since 2016 [2] Blink has been setting
> @@toStringTag on API class prototypes to manage the
> Object.prototype.toString() output, so the legacy [[Class]] handling in
> V8 has not been necessary for the past couple of years.
> 
> This CL removes the remaining legacy [[Class]] handling in
> Object.prototype.toString(), JSReceiver::class_name(), and
> GetConstructorName(). However, it does not remove the class_name field
> in FunctionTemplateInfo, as it is still used for the `name` property of
> created functions.
> 
> This CL also cleans up other places in the codebase that still reference
> [[Class]].
> 
> This change should have minimal impact on web-compatibility. For the
> change to be observable, a script must do one of the following:
> 
> 1. delete APIConstructor.prototype[Symbol.toStringTag];
> 2. Object.setPrototypeOf(apiObject, somethingElse);
> 
> Before this CL, these changes will not change the apiObject.toString()
> output. But after this CL, they will make apiObject.toString() show
> "[object Object]" (in the first case) or the @@toStringTag of the other
> prototype (in the latter case).
> 
> However, both are deemed unlikely. @@toStringTag is not well-known
> feature of JavaScript, nor does it get tampered much on API
> constructors. In the second case, setting the prototype of an API object
> would effectly render the object useless, as all its methods (including
> property getters/setters) would no longer be accessible.
> 
> Currently, @@toStringTag-based API object branding is not yet
> implemented by other browsers. This V8 bug in particular has been an
> impediment to standardizing toString behavior. Fixing this bug will
> unblock [3] and lead to a better Web IDL spec, and better toString()
> compatibility for all.
> 
> [1]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244
> [2]: https://crrev.com/909c0d7d5a53c8526ded351683c65ea7d17531d4
> [3]: https://github.com/heycam/webidl/pull/357
> 
> Bug: chromium:793406
> Cq-Include-Trybots: luci.chromium.try:linux-rel
> Change-Id: Iceded24e37afa2646ec385d5018909f55b177f93
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2146996
> Commit-Queue: Timothy Gu <timothygu@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67327}

TBR=verwaest@chromium.org,timothygu@chromium.org

Change-Id: I678d2ffc1064b1d1ddb62024cc23c6c41b216ef4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:793406
Cq-Include-Trybots: luci.chromium.try:linux-rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2163956Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67349}
      213016d6
  21. 23 Apr, 2020 1 commit
    • Timothy Gu's avatar
      [builtins] Clean up the use of class_name / ES5 [[Class]] · 29c1eab9
      Timothy Gu authored 
      Before ES2015, the ES spec had a [[Class]] internal slot for all
objects, which Object.prototype.toString() would use to figure the
returned string. Post-ES2015, the [[Class]] slot was removed in spec for
all objects, with the @@toStringTag well-known symbol the proper way to
change Object.prototype.toString() output.

At the time, spec-identical handling without the use of [[Class]] was
implemented in V8 for all objects other than API objects, where issues
with the Web IDL spec [1] prevented Blink, and hence V8, to totally
migrate to @@toStringTag. However, since 2016 [2] Blink has been setting
@@toStringTag on API class prototypes to manage the
Object.prototype.toString() output, so the legacy [[Class]] handling in
V8 has not been necessary for the past couple of years.

This CL removes the remaining legacy [[Class]] handling in
Object.prototype.toString(), JSReceiver::class_name(), and
GetConstructorName(). However, it does not remove the class_name field
in FunctionTemplateInfo, as it is still used for the `name` property of
created functions.

This CL also cleans up other places in the codebase that still reference
[[Class]].

This change should have minimal impact on web-compatibility. For the
change to be observable, a script must do one of the following:

1. delete APIConstructor.prototype[Symbol.toStringTag];
2. Object.setPrototypeOf(apiObject, somethingElse);

Before this CL, these changes will not change the apiObject.toString()
output. But after this CL, they will make apiObject.toString() show
"[object Object]" (in the first case) or the @@toStringTag of the other
prototype (in the latter case).

However, both are deemed unlikely. @@toStringTag is not well-known
feature of JavaScript, nor does it get tampered much on API
constructors. In the second case, setting the prototype of an API object
would effectly render the object useless, as all its methods (including
property getters/setters) would no longer be accessible.

Currently, @@toStringTag-based API object branding is not yet
implemented by other browsers. This V8 bug in particular has been an
impediment to standardizing toString behavior. Fixing this bug will
unblock [3] and lead to a better Web IDL spec, and better toString()
compatibility for all.

[1]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244
[2]: https://crrev.com/909c0d7d5a53c8526ded351683c65ea7d17531d4
[3]: https://github.com/heycam/webidl/pull/357

Bug: chromium:793406
Cq-Include-Trybots: luci.chromium.try:linux-rel
Change-Id: Iceded24e37afa2646ec385d5018909f55b177f93
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2146996
Commit-Queue: Timothy Gu <timothygu@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67327}
      29c1eab9
  23. 20 Apr, 2020 1 commit
  25. 14 Apr, 2020 1 commit
  27. 03 Mar, 2020 1 commit
  29. 02 Mar, 2020 2 commits
  31. 22 Jan, 2020 1 commit
  33. 20 Dec, 2019 1 commit
    • Tobias Tebbi's avatar
      Revert "Extend GetIterator bytecode to perform JSReceiver check on object[Symbol.iterator]()" · 4671cb56
      Tobias Tebbi authored 
      This reverts commit 91e3243d.

Reason for revert: This deopts to the wrong point.

Original change's description:
> Extend GetIterator bytecode to perform JSReceiver check on object[Symbol.iterator]()
> 
> Current GetIterator bytecode loads and calls @@iterator property on a
> given object. This change extends the bytecode functionality to check
> whether the value returned after calling @@iterator property is a valid
> JSReceiver. The bytecode throws SymbolIteratorInvalid exception if the
> returned value is not a valid JSReceiver. This change absorbs the
> functionality of additional two bytecodes - JumpIfJSReceiver and
> CallRuntime, that are part of the iterator protocol in the GetIterator
> bytecode.
> 
> Bug: v8:9489
> Change-Id: I9e84cfe85eeb9a1b8a97ca0595375ac26ba1bbfd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792905
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
> Cr-Commit-Position: refs/heads/master@{#63704}

TBR=rmcilroy@chromium.org,leszeks@chromium.org,tebbi@chromium.org,swapnilgaikwad@google.com

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: v8:9489
Change-Id: I9324b5b01ead29912ad793a1e7b4d009643d7901
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1960288Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65541}
      4671cb56
  35. 19 Dec, 2019 1 commit
    • Shu-yu Guo's avatar
      Remove per-parameter position var scope · 1b450a17
      Shu-yu Guo authored 
      The spec was normatively changed to simplify var scopes for parameter
expressions. Previously there was a per-parameter var scope in sloppy
mode so direct evals could introduce vars that did not escape the
parameter position. That semantics is complex both for the programmer
and implementation and has resulted in bugs in the past. Furthermore, it
has never been fully interoperable (with Safari in particular). The spec
was instead changed to be simpler: to have a single var scope for
sloppy evals in parameters that encloses the parameter scope and body
scope.

This simplification lets us remove expression-scope-reparenter.

Drive-by removal of stale reference to PatternRewriter.

Bug: v8:7532
Change-Id: Iade5594abe0009f7f3f6a1adad18628b17e1e779
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962471Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65517}
      1b450a17
  37. 09 Dec, 2019 1 commit
    • Leszek Swirski's avatar
      [parser] Use non-eval decl scope's parent for caching · fffea681
      Leszek Swirski authored 
      We use the compilation entry point as a caching scope for deserializing
lookups, to avoid redundantly iterating over parent scopes when
accessing the same variable multiple times.

However, this caching scope messes with lookups that are looking for
lexical name conflicts, as opposed to just resolving variables. In
particular, it messes with name conflict lookups and sloppy block
function hoisting checks, when there are other scopes in the way, e.g.

    function f() {
      let x;
      try {
        throw 0;
      }
      catch (x) {
        // This catch is the entry scope

        // Naive use of caches will find the catch-bound x (which is
        // a VAR), and declare 'no conflict'.
        eval("var x;");

        // Naive use of caches will find the catch-bound x (which is
        // a VAR), and determine that this function can be hoisted.
        eval("{ function x() {} }");
      }
    }

Previously, we worked around this by avoiding cache uses for these
lookups, but this had the issue of instead caching the same variable
multiple times, on different scopes. In particular, we saw:

    function f() {
      with ({}) {
        // This with is the entry scope, any other scope would do
        // though.

        // The conflict check on `var f` caches the function name
        // variable on the function scope, the subsequent 'real'
        // lookup of `f` caches the function name variable on the
        // entry i.e. with scope.
        eval("var f; f;");
      }
    }

With this patch, we change the caching behaviour to cache on the first
non-eval declaration scope above the eval -- in the above examples, this
becomes the parent function "f". For compilations with no intermediate
non-decl scopes (no with or catch scopes between the function and eval)
this becomes equivalent to the existing entry-point-based caching.

This means that normal lookups do have to (sometimes) iterate more scopes,
and we do have to be careful when using the cache to not use it for
lookups in these intermediate scopes (a new IsOuterScope DCHECK guards
against this), but we can now safely ignore the cache scope when doing
the name-collision lookups, as they only iterate up to the outer
non-eval declaration scope anyway.

Bug: chromium:1026603
Bug: chromium:1029461
Change-Id: I9e7a96ce4b8adbc7ed47a49fba6fba58b526235b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1955731
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65391}
      fffea681
  39. 27 Nov, 2019 1 commit
  41. 14 Nov, 2019 1 commit
  43. 11 Nov, 2019 1 commit
  45. 01 Nov, 2019 1 commit
  47. 31 Oct, 2019 1 commit
  49. 28 Oct, 2019 1 commit
  51. 25 Oct, 2019 1 commit
    • Leszek Swirski's avatar
      [heap] Add base class for LargeObjectSpaces · eb667651
      Leszek Swirski authored 
      Both LO_SPACE and NEW_LO_SPACE use the basic page management system of
LargeObjectSpace, but implement different AllocateRaw methods (with
the NEW_LO_SPACE version shadowing the LO_SPACE version).

To clean this up, and allow other future LargeObjectSpace implementations
(in particular, an off-thread variant), refactored the current
LargeObjectSpace into a base class, and make both LargeObjectSpace
(renamed to OldLargeObjectSpace) and NewLargeObjectSpace extend this
class.

Bug: chromium:1011762
Change-Id: I41b45b97f2611611dcfde677213131396df03a5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876824
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64560}
      eb667651
  53. 18 Oct, 2019 1 commit
  55. 16 Sep, 2019 1 commit
  57. 12 Sep, 2019 2 commits
  59. 06 Sep, 2019 1 commit
    • Swapnil Gaikwad's avatar
      Reland "Update GetIterator bytecode to load and call object[Symbol.iterator]" · ffa9f163
      Swapnil Gaikwad authored 
      This is a reland of 8b89a7c3

Reland after disabling the test getting deadlocked with '--gc_stress' flag.
The CL was reverted because of the 'wasm/grow-shared-memory' test from
the mjsunit test suite deadlocked for the 'gc_stress' variant. This is
the known issue (v8:9221) and the deadlocking test is now disabled (
https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788).


Original change's description:
> Update GetIterator bytecode to load and call object[Symbol.iterator]
>
> The functionality of the GetIterator bytecode introduced previously is
> now extended from loading the @@iterator property to calling the property
> as well. This change basically absorbs the functionality of additional
> two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
> Importantly, this change handles the cases of eager and lazy deoptimization
> in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
> eager deopt of the CallProperty0 bytecode, using the continuation builtins.
> This mechanism can work as a template for the future bytecode that require
> handling such inter-bytecode deopt scenario. The tests evaluating the eager
> and lazy deopt scenarios are also included.
>
> Bug: v8:9489
> Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63528}

Bug: v8:9489,v8:9221
Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
Cr-Commit-Position: refs/heads/master@{#63599}
      ffa9f163
  61. 03 Sep, 2019 2 commits
    • Francis McCabe's avatar
      Revert "Update GetIterator bytecode to load and call object[Symbol.iterator]" · af04a51e
      Francis McCabe authored 
      This reverts commit 8b89a7c3.

Reason for revert: GC Stress tests timing out.
See https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/24272

Original change's description:
> Update GetIterator bytecode to load and call object[Symbol.iterator]
> 
> The functionality of the GetIterator bytecode introduced previously is
> now extended from loading the @@iterator property to calling the property
> as well. This change basically absorbs the functionality of additional
> two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
> Importantly, this change handles the cases of eager and lazy deoptimization
> in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
> eager deopt of the CallProperty0 bytecode, using the continuation builtins.
> This mechanism can work as a template for the future bytecode that require
> handling such inter-bytecode deopt scenario. The tests evaluating the eager
> and lazy deopt scenarios are also included.
> 
> Bug: v8:9489
> Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63528}

TBR=rmcilroy@chromium.org,neis@chromium.org,leszeks@chromium.org,tebbi@chromium.org,swapnilgaikwad@google.com

Change-Id: I9ae475f71275f71f1b9e60b8bf0578e21ce2704b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9489
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1783736Reviewed-by: 's avatarFrancis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63536}
      af04a51e
    • Swapnil Gaikwad's avatar
      Update GetIterator bytecode to load and call object[Symbol.iterator] · 8b89a7c3
      Swapnil Gaikwad authored 
      The functionality of the GetIterator bytecode introduced previously is
now extended from loading the @@iterator property to calling the property
as well. This change basically absorbs the functionality of additional
two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
Importantly, this change handles the cases of eager and lazy deoptimization
in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
eager deopt of the CallProperty0 bytecode, using the continuation builtins.
This mechanism can work as a template for the future bytecode that require
handling such inter-bytecode deopt scenario. The tests evaluating the eager
and lazy deopt scenarios are also included.

Bug: v8:9489
Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63528}
      8b89a7c3