Make RendererCompositorFrameSink derive from ClientCompositorFrameSink

Make RendererCompositorFrameSink derive from ClientCompositorFrameSink

RendererCompositorFrameSink is pretty much a more specialized version
of ClientCompositorFrameSink for the renderer. By deriving from
ClientCompositorFrameSink, some code reuse is possible.

BUG=726485
TBR=sadrul@chromium.org

Review-Url: https://codereview.chromium.org/2903853002
Cr-Commit-Position: refs/heads/master@{#475563}
Committed: https://chromium.googlesource.com/chromium/src/+/69f7eaad72b5c7419e014f044df6c7a2df054b86

[Saman Sami, 2017-05-24 14:31:24]

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

[commit-bot: I haz the power, 2017-05-24 14:31: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-05-24 14:46:12]

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

[commit-bot: I haz the power, 2017-05-24 14:46:12]

Dry run: Try jobs failed on following builders:
  cast_shell_android on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)

[Saman Sami, 2017-05-24 16:51:30]

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

[commit-bot: I haz the power, 2017-05-24 16:51:50]

Dry run: CQ is trying da patch.

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

[Saman Sami, 2017-05-24 16:59:30]

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

[commit-bot: I haz the power, 2017-05-24 17:00:22]

Dry run: CQ is trying da patch.

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

[Saman Sami, 2017-05-24 17:01:50]

samans@chromium.org changed reviewers:
+ fsamuel@chromium.org

[commit-bot: I haz the power, 2017-05-24 17:10:51]

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

[commit-bot: I haz the power, 2017-05-24 17:10:52]

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_...)

[Saman Sami, 2017-05-24 17:21:14]

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

[commit-bot: I haz the power, 2017-05-24 17:21:48]

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-05-24 17:26:06]

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

[commit-bot: I haz the power, 2017-05-24 17:26:07]

Dry run: Try jobs failed on following builders:
  android_cronet on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_cron...)

[Saman Sami, 2017-05-24 17:46:22]

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

[commit-bot: I haz the power, 2017-05-24 17:47:02]

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-05-24 17:51:28]

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

[commit-bot: I haz the power, 2017-05-24 17:51:29]

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

[Saman Sami, 2017-05-24 20:47:01]

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

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

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-05-24 20:52:14]

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

[commit-bot: I haz the power, 2017-05-24 20:52:15]

Dry run: Try jobs failed on following builders:
  android_clang_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...)
  android_compile_dbg on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)
  cast_shell_android on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)

[Fady Samuel, 2017-05-24 21:10:15]

Looks good once the bots are happy.

[Fady Samuel, 2017-05-26 12:00:18]

https://codereview.chromium.org/2903853002/diff/60001/content/renderer/gpu/re...
File content/renderer/gpu/renderer_compositor_frame_sink.cc (left):

https://codereview.chromium.org/2903853002/diff/60001/content/renderer/gpu/re...
content/renderer/gpu/renderer_compositor_frame_sink.cc:38:
scoped_refptr<FrameSwapMessageQueue> swap_frame_message_queue)
why do we hold on to this if we don't use it anymore?

[Saman Sami, 2017-05-26 14:32:37]

https://codereview.chromium.org/2903853002/diff/60001/content/renderer/gpu/re...
File content/renderer/gpu/renderer_compositor_frame_sink.cc (left):

https://codereview.chromium.org/2903853002/diff/60001/content/renderer/gpu/re...
content/renderer/gpu/renderer_compositor_frame_sink.cc:38:
scoped_refptr<FrameSwapMessageQueue> swap_frame_message_queue)
On 2017/05/26 12:00:18, Fady Samuel wrote:
> why do we hold on to this if we don't use it anymore?

Good catch. Let me get rid of this in a separate CL.

[Saman Sami, 2017-05-26 15:57:54]

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

[commit-bot: I haz the power, 2017-05-26 15:58:34]

Dry run: CQ is trying da patch.

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

[Saman Sami, 2017-05-26 15:59:27]

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

[commit-bot: I haz the power, 2017-05-26 15:59: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-05-26 16:17:33]

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

