Reland2 [Mojo Video Capture] Replace method OnIncomingCapturedVideoFrame() with OnIncomingCapturedBu

Reland2 [Mojo Video Capture] Replace method OnIncomingCapturedVideoFrame() with OnIncomingCapturedBufferExt()

PatchSet#1 is the state as previously reviewed, landed, and reverted.
PatchSet#2 is the fix for the caused issue.

Description of issue and fix:

The original CL caused crbug.com/678766.
Method OnIncomingCapturedBufferExt() unwrapped |memory_handle| and passed it 
to |frame|. However, |frame| did not take ownership, resulting in 
|memory_handle| never getting closed.
Since the memory handle inside |frame| is not being used downstream anyway, 
the fix is to use a NULLHandle() instead of unwrapping and attaching ownership.


Description of original CL:

In interface media:VideoCaptureDevice::Client, replaced the method
OnIncomingCapturedVideoFrame() with OnIncomingCapturedBufferExt(). Compared to
method OnIncomingCaptureBuffer(), the VideoFrame parameter in
OnIncomingCapturedVideoFrame() was only used for passing along a bit of extra
information, namely a custom |visible_rect| as well as some
|additional_metadata|. The new method makes the intent clear and eliminates the
need for passing a media::VideoFrame that is partly redundant with the also
passed media::VideoCaptureDevice::Client::Buffer.

This CL breaks the video_capture_unittests, because current implementation of
the video_capture service wants to use VideoCaptureDeviceClient with buffers
that are backed by MojoSharedMemoryBufferTracker instances instead of the 
"regular" shared memory buffers. With this CL, VideoCaptureDeviceClient is
dropping support for this. We are working towards making the video_capture
service work with the regular buffers. To keep CLs small, we defer changes
to the service to after refactorings of VideoCaptureController and
VideoCaptureManager are complete and deactive the video_capture_unittests
temporarily. This is acceptable for the time being, since they are not run on
the bots yet. The CL that re-enables them is currently labeled CL1.9.22 in the
design doc.

This CL is part of the Mojo Video Capture work. For the bigger picture,
see [1] CL1.9.9

BUG=584797
TEST=
  content_unittests --gtest_filter="*Video*",
  video_capture_unittests,
  Apprtc loopback on Debug,
  Desktop Capture Example extension on Release

[1] https://docs.google.com/a/chromium.org/document/d/1Qw7rw1AJy0QHXjha36jZNiEuxsxWslJ_X-zpOhijvI8/edit?usp=sharing

