637901 - Video in youtube goes white

Status: VERIFIED FIXED

(Core :: Graphics, defect)

Description

[Armen [:armenzg]]

Reproducible: quite frequently
1. Load any video on youtube. (e.g. http://www.youtube.com/watch?v=VWA4yJDqT_Y&feature=feedu)
2. Stop moving the mouse
3. At some point the video will go white

Workaround:
- as soon as I move the mouse the video is re-drawn

Build identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b13pre) Gecko/20110301 Firefox/4.0b13pre

Comment 1

[Joe Drew (not getting mail)]

This might be fixed by bug 636817?

Comment 2

[Joe Drew (not getting mail)]

The plugin actually goes entirely transparent - if you visit the Old Spice channel, for example, you can see the image behind the plugin when it disappears.

http://www.youtube.com/user/OldSpice?blend=2&ob=1#p/c/3925D55293FF84A1/0/oi9nTdN7x20

Comment 3

[Damon Sicore (:damons)]

I don't see the video go white.  Video seems fine.  BUT, if you reload the page the list of related videos disappears.  Could be a website bug.  Boris, what do you think?

Comment 4

[Christopher Blizzard (:blizzard)]

When I click the link into a new tab, the content and video are fine.  If I then reload in that tab, I lose the list of videos on the right.  But the cursor feedback over the content is missing too which makes me think it's a content/layout problem or a website bug, not a drawing problem.

Comment 5

[Joe Drew (not getting mail)]

There's no way this is a website bug. One thing I seem to have noticed: you have to leave the mouse pointer over the video. (This probably changes how the YouTube Flash applet operates.)

Also, make sure you haven't opted in to the html5 youtube beta - http://www.youtube.com/html5.

Comment 6

[Damon Sicore (:damons)]

And, looking at the page in Chrome, the related videos vanishing is a site bug.

Comment 7

[Christopher Blizzard (:blizzard)]

None of us can reproduce the video going white.  We can reproduce content vanishing on the sites in Firefox and Chrome.

Comment 8

[Joe Drew (not getting mail)]

Attachment: Screencast

Comment 9

[mattburles]

video is not going white for me either.

Comment 10

[Christopher Blizzard (:blizzard)]

Joe, what's your flash version?  agal can reproduce rendering problems on his mac with 64 bit builds, but he's got a 10.3 flash developer release.

Comment 11

[mattburles]

(In reply to comment #9)
> video is not going white for me either.

using 10.2.152.32

Comment 12

[Damon Sicore (:damons)]

Probably doesn't help, but tested with both accel on and off, and works fine
for me.  My config:

   Flash Version: 10.2.152.26

  Chipset Model:    NVIDIA GeForce 320M
  Type:    GPU
  Bus:    PCI
  VRAM (Total):    256 MB
  Vendor:    NVIDIA (0x10de)
  Device ID:    0x08a2
  Revision ID:    0x00a2
  ROM Revision:    3571

11' MB Air

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b13pre) Gecko/20110301 Firefox/4.0b13pre

Comment 13

[Damon Sicore (:damons)]

Also, the video *was* freezing near the end, but I updated to the latest nightly and that problem disappeared.

Comment 14

[Joe Drew (not getting mail)]

Flash version = 10.2.152.26

Comment 15

[Armen [:armenzg]]

It does go white for me.

Application Basics
    File: Flash Player.plugin
    Version: 10.2.152.26
    Shockwave Flash 10.2 r152

  Graphics
Adapter Description 0x22600,0x20400
Vendor ID        0000
Device ID        0000
WebGL Renderer        NVIDIA Corporation -- NVIDIA GeForce 9400M OpenGL Engine -- 2.1 NVIDIA-1.6.26
GPU Accelerated Windows        1/1 OpenGL

Comment 16

[mattburles]

does upgrading to 10.2.152.32 make a difference any?

Comment 17

[Damon Sicore (:damons)]

Hardblocking as some can repro.

Comment 18

[Andreas Gal :gal]

I cannot reproduce this with the latest 10.2.152. Everything works fine with a nightly.

Adapter Description0x22600,0x20400Vendor ID0000Device ID0000Adapter RAMAdapter DriversDriver VersionDriver DateDirect2D EnabledfalseDirectWrite EnabledfalseWebGL RendererNVIDIA Corporation -- NVIDIA GeForce GT 330M OpenGL Engine -- 2.1 NVIDIA-1.6.26GPU Accelerated Windows1/1 OpenGL

    File: Flash Player.plugin
    Version: 10.2.152.33
    Shockwave Flash 10.2 r152

Comment 19

[Boris Zbarsky [:bzbarsky]]

So far I can't reproduce (using flash 10.2.152.26)...

Comment 20

[Joe Drew (not getting mail)]