[commit-bot: I haz the power, 2017-05-26 16:17:34]

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

[Saman Sami, 2017-05-26 18:30:17]

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

[commit-bot: I haz the power, 2017-05-26 18:30:50]

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-05-26 18:41:58]

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

[commit-bot: I haz the power, 2017-05-26 18:41:59]

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

[Saman Sami, 2017-05-26 18:56:57]

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

[commit-bot: I haz the power, 2017-05-26 18:57:42]

Dry run: CQ is trying da patch.

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

[Saman Sami, 2017-05-26 19:13:14]

Description was changed from

==========
Make RendererCompositorFrameSink derive from ClientCompositorFrameSink
==========

to

==========
Make RendererCompositorFrameSink derive from ClientCompositorFrameSink

RendererCompositorFrameSink is pretty much a more specialized version
of ClientCompositorFrameSink for the renderer. By deriving from
ClientCompositorFrameSink, some code reuse is possible.

BUG=726485
==========

[Fady Samuel, 2017-05-26 19:35:02]

lgtm

[Saman Sami, 2017-05-26 20:25:05]

samans@chromium.org changed reviewers:
+ piman@chromium.org

[Saman Sami, 2017-05-26 20:25:33]

piman please review content/

[Saman Sami, 2017-05-26 20:26:45]

Description was changed from

==========
Make RendererCompositorFrameSink derive from ClientCompositorFrameSink

RendererCompositorFrameSink is pretty much a more specialized version
of ClientCompositorFrameSink for the renderer. By deriving from
ClientCompositorFrameSink, some code reuse is possible.

BUG=726485
==========

to

==========
Make RendererCompositorFrameSink derive from ClientCompositorFrameSink

RendererCompositorFrameSink is pretty much a more specialized version
of ClientCompositorFrameSink for the renderer. By deriving from
ClientCompositorFrameSink, some code reuse is possible.

BUG=726485
TBR=sadrul@chromium.org
==========

[Saman Sami, 2017-05-26 20:26:45]

samans@chromium.org changed reviewers:
+ sadrul@chromium.org

[commit-bot: I haz the power, 2017-05-26 21:28:10]

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

[commit-bot: I haz the power, 2017-05-26 21:28:11]

Dry run: This issue passed the CQ dry run.

[piman, 2017-05-26 21:34:02]

I worry a little bit that we'll end up into a "fragile base class" situation,
particularly if RendererCompositorFrameSink::SubmitCompositorFrame is a
completely separate implementation from
ClientCompositorFrameSink::SubmitCompositorFrame.
Assuming we can reland https://codereview.chromium.org/2899073006, is there a
way we could have a single class, and "externalize" the logic around when to
recreate a local id, e.g. with a callback or a simple client interface
containing a virtual bool ShouldCreateNewLocalId(const cc::CompositorFrame&
frame), since that's the only difference left?

https://codereview.chromium.org/2903853002/diff/140001/components/viz/client/...
File components/viz/client/client_compositor_frame_sink.cc (right):

https://codereview.chromium.org/2903853002/diff/140001/components/viz/client/...
components/viz/client/client_compositor_frame_sink.cc:60:
DCHECK_CALLED_ON_VALID_THREAD(thread_checker_);
nit: duplicate of the above?

https://codereview.chromium.org/2903853002/diff/140001/content/renderer/gpu/r...
File content/renderer/gpu/renderer_compositor_frame_sink.h (right):

https://codereview.chromium.org/2903853002/diff/140001/content/renderer/gpu/r...
content/renderer/gpu/renderer_compositor_frame_sink.h:110:
cc::LocalSurfaceIdAllocator id_allocator_;
These duplicate (and hide) the ClientCompositorFrameSink ones. Could we share?

[Saman Sami, 2017-05-29 15:13:12]

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

[commit-bot: I haz the power, 2017-05-29 15:13:24]

Dry run: CQ is trying da patch.

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

[Saman Sami, 2017-05-29 15:17:54]

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

[commit-bot: I haz the power, 2017-05-29 15:18:10]