Committed: https://crrev.com/fc2e2a6f6597cf6582673572bbf22268e445dac0
Cr-Original-Commit-Position: refs/heads/master@{#441391}
Review-Url: https://codereview.chromium.org/2621743002
Cr-Commit-Position: refs/heads/master@{#442796}
Committed: https://chromium.googlesource.com/chromium/src/+/690089d348c70b998fa589cd8ac74a5b274ee2a7

[chfremer, 2017-01-09 19:22:17]

Description was changed from

==========
State as reverted.

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

to

==========
Reland2 [Mojo Video Capture] Replace method OnIncomingCapturedVideoFrame() with
OnIncomingCapturedBufferExt()

PatchSet#1 is the state as previously reviewed, landed, and reverted.
PatchSet#2 is the fix for the caused issue.

Description of issue and fix:

Method OnIncomingCapturedBufferExt() unwrapped |memory_handle| and passed int 
to |frame|. However, |frame| did not take ownership, resulting in 
|memory_handle| never getting closed.
Since the memory handle inside |frame| is not being used downstream anyway, 
the fix is to use a NULLHandle() instead of unwrapping and attaching ownership.


Description of original CL:

In interface media:VideoCaptureDevice::Client, replaced the method
OnIncomingCapturedVideoFrame() with OnIncomingCapturedBufferExt(). Compared to
method OnIncomingCaptureBuffer(), the VideoFrame parameter in
OnIncomingCapturedVideoFrame() was only used for passing along a bit of extra
information, namely a custom |visible_rect| as well as some
|additional_metadata|. The new method makes the intent clear and eliminates the
need for passing a media::VideoFrame that is partly redundant with the also
passed media::VideoCaptureDevice::Client::Buffer.

This CL breaks the video_capture_unittests, because current implementation of
the video_capture service wants to use VideoCaptureDeviceClient with buffers
that are backed by MojoSharedMemoryBufferTracker instances instead of the 
"regular" shared memory buffers. With this CL, VideoCaptureDeviceClient is
dropping support for this. We are working towards making the video_capture
service work with the regular buffers. To keep CLs small, we defer changes
to the service to after refactorings of VideoCaptureController and
VideoCaptureManager are complete and deactive the video_capture_unittests
temporarily. This is acceptable for the time being, since they are not run on
the bots yet. The CL that re-enables them is currently labeled CL1.9.22 in the
design doc.

This CL is part of the Mojo Video Capture work. For the bigger picture,
see [1] CL1.9.9

BUG=584797
TEST=
  content_unittests --gtest_filter="*Video*",
  video_capture_unittests,
  Apprtc loopback on Debug,
  Desktop Capture Example extension on Release

[1]
https://docs.google.com/a/chromium.org/document/d/1Qw7rw1AJy0QHXjha36jZNiEuxs...

Committed: https://crrev.com/fc2e2a6f6597cf6582673572bbf22268e445dac0
Cr-Commit-Position: refs/heads/master@{#441391}
==========

[chfremer, 2017-01-09 19:23:07]

Description was changed from

==========
Reland2 [Mojo Video Capture] Replace method OnIncomingCapturedVideoFrame() with
OnIncomingCapturedBufferExt()

PatchSet#1 is the state as previously reviewed, landed, and reverted.
PatchSet#2 is the fix for the caused issue.

Description of issue and fix:

Method OnIncomingCapturedBufferExt() unwrapped |memory_handle| and passed int 
to |frame|. However, |frame| did not take ownership, resulting in 
|memory_handle| never getting closed.
Since the memory handle inside |frame| is not being used downstream anyway, 
the fix is to use a NULLHandle() instead of unwrapping and attaching ownership.


Description of original CL:

In interface media:VideoCaptureDevice::Client, replaced the method
OnIncomingCapturedVideoFrame() with OnIncomingCapturedBufferExt(). Compared to
method OnIncomingCaptureBuffer(), the VideoFrame parameter in
OnIncomingCapturedVideoFrame() was only used for passing along a bit of extra
information, namely a custom |visible_rect| as well as some
|additional_metadata|. The new method makes the intent clear and eliminates the
need for passing a media::VideoFrame that is partly redundant with the also
passed media::VideoCaptureDevice::Client::Buffer.

This CL breaks the video_capture_unittests, because current implementation of
the video_capture service wants to use VideoCaptureDeviceClient with buffers
that are backed by MojoSharedMemoryBufferTracker instances instead of the 
"regular" shared memory buffers. With this CL, VideoCaptureDeviceClient is
dropping support for this. We are working towards making the video_capture
service work with the regular buffers. To keep CLs small, we defer changes
to the service to after refactorings of VideoCaptureController and
VideoCaptureManager are complete and deactive the video_capture_unittests
temporarily. This is acceptable for the time being, since they are not run on
the bots yet. The CL that re-enables them is currently labeled CL1.9.22 in the
design doc.

This CL is part of the Mojo Video Capture work. For the bigger picture,
see [1] CL1.9.9

BUG=584797
TEST=
  content_unittests --gtest_filter="*Video*",
  video_capture_unittests,
  Apprtc loopback on Debug,
  Desktop Capture Example extension on Release

[1]
https://docs.google.com/a/chromium.org/document/d/1Qw7rw1AJy0QHXjha36jZNiEuxs...

Committed: https://crrev.com/fc2e2a6f6597cf6582673572bbf22268e445dac0
Cr-Commit-Position: refs/heads/master@{#441391}
==========

to

==========
Reland2 [Mojo Video Capture] Replace method OnIncomingCapturedVideoFrame() with
OnIncomingCapturedBufferExt()

PatchSet#1 is the state as previously reviewed, landed, and reverted.
PatchSet#2 is the fix for the caused issue.

Description of issue and fix:

Method OnIncomingCapturedBufferExt() unwrapped |memory_handle| and passed it 
to |frame|. However, |frame| did not take ownership, resulting in 
|memory_handle| never getting closed.
Since the memory handle inside |frame| is not being used downstream anyway, 
the fix is to use a NULLHandle() instead of unwrapping and attaching ownership.


Description of original CL:

In interface media:VideoCaptureDevice::Client, replaced the method
OnIncomingCapturedVideoFrame() with OnIncomingCapturedBufferExt(). Compared to
method OnIncomingCaptureBuffer(), the VideoFrame parameter in
OnIncomingCapturedVideoFrame() was only used for passing along a bit of extra
information, namely a custom |visible_rect| as well as some
|additional_metadata|. The new method makes the intent clear and eliminates the
need for passing a media::VideoFrame that is partly redundant with the also
passed media::VideoCaptureDevice::Client::Buffer.

This CL breaks the video_capture_unittests, because current implementation of
the video_capture service wants to use VideoCaptureDeviceClient with buffers
that are backed by MojoSharedMemoryBufferTracker instances instead of the 
"regular" shared memory buffers. With this CL, VideoCaptureDeviceClient is
dropping support for this. We are working towards making the video_capture
service work with the regular buffers. To keep CLs small, we defer changes
to the service to after refactorings of VideoCaptureController and
VideoCaptureManager are complete and deactive the video_capture_unittests
temporarily. This is acceptable for the time being, since they are not run on
the bots yet. The CL that re-enables them is currently labeled CL1.9.22 in the
design doc.

This CL is part of the Mojo Video Capture work. For the bigger picture,
see [1] CL1.9.9

BUG=584797
TEST=
  content_unittests --gtest_filter="*Video*",
  video_capture_unittests,
  Apprtc loopback on Debug,
  Desktop Capture Example extension on Release

[1]
https://docs.google.com/a/chromium.org/document/d/1Qw7rw1AJy0QHXjha36jZNiEuxs...

Committed: https://crrev.com/fc2e2a6f6597cf6582673572bbf22268e445dac0
Cr-Commit-Position: refs/heads/master@{#441391}
==========

[chfremer, 2017-01-09 19:35:29]

Description was changed from

==========
Reland2 [Mojo Video Capture] Replace method OnIncomingCapturedVideoFrame() with
OnIncomingCapturedBufferExt()

PatchSet#1 is the state as previously reviewed, landed, and reverted.
PatchSet#2 is the fix for the caused issue.

Description of issue and fix:

Method OnIncomingCapturedBufferExt() unwrapped |memory_handle| and passed it 
to |frame|. However, |frame| did not take ownership, resulting in 
|memory_handle| never getting closed.
Since the memory handle inside |frame| is not being used downstream anyway, 
the fix is to use a NULLHandle() instead of unwrapping and attaching ownership.


Description of original CL:

In interface media:VideoCaptureDevice::Client, replaced the method
OnIncomingCapturedVideoFrame() with OnIncomingCapturedBufferExt(). Compared to
method OnIncomingCaptureBuffer(), the VideoFrame parameter in
OnIncomingCapturedVideoFrame() was only used for passing along a bit of extra
information, namely a custom |visible_rect| as well as some
|additional_metadata|. The new method makes the intent clear and eliminates the
need for passing a media::VideoFrame that is partly redundant with the also
passed media::VideoCaptureDevice::Client::Buffer.

This CL breaks the video_capture_unittests, because current implementation of
the video_capture service wants to use VideoCaptureDeviceClient with buffers
that are backed by MojoSharedMemoryBufferTracker instances instead of the 
"regular" shared memory buffers. With this CL, VideoCaptureDeviceClient is
dropping support for this. We are working towards making the video_capture
service work with the regular buffers. To keep CLs small, we defer changes
to the service to after refactorings of VideoCaptureController and
VideoCaptureManager are complete and deactive the video_capture_unittests
temporarily. This is acceptable for the time being, since they are not run on
the bots yet. The CL that re-enables them is currently labeled CL1.9.22 in the
design doc.

This CL is part of the Mojo Video Capture work. For the bigger picture,
see [1] CL1.9.9

BUG=584797
TEST=
  content_unittests --gtest_filter="*Video*",
  video_capture_unittests,
  Apprtc loopback on Debug,
  Desktop Capture Example extension on Release

[1]
https://docs.google.com/a/chromium.org/document/d/1Qw7rw1AJy0QHXjha36jZNiEuxs...

Committed: https://crrev.com/fc2e2a6f6597cf6582673572bbf22268e445dac0
Cr-Commit-Position: refs/heads/master@{#441391}
==========

to

==========
Reland2 [Mojo Video Capture] Replace method OnIncomingCapturedVideoFrame() with
OnIncomingCapturedBufferExt()

PatchSet#1 is the state as previously reviewed, landed, and reverted.
PatchSet#2 is the fix for the caused issue.

Description of issue and fix:

The original CL caused crbug.com/678766.
Method OnIncomingCapturedBufferExt() unwrapped |memory_handle| and passed it 
to |frame|. However, |frame| did not take ownership, resulting in 
|memory_handle| never getting closed.
Since the memory handle inside |frame| is not being used downstream anyway, 
the fix is to use a NULLHandle() instead of unwrapping and attaching ownership.


Description of original CL:

In interface media:VideoCaptureDevice::Client, replaced the method
OnIncomingCapturedVideoFrame() with OnIncomingCapturedBufferExt(). Compared to
method OnIncomingCaptureBuffer(), the VideoFrame parameter in
OnIncomingCapturedVideoFrame() was only used for passing along a bit of extra
information, namely a custom |visible_rect| as well as some
|additional_metadata|. The new method makes the intent clear and eliminates the
need for passing a media::VideoFrame that is partly redundant with the also
passed media::VideoCaptureDevice::Client::Buffer.

This CL breaks the video_capture_unittests, because current implementation of
the video_capture service wants to use VideoCaptureDeviceClient with buffers
that are backed by MojoSharedMemoryBufferTracker instances instead of the 
"regular" shared memory buffers. With this CL, VideoCaptureDeviceClient is
dropping support for this. We are working towards making the video_capture
service work with the regular buffers. To keep CLs small, we defer changes
to the service to after refactorings of VideoCaptureController and
VideoCaptureManager are complete and deactive the video_capture_unittests
temporarily. This is acceptable for the time being, since they are not run on
the bots yet. The CL that re-enables them is currently labeled CL1.9.22 in the
design doc.

This CL is part of the Mojo Video Capture work. For the bigger picture,
see [1] CL1.9.9

BUG=584797
TEST=
  content_unittests --gtest_filter="*Video*",
  video_capture_unittests,
  Apprtc loopback on Debug,
  Desktop Capture Example extension on Release

[1]
https://docs.google.com/a/chromium.org/document/d/1Qw7rw1AJy0QHXjha36jZNiEuxs...

Committed: https://crrev.com/fc2e2a6f6597cf6582673572bbf22268e445dac0
Cr-Commit-Position: refs/heads/master@{#441391}
==========

[chfremer, 2017-01-09 20:53:41]

chfremer@chromium.org changed reviewers:
+ mcasas@chromium.org, miu@chromium.org

[chfremer, 2017-01-09 20:53:42]

mcasas@: PTAL
miu@: PTAL

Fixed issue of file handles not getting closed.

[chfremer, 2017-01-09 23:08:59]

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

[commit-bot: I haz the power, 2017-01-09 23:09:29]

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-01-10 01:34:52]

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

[commit-bot: I haz the power, 2017-01-10 01:34:52]

Dry run: This issue passed the CQ dry run.

[miu, 2017-01-10 23:32:19]

lgtm % decision for you:

https://codereview.chromium.org/2621743002/diff/20001/media/capture/video/vid...
File media/capture/video/video_capture_device_client.cc (right):

https://codereview.chromium.org/2621743002/diff/20001/media/capture/video/vid...
media/capture/video/video_capture_device_client.cc:319:
base::SharedMemory::NULLHandle(),       // handle
This could either be great or not:

Great in that maybe all the special code for managing ownership of shared memory
can be removed from media::VideoFrame.

Bad in that maybe we want to ensure media::VideoFrame retains a ref-count on the
shared memory so that it is guaranteed to out-live the VideoFrame?

Your call, as your brain's "cache memory" is better primed than mine for all of
this right now. ;-)

[chfremer, 2017-01-10 23:45:29]

miu@ Thanks for the review.
mcasas@: Please RS

https://codereview.chromium.org/2621743002/diff/20001/media/capture/video/vid...
File media/capture/video/video_capture_device_client.cc (right):

https://codereview.chromium.org/2621743002/diff/20001/media/capture/video/vid...
media/capture/video/video_capture_device_client.cc:319:
base::SharedMemory::NULLHandle(),       // handle
On 2017/01/10 23:32:19, miu wrote:
> This could either be great or not:
> 
> Great in that maybe all the special code for managing ownership of shared
memory
> can be removed from media::VideoFrame.
> 
> Bad in that maybe we want to ensure media::VideoFrame retains a ref-count on
the
> shared memory so that it is guaranteed to out-live the VideoFrame?
> 
> Your call, as your brain's "cache memory" is better primed than mine for all
of
> this right now. ;-)

In this case, I think it is okay to not attach a ref-count of the shared memory
to video frame, for the following two reasons:
1. The code before this CL did not do it either, and I am trying to not make any
functional change.
2. The ownership of buffer is already included in |buffer|.

The need to wrap into a media::VideoFrame also goes away in the subsequent CL
anyway.

[mcasas, 2017-01-10 23:48:04]

On 2017/01/10 23:45:29, chfremer wrote:
> miu@ Thanks for the review.
> mcasas@: Please RS
> 
>
https://codereview.chromium.org/2621743002/diff/20001/media/capture/video/vid...
> File media/capture/video/video_capture_device_client.cc (right):
> 
>
https://codereview.chromium.org/2621743002/diff/20001/media/capture/video/vid...
> media/capture/video/video_capture_device_client.cc:319:
> base::SharedMemory::NULLHandle(),       // handle
> On 2017/01/10 23:32:19, miu wrote:
> > This could either be great or not:
> > 
> > Great in that maybe all the special code for managing ownership of shared
> memory
> > can be removed from media::VideoFrame.
> > 
> > Bad in that maybe we want to ensure media::VideoFrame retains a ref-count on
> the
> > shared memory so that it is guaranteed to out-live the VideoFrame?
> > 
> > Your call, as your brain's "cache memory" is better primed than mine for all
> of
> > this right now. ;-)
> 
> In this case, I think it is okay to not attach a ref-count of the shared
memory
> to video frame, for the following two reasons:
> 1. The code before this CL did not do it either, and I am trying to not make
any
> functional change.
> 2. The ownership of buffer is already included in |buffer|.
> 
> The need to wrap into a media::VideoFrame also goes away in the subsequent CL
> anyway.

RS lgtm

[chfremer, 2017-01-10 23:52:51]

The CQ bit was checked by chfremer@chromium.org

[commit-bot: I haz the power, 2017-01-10 23:53:21]

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-01-11 04:15:46]

CQ is committing da patch.

Bot data: {"patchset_id": 20001, "attempt_start_ts": 1484092371191710,
"parent_rev": "6b13e1b5dfc1d83b733e6e6ec4d536a47feb8c7e", "commit_rev":
"690089d348c70b998fa589cd8ac74a5b274ee2a7"}

[commit-bot: I haz the power, 2017-01-11 04:16:14]

Description was changed from

==========
Reland2 [Mojo Video Capture] Replace method OnIncomingCapturedVideoFrame() with
OnIncomingCapturedBufferExt()

PatchSet#1 is the state as previously reviewed, landed, and reverted.
PatchSet#2 is the fix for the caused issue.

Description of issue and fix:

The original CL caused crbug.com/678766.
Method OnIncomingCapturedBufferExt() unwrapped |memory_handle| and passed it 
to |frame|. However, |frame| did not take ownership, resulting in 
|memory_handle| never getting closed.
Since the memory handle inside |frame| is not being used downstream anyway, 
the fix is to use a NULLHandle() instead of unwrapping and attaching ownership.


Description of original CL:

In interface media:VideoCaptureDevice::Client, replaced the method
OnIncomingCapturedVideoFrame() with OnIncomingCapturedBufferExt(). Compared to
method OnIncomingCaptureBuffer(), the VideoFrame parameter in
OnIncomingCapturedVideoFrame() was only used for passing along a bit of extra
information, namely a custom |visible_rect| as well as some
|additional_metadata|. The new method makes the intent clear and eliminates the
need for passing a media::VideoFrame that is partly redundant with the also
passed media::VideoCaptureDevice::Client::Buffer.

This CL breaks the video_capture_unittests, because current implementation of
the video_capture service wants to use VideoCaptureDeviceClient with buffers
that are backed by MojoSharedMemoryBufferTracker instances instead of the 
"regular" shared memory buffers. With this CL, VideoCaptureDeviceClient is
dropping support for this. We are working towards making the video_capture
service work with the regular buffers. To keep CLs small, we defer changes
to the service to after refactorings of VideoCaptureController and
VideoCaptureManager are complete and deactive the video_capture_unittests
temporarily. This is acceptable for the time being, since they are not run on
the bots yet. The CL that re-enables them is currently labeled CL1.9.22 in the
design doc.

This CL is part of the Mojo Video Capture work. For the bigger picture,
see [1] CL1.9.9

BUG=584797
TEST=
  content_unittests --gtest_filter="*Video*",
  video_capture_unittests,
  Apprtc loopback on Debug,
  Desktop Capture Example extension on Release

[1]
https://docs.google.com/a/chromium.org/document/d/1Qw7rw1AJy0QHXjha36jZNiEuxs...

Committed: https://crrev.com/fc2e2a6f6597cf6582673572bbf22268e445dac0
Cr-Commit-Position: refs/heads/master@{#441391}
==========

to

==========
Reland2 [Mojo Video Capture] Replace method OnIncomingCapturedVideoFrame() with
OnIncomingCapturedBufferExt()

PatchSet#1 is the state as previously reviewed, landed, and reverted.
PatchSet#2 is the fix for the caused issue.

Description of issue and fix:

The original CL caused crbug.com/678766.
Method OnIncomingCapturedBufferExt() unwrapped |memory_handle| and passed it 
to |frame|. However, |frame| did not take ownership, resulting in 
|memory_handle| never getting closed.
Since the memory handle inside |frame| is not being used downstream anyway, 
the fix is to use a NULLHandle() instead of unwrapping and attaching ownership.


Description of original CL:

In interface media:VideoCaptureDevice::Client, replaced the method
OnIncomingCapturedVideoFrame() with OnIncomingCapturedBufferExt(). Compared to
method OnIncomingCaptureBuffer(), the VideoFrame parameter in
OnIncomingCapturedVideoFrame() was only used for passing along a bit of extra
information, namely a custom |visible_rect| as well as some
|additional_metadata|. The new method makes the intent clear and eliminates the
need for passing a media::VideoFrame that is partly redundant with the also
passed media::VideoCaptureDevice::Client::Buffer.

This CL breaks the video_capture_unittests, because current implementation of
the video_capture service wants to use VideoCaptureDeviceClient with buffers
that are backed by MojoSharedMemoryBufferTracker instances instead of the 
"regular" shared memory buffers. With this CL, VideoCaptureDeviceClient is
dropping support for this. We are working towards making the video_capture
service work with the regular buffers. To keep CLs small, we defer changes
to the service to after refactorings of VideoCaptureController and
VideoCaptureManager are complete and deactive the video_capture_unittests
temporarily. This is acceptable for the time being, since they are not run on
the bots yet. The CL that re-enables them is currently labeled CL1.9.22 in the
design doc.

This CL is part of the Mojo Video Capture work. For the bigger picture,
see [1] CL1.9.9

BUG=584797
TEST=
  content_unittests --gtest_filter="*Video*",
  video_capture_unittests,
  Apprtc loopback on Debug,
  Desktop Capture Example extension on Release

[1]
https://docs.google.com/a/chromium.org/document/d/1Qw7rw1AJy0QHXjha36jZNiEuxs...

Committed: https://crrev.com/fc2e2a6f6597cf6582673572bbf22268e445dac0
Cr-Original-Commit-Position: refs/heads/master@{#441391}
Review-Url: https://codereview.chromium.org/2621743002
Cr-Commit-Position: refs/heads/master@{#442796}
Committed:
https://chromium.googlesource.com/chromium/src/+/690089d348c70b998fa589cd8ac7...
==========

[commit-bot: I haz the power, 2017-01-11 04:16:16]

Committed patchset #2 (id:20001) as
https://chromium.googlesource.com/chromium/src/+/690089d348c70b998fa589cd8ac7...