[videofling] Page not rendered after leaving ECA on ICS/JB MR0

Reset surface format in ContentViewRenderView. This prevents issues with the tab not rendering if an activity starts over the FS video view.

BUG=356663
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=263050

[May, 2014-04-10 12:34:34]

Tests pass, whoop! Was afraid I'd end up breaking something with this change.

[Sami, 2014-04-10 13:49:49]

lgtm, thanks for the fix!

[May, 2014-04-10 17:22:04]

The CQ bit was checked by maybelle@chromium.org

[commit-bot: I haz the power, 2014-04-10 17:23:44]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/maybelle@chromium.org/230223008/1

[commit-bot: I haz the power, 2014-04-10 19:33:30]

Change committed as 263050

[no sievers, 2014-04-10 20:42:34]

On 2014/04/10 19:33:30, I haz the power (commit-bot) wrote:
> Change committed as 263050

Huh?

The surface_format gets reset in SurfaceDestroyed. Why is this necessary?
Also see comment #27 in bug 356663

[May, 2014-04-11 14:44:49]

On 2014/04/10 20:42:34, sievers wrote:
> On 2014/04/10 19:33:30, I haz the power (commit-bot) wrote:
> > Change committed as 263050
> 
> Huh?
> 
> The surface_format gets reset in SurfaceDestroyed. Why is this necessary?
> Also see comment #27 in bug 356663

A surface is created when going back from the FS activity to Chrome (triggered
by window visibility changed). It's using the same surface_format variable as
the surface that was created by CompositorView.setOverlayVideoMode(false).

[no sievers, 2014-04-11 16:06:08]

On 2014/04/11 14:44:49, may wrote:
> On 2014/04/10 20:42:34, sievers wrote:
> > On 2014/04/10 19:33:30, I haz the power (commit-bot) wrote:
> > > Change committed as 263050
> > 
> > Huh?
> > 
> > The surface_format gets reset in SurfaceDestroyed. Why is this necessary?
> > Also see comment #27 in bug 356663
> 
> A surface is created when going back from the FS activity to Chrome (triggered
> by window visibility changed). It's using the same surface_format variable as
> the surface that was created by CompositorView.setOverlayVideoMode(false).

We have to synchronously tear down the old surface (SurfaceDestroyed), are we
doing that?

[May, 2014-04-11 16:13:26]

On 2014/04/11 16:06:08, sievers wrote:
> On 2014/04/11 14:44:49, may wrote:
> > On 2014/04/10 20:42:34, sievers wrote:
> > > On 2014/04/10 19:33:30, I haz the power (commit-bot) wrote:
> > > > Change committed as 263050
> > > 
> > > Huh?
> > > 
> > > The surface_format gets reset in SurfaceDestroyed. Why is this necessary?
> > > Also see comment #27 in bug 356663
> > 
> > A surface is created when going back from the FS activity to Chrome
(triggered
> > by window visibility changed). It's using the same surface_format variable
as
> > the surface that was created by CompositorView.setOverlayVideoMode(false).
> 
> We have to synchronously tear down the old surface (SurfaceDestroyed), are we
> doing that?

Not the ContentVideoView surface, no. According to Min, that destroy needs to be
posted. I attempted to make that synchronous, but I would encounter a NPE
(crbug.com/360050).

[qinmin, 2014-04-11 16:28:08]

On 2014/04/11 16:13:26, may wrote:
> On 2014/04/11 16:06:08, sievers wrote:
> > On 2014/04/11 14:44:49, may wrote:
> > > On 2014/04/10 20:42:34, sievers wrote:
> > > > On 2014/04/10 19:33:30, I haz the power (commit-bot) wrote:
> > > > > Change committed as 263050
> > > > 
> > > > Huh?
> > > > 
> > > > The surface_format gets reset in SurfaceDestroyed. Why is this
necessary?
> > > > Also see comment #27 in bug 356663
> > > 
> > > A surface is created when going back from the FS activity to Chrome
> (triggered
> > > by window visibility changed). It's using the same surface_format variable
> as
> > > the surface that was created by CompositorView.setOverlayVideoMode(false).
> > 
> > We have to synchronously tear down the old surface (SurfaceDestroyed), are
we
> > doing that?
> 
> Not the ContentVideoView surface, no. According to Min, that destroy needs to
be
> posted. I attempted to make that synchronous, but I would encounter a NPE
> (crbug.com/360050).

That issue is about the fact that we cannot call removeview(surfaceView) inside
SurfaceDestroyed().
And the issue here is that we don't see a surfaceDestroyed() before
SurfaceCreated(). So it is a separate issue.