Dry run: CQ is trying da patch.

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

[Saman Sami, 2017-05-29 15:23:54]

On 2017/05/26 21:34:02, piman wrote:
> I worry a little bit that we'll end up into a "fragile base class" situation,
> particularly if RendererCompositorFrameSink::SubmitCompositorFrame is a
> completely separate implementation from
> ClientCompositorFrameSink::SubmitCompositorFrame.
> Assuming we can reland https://codereview.chromium.org/2899073006, is there a
> way we could have a single class, and "externalize" the logic around when to
> recreate a local id, e.g. with a callback or a simple client interface
> containing a virtual bool ShouldCreateNewLocalId(const cc::CompositorFrame&
> frame), since that's the only difference left?
> 
>
https://codereview.chromium.org/2903853002/diff/140001/components/viz/client/...
> File components/viz/client/client_compositor_frame_sink.cc (right):
> 
>
https://codereview.chromium.org/2903853002/diff/140001/components/viz/client/...
> components/viz/client/client_compositor_frame_sink.cc:60:
> DCHECK_CALLED_ON_VALID_THREAD(thread_checker_);
> nit: duplicate of the above?
> 
>
https://codereview.chromium.org/2903853002/diff/140001/content/renderer/gpu/r...
> File content/renderer/gpu/renderer_compositor_frame_sink.h (right):
> 
>
https://codereview.chromium.org/2903853002/diff/140001/content/renderer/gpu/r...
> content/renderer/gpu/renderer_compositor_frame_sink.h:110:
> cc::LocalSurfaceIdAllocator id_allocator_;
> These duplicate (and hide) the ClientCompositorFrameSink ones. Could we share?

I understand your concern. We are aiming for unification of these two classes,
however I'm not entirely sure it's feasible. The swap message stuff will go
away, but I can think of other stuff that will be added. I moved the decision
about allocating a new LocalSurfaceId to a separate virtual method that the
child can override and now RCFS::SubmitCompositorFrame calls to
CCFS::SubmitCompositorFrame at some point which I assume solves the fragility
issue to some extent? Could you take another look please?

[Saman Sami, 2017-05-29 15:24:45]

https://codereview.chromium.org/2903853002/diff/140001/components/viz/client/...
File components/viz/client/client_compositor_frame_sink.cc (right):

https://codereview.chromium.org/2903853002/diff/140001/components/viz/client/...
components/viz/client/client_compositor_frame_sink.cc:60:
DCHECK_CALLED_ON_VALID_THREAD(thread_checker_);
On 2017/05/26 21:34:02, piman wrote:
> nit: duplicate of the above?

Done.

https://codereview.chromium.org/2903853002/diff/140001/content/renderer/gpu/r...
File content/renderer/gpu/renderer_compositor_frame_sink.h (right):

https://codereview.chromium.org/2903853002/diff/140001/content/renderer/gpu/r...
content/renderer/gpu/renderer_compositor_frame_sink.h:110:
cc::LocalSurfaceIdAllocator id_allocator_;
On 2017/05/26 21:34:02, piman wrote:
> These duplicate (and hide) the ClientCompositorFrameSink ones. Could we share?

I removed the one in RendererCompositorFrameSink.

[Saman Sami, 2017-05-29 15:31:55]

Patchset #9 (id:160001) has been deleted

[commit-bot: I haz the power, 2017-05-29 16:30:56]

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

[commit-bot: I haz the power, 2017-05-29 16:30:57]

Dry run: This issue passed the CQ dry run.

[sadrul, 2017-05-29 16:56:47]

lgtm

https://codereview.chromium.org/2903853002/diff/180001/components/viz/client/...
File components/viz/client/client_compositor_frame_sink.h (right):

https://codereview.chromium.org/2903853002/diff/180001/components/viz/client/...
components/viz/client/client_compositor_frame_sink.h:41: bool
enable_surface_synchronization);
Should there be an InitParams for these?

https://codereview.chromium.org/2903853002/diff/180001/ui/aura/mus/window_por...
File ui/aura/mus/window_port_mus.cc (right):