Armen, can you reproduce using a tinderbox build like ftp://ftp.mozilla.org/pub/firefox/tinderbox-builds/mozilla-central-macosx64/1299030248/firefox-4.0b13pre.en-US.mac.dmg - or if you get this tomorrow, the nightly?

Comment 21

[Andreas Gal :gal]

I have downgraded to 10.2.152.26, and I can still not reproduce this with acceleration enabled or disabled.

Comment 22

[Joe Drew (not getting mail)]

Crap. I had hoped this would be fixed by bug 636817, but I can still reproduce it with my up-to-date universal build.

Comment 23

[Andreas Gal :gal]

joe, is that with .26 or .33?

I tried the 64-bit build you linked with .26 and I cannot reproduce this (my previous attempts were using 32-bit). Any additional hints for STR?

Comment 24

[Joe Drew (not getting mail)]

I can frequently get this to reproduce by doing the following:
1. Load the Old Spice url I linked above.
2. Let the video play a while; until about 15s.
3. Click on the video to make it pause.
4. Seek to the beginning of the video using the red slider.
5. Click on the video again to start it playing.
6. Don't touch anything; let it play with absolutely no user input. The video can disappear anywhere from 2 to 20 s later, with probably 75% probability.

Comment 25

[Joe Drew (not getting mail)]

I'm still using .26. I'll upgrade to .33 and try to reproduce.

Comment 26

[Andreas Gal :gal]

Cool. I will try comment 24 in the meantime.

Comment 27

[Joe Drew (not getting mail)]

10.2.152.33 still disappears.

Comment 28

[Andreas Gal :gal]

joe, does trunk default to acceleration on or off on your machine? On my machine it defaults to off (1 year old MBP).

Comment 29

[Andreas Gal :gal]

I can't reproduce with the STR above either with the default setting (off) or by forcing layers on using about:config. We should compare hardware:

NVIDIA Corporation -- NVIDIA GeForce GT 330M OpenGL Engine -- 2.1 NVIDIA-1.6.26

Comment 30

[Joe Drew (not getting mail)]

Defaults to on. (So should yours, fwiw - I have the same hardware.)

Comment 31

[Joe Drew (not getting mail)]

Adapter Description 0x22600,0x20400
WebGL Renderer NVIDIA Corporation -- NVIDIA GeForce GT 330M OpenGL Engine -- 2.1 NVIDIA-1.6.26

Comment 32

[Joe Drew (not getting mail)]

Extensions: 

Better GReader
Mass Password Reset
Fox To Phone
Copy Link Text
Read It Later
Bugzilla Tweaks
Scriptish

Comment 33

[Andreas Gal :gal]

jag and damons couldn't reproduce this either.

joe and I are using essentially identical hardware. He is reproducing this on a dirty profile and has not been able to reproduce this on a clear profile yet.

joe disabled all add-ons, that didn't help.

Comment 34

[Joe Drew (not getting mail)]

It looks like you have to have a persona applied to see these problems. Also potentially some app tabs, but that part is not confirmed yet.

Comment 35

[Andreas Gal :gal]

Additional information in bug 637087, which is a dup.

Comment 37

[Andreas Gal :gal]

dria says that this only happens with a persona installed, and doesn't happen with the default persona. I saw this bug briefly with a persona installed, and joe seems to support this observation as well.

Comment 38

[Andreas Gal :gal]

joe was unable to reproduce this with hardware acceleration disabled.

personas do seem to change the layer tree a bit, so there is a good chance that this is layers-related.

Comment 39

[Andreas Gal :gal]

I was following dria's suggestion to try closing and opening the add-on bar to trigger this and got this flash crash:

https://crash-stats.mozilla.com/report/index/bp-c6d107a4-c482-4178-ba9c-e65ce2110301

Comment 40

[Deb Richardson [:dria] (plz NEEDINFO)]

I managed to reproduce this on a clean profile on today's nightly with this
Persona:
  https://www.getpersonas.com/en-US/persona/370177

Watching this video:
  http://www.penny-arcade.com/patv/pa-the-series/214/

The video would sporadically blank when I closed the add-on bar.  Was fine on
open, but would blank on close every 2-3 times I tried it.

The video would unblank when I:
* switched to another tab and back
* focused on another app 
* moused over other tabs so they would highlight

Going to see if I can find a regression range now.

Comment 41

[Andreas Gal :gal]

Got another crash, same stack as comment 39. Possibly unrelated. Filed as bug 638009.

Comment 42

[Joe Drew (not getting mail)]

On a hunch, Matt Woodrow got me to turn http://mxr.mozilla.org/mozilla-central/source/gfx/layers/opengl/ImageLayerOGL.cpp#397 into an abort, and lo and behold, we hit it. The question is "why are we getting a null Image."

Comment 43

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Set a conditional breakpoint on ImageContainerOGL::SetCurrentImage to find out?

Comment 44

[Joe Drew (not getting mail)]

Regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1da3405c74fd&tochange=f8279991d58f

Comment 45

[Joe Drew (not getting mail)]

nthomas says http://www.dwight.co.nz/wdlv5_04.swf?wdlconfig.xml triggers it a lot.

<mattwoodrow> same as suggested, persona, nthomas|away's flash video
<mattwoodrow> and flick tabs a few times
<mattwoodrow> gal: Switch back and forth a few times

Comment 46

[Matt Woodrow (:mattwoodrow)]

Debugging with a build before bug 636817 landed, and it appears I'm hitting the exact same bug. Rebuilding with tip now to see if I can still reproduce and what changes.

nsObjectFrame::GetImageContainer is being called with aManager = 0x0. This uses nsContentUtils::LayerManagerForDocument to find a layer manager, and creates a BasicLayers one.

Because this of a different type to our normal manager (OpenGL), we discard the cached image container (the one that is set on the ImageLayer) and set it's current image to nsnull.

In a normal transaction, BuildLayer would fix this for us, but in an empty transaction we get to the rendering phase still with the old container (and no image) set on the layer. As expected, ImageLayerOGL bails out with no image and nothing gets drawn.

Moving the mouse etc triggers invalidation and a full transaction which fixes this broken state.

Comment 47

[Andreas Gal :gal]

dria bisected this down to the following regression range:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d39a263d7f14&tochange=b8194445b364

Comment 48

[Johnny Stenback (:jst)]

This needs an owner. Seems Matt has done the most digging so far, Matt, can you own this one? If not, please speak up, we're running low on time here...

Comment 49

[Matt Woodrow (:mattwoodrow)]

Attachment: Don't trash our cached ImageContainer unless we have a retained layer manager

So the reason this bug continues to happen is with personas we render the title bar with a temporary layer manager. This changes our cached ImageContainer to a BasicLayers one, and removes the image from the old container.

After this we can still trigger an empty transaction using the old (empty) image container.

This patch makes it so we only cache when an ImageContainer is created for a retained layer manager.

Comment 50

[Matt Woodrow (:mattwoodrow)]

Attachment: Don't trash our cached ImageContainer unless we have a retained layer manager v2

Fixed a crash

Comment 51

[Matt Woodrow (:mattwoodrow)]

Attachment: Don't trash our cached ImageContainer unless we have a retained layer manager v3

Fixed missing braces

Comment 52

[Timothy Nikkel (:tnikkel)]

Comment on attachment 516204 [details] [diff] [review]
Don't trash our cached ImageContainer unless we have a retained layer manager v3

+++ b/content/base/public/nsContentUtils.h
    * If one can't be found, a BasicLayerManager is created and returned.
+  LayerManagerForDocument(nsIDocument *aDoc, bool *aAllowRetaining = nsnull);

I made that comment false, can you remove it? Same for PersistentLayerManagerForDocument. And document the aAllowRetaining parameter.

Comment 53

[Timothy Nikkel (:tnikkel)]

We should also look into canvas and video's use of (Persistent)LayerManagerForDocument to make sure they aren't vulnerable to something like this at some point.

Comment 54

[Matt Woodrow (:mattwoodrow)]

Attachment: Don't trash our cached ImageContainer unless we have a retained layer manager v4

Updated docs.

Carrying forward r=tnikkel

Comment 55

[Matt Woodrow (:mattwoodrow)]

http://hg.mozilla.org/mozilla-central/rev/01037ab16a65

Comment 56

[Armen [:armenzg]]

This should be fixed on tomorrow's nightly as 919f15d71153 was used for today's nightly.

Comment 57

[Johnny Stenback (:jst)]

Thank you Matt and Timothy for jumping on this and fixing it super quickly!

Comment 58

[Brendan Eich [:brendan]]

Yeah, awesome teamwork -- like Mystery Inc. (Matt is Fred, dria is Velma [sorry, glasses-based typecasting], not sure who Shaggy is though... we have multiple candidates...).

"I would have gotten away with it if it weren't for those meddling kids!"

/be

Comment 59

[Rob Campbell [:rc] (:robcee)]

can I be Shaggy? Zoiks! *munches a scooby snack*

Comment 61

[Brendan Eich [:brendan]]

(In reply to comment #59)
> can I be Shaggy? Zoiks! *munches a scooby snack*

Ok. Who is Scooby?

/be

Comment 62

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

this joke is done

Comment 63

[Joe Drew (not getting mail)]

(In reply to comment #61)
> (In reply to comment #59)
> > can I be Shaggy? Zoiks! *munches a scooby snack*
> 
> Ok. Who is Scooby?

seriously!? ;)

Comment 64

[Deb Richardson [:dria] (plz NEEDINFO)]

Just to follow up, I can't replicate this in today's nightly.  Huzzah!

Comment 65

[Rob Campbell [:rc] (:robcee)]

as per comment #64