https://codereview.chromium.org/2903853002/diff/180001/ui/aura/mus/window_por...
ui/aura/mus/window_port_mus.cc:109: nullptr, std::move(sink_info),
std::move(client_request),
Can you add comments for the null things? e.g.

  std::move(context_provider), nullptr /* worker_context_provider */,
  gpu_memory_buffer_manager, nullptr /* shared_bitmap_manager */,

etc. That makes it easier to read the code.

[Saman Sami, 2017-05-29 17:26:35]

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

[commit-bot: I haz the power, 2017-05-29 17:26:51]

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-05-29 18:28:03]

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

[commit-bot: I haz the power, 2017-05-29 18:28:04]

Dry run: This issue passed the CQ dry run.

[Fady Samuel, 2017-05-30 13:05:39]

On 2017/05/29 15:23:54, Saman Sami wrote:
> On 2017/05/26 21:34:02, piman wrote:
> > I worry a little bit that we'll end up into a "fragile base class"
situation,
> > particularly if RendererCompositorFrameSink::SubmitCompositorFrame is a
> > completely separate implementation from
> > ClientCompositorFrameSink::SubmitCompositorFrame.
> > Assuming we can reland https://codereview.chromium.org/2899073006, is there
a
> > way we could have a single class, and "externalize" the logic around when to
> > recreate a local id, e.g. with a callback or a simple client interface
> > containing a virtual bool ShouldCreateNewLocalId(const cc::CompositorFrame&
> > frame), since that's the only difference left?
> > 
> >
>
https://codereview.chromium.org/2903853002/diff/140001/components/viz/client/...
> > File components/viz/client/client_compositor_frame_sink.cc (right):
> > 
> >
>
https://codereview.chromium.org/2903853002/diff/140001/components/viz/client/...
> > components/viz/client/client_compositor_frame_sink.cc:60:
> > DCHECK_CALLED_ON_VALID_THREAD(thread_checker_);
> > nit: duplicate of the above?
> > 
> >
>
https://codereview.chromium.org/2903853002/diff/140001/content/renderer/gpu/r...
> > File content/renderer/gpu/renderer_compositor_frame_sink.h (right):
> > 
> >
>
https://codereview.chromium.org/2903853002/diff/140001/content/renderer/gpu/r...
> > content/renderer/gpu/renderer_compositor_frame_sink.h:110:
> > cc::LocalSurfaceIdAllocator id_allocator_;
> > These duplicate (and hide) the ClientCompositorFrameSink ones. Could we
share?
> 
> I understand your concern. We are aiming for unification of these two classes,
> however I'm not entirely sure it's feasible. The swap message stuff will go
> away, but I can think of other stuff that will be added. I moved the decision
> about allocating a new LocalSurfaceId to a separate virtual method that the
> child can override and now RCFS::SubmitCompositorFrame calls to
> CCFS::SubmitCompositorFrame at some point which I assume solves the fragility
> issue to some extent? Could you take another look please?

What other stuff do you expect to be added? I feel like we can avoid adding
stuff by adding things to SwapPromise?

[Fady Samuel, 2017-05-30 13:07:13]

On 2017/05/30 13:05:39, Fady Samuel wrote:
> On 2017/05/29 15:23:54, Saman Sami wrote:
> > On 2017/05/26 21:34:02, piman wrote:
> > > I worry a little bit that we'll end up into a "fragile base class"
> situation,
> > > particularly if RendererCompositorFrameSink::SubmitCompositorFrame is a
> > > completely separate implementation from
> > > ClientCompositorFrameSink::SubmitCompositorFrame.
> > > Assuming we can reland https://codereview.chromium.org/2899073006, is
there
> a
> > > way we could have a single class, and "externalize" the logic around when
to
> > > recreate a local id, e.g. with a callback or a simple client interface
> > > containing a virtual bool ShouldCreateNewLocalId(const
cc::CompositorFrame&
> > > frame), since that's the only difference left?
> > > 
> > >
> >
>
https://codereview.chromium.org/2903853002/diff/140001/components/viz/client/...
> > > File components/viz/client/client_compositor_frame_sink.cc (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/2903853002/diff/140001/components/viz/client/...
> > > components/viz/client/client_compositor_frame_sink.cc:60:
> > > DCHECK_CALLED_ON_VALID_THREAD(thread_checker_);
> > > nit: duplicate of the above?
> > > 
> > >
> >
>
https://codereview.chromium.org/2903853002/diff/140001/content/renderer/gpu/r...
> > > File content/renderer/gpu/renderer_compositor_frame_sink.h (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/2903853002/diff/140001/content/renderer/gpu/r...
> > > content/renderer/gpu/renderer_compositor_frame_sink.h:110:
> > > cc::LocalSurfaceIdAllocator id_allocator_;
> > > These duplicate (and hide) the ClientCompositorFrameSink ones. Could we
> share?
> > 
> > I understand your concern. We are aiming for unification of these two
classes,
> > however I'm not entirely sure it's feasible. The swap message stuff will go
> > away, but I can think of other stuff that will be added. I moved the
decision
> > about allocating a new LocalSurfaceId to a separate virtual method that the
> > child can override and now RCFS::SubmitCompositorFrame calls to
> > CCFS::SubmitCompositorFrame at some point which I assume solves the
fragility
> > issue to some extent? Could you take another look please?
> 
> What other stuff do you expect to be added? I feel like we can avoid adding
> stuff by adding things to SwapPromise?

I should add that I believe  ShouldAllocateNewLocalSurfaceId will go away once
surface synchronization is turned on everywhere...*I think*.

[Saman Sami, 2017-05-30 14:26:40]

Two things that will be added off the top of my head:
1) Asking for LocalSurfaceId from the parent
2) Sending browser-related parts of CompositorFrameMetadata to the browser in a
separate IPC message. This could technically be a swap promise but it's weird
because we do it every swap.

[piman, 2017-05-30 16:37:08]

LGTM, this is better, but we should try very hard to unify the classes.
Implementation inheritance is fragile and oftentimes causes more problems than
it solves.

[Saman Sami, 2017-05-30 16:46:06]

The CQ bit was checked by samans@chromium.org

[Saman Sami, 2017-05-30 16:46:06]

The patchset sent to the CQ was uploaded after l-g-t-m from
fsamuel@chromium.org, sadrul@chromium.org
Link to the patchset: https://codereview.chromium.org/2903853002/#ps200001
(title: "Add comments")

[commit-bot: I haz the power, 2017-05-30 16:46:41]

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-05-30 16:51:28]

CQ is committing da patch.

Bot data: {"patchset_id": 200001, "attempt_start_ts": 1496162766178770,
"parent_rev": "a3410f5c72de0fecf8772dbeeee95514e57c4cb0", "commit_rev":
"69f7eaad72b5c7419e014f044df6c7a2df054b86"}

[commit-bot: I haz the power, 2017-05-30 16:51:36]

Description was changed from

==========
Make RendererCompositorFrameSink derive from ClientCompositorFrameSink

RendererCompositorFrameSink is pretty much a more specialized version
of ClientCompositorFrameSink for the renderer. By deriving from
ClientCompositorFrameSink, some code reuse is possible.

BUG=726485
TBR=sadrul@chromium.org
==========

to

==========
Make RendererCompositorFrameSink derive from ClientCompositorFrameSink

RendererCompositorFrameSink is pretty much a more specialized version
of ClientCompositorFrameSink for the renderer. By deriving from
ClientCompositorFrameSink, some code reuse is possible.

BUG=726485
TBR=sadrul@chromium.org

Review-Url: https://codereview.chromium.org/2903853002
Cr-Commit-Position: refs/heads/master@{#475563}
Committed:
https://chromium.googlesource.com/chromium/src/+/69f7eaad72b5c7419e014f044df6...
==========

[commit-bot: I haz the power, 2017-05-30 16:51:40]

Committed patchset #10 (id:200001) as
https://chromium.googlesource.com/chromium/src/+/69f7eaad72b5c7419e014f044df6...