Closed Bug 637901 Opened 9 years ago Closed 9 years ago

Video in youtube goes white

Categories

(Core :: Graphics, defect)

x86
macOS
defect
Not set

Tracking

()

VERIFIED FIXED
Tracking Status
blocking2.0 --- final+

People

(Reporter: armenzg, Assigned: mattwoodrow)

References

Details

(Keywords: regression, Whiteboard: [hardblocker])

Attachments

(2 files, 3 obsolete files)

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
This might be fixed by bug 636817?
blocking2.0: --- → ?
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
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?
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.
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.
And, looking at the page in Chrome, the related videos vanishing is a site bug.
None of us can reproduce the video going white.  We can reproduce content vanishing on the sites in Firefox and Chrome.
Attached video Screencast
video is not going white for me either.
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.
(In reply to comment #9)
> video is not going white for me either.

using 10.2.152.32
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
Also, the video *was* freezing near the end, but I updated to the latest nightly and that problem disappeared.
Flash version = 10.2.152.26
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
does upgrading to 10.2.152.32 make a difference any?
Hardblocking as some can repro.
blocking2.0: ? → final+
Whiteboard: [hardblocker]
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
So far I can't reproduce (using flash 10.2.152.26)...
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?
I have downgraded to 10.2.152.26, and I can still not reproduce this with acceleration enabled or disabled.
Crap. I had hoped this would be fixed by bug 636817, but I can still reproduce it with my up-to-date universal build.
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?
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.
Keywords: qawanted
I'm still using .26. I'll upgrade to .33 and try to reproduce.
Cool. I will try comment 24 in the meantime.
10.2.152.33 still disappears.
joe, does trunk default to acceleration on or off on your machine? On my machine it defaults to off (1 year old MBP).
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
Defaults to on. (So should yours, fwiw - I have the same hardware.)
Adapter Description 0x22600,0x20400
WebGL Renderer NVIDIA Corporation -- NVIDIA GeForce GT 330M OpenGL Engine -- 2.1 NVIDIA-1.6.26
Extensions: 

Better GReader
Mass Password Reset
Fox To Phone
Copy Link Text
Read It Later
Bugzilla Tweaks
Scriptish
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.
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.
Additional information in bug 637087, which is a dup.
Duplicate of this bug: 637087
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.
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.
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
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.
Got another crash, same stack as comment 39. Possibly unrelated. Filed as bug 638009.
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."
Set a conditional breakpoint on ImageContainerOGL::SetCurrentImage to find out?
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
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.
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...
Assignee: nobody → matt.woodrow+bugzilla
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.
Fixed a crash
Attachment #516197 - Attachment is obsolete: true
Attachment #516200 - Flags: review?(tnikkel)
Fixed missing braces
Attachment #516200 - Attachment is obsolete: true
Attachment #516200 - Flags: review?(tnikkel)
Attachment #516204 - Flags: review?(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.
Attachment #516204 - Flags: review?(tnikkel) → review+
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.
Updated docs.

Carrying forward r=tnikkel
Attachment #516204 - Attachment is obsolete: true
Attachment #516207 - Flags: review+
http://hg.mozilla.org/mozilla-central/rev/01037ab16a65
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
This should be fixed on tomorrow's nightly as 919f15d71153 was used for today's nightly.
Status: RESOLVED → UNCONFIRMED
Ever confirmed: false
Resolution: FIXED → ---
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Thank you Matt and Timothy for jumping on this and fixing it super quickly!
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
can I be Shaggy? Zoiks! *munches a scooby snack*
Duplicate of this bug: 638259
(In reply to comment #59)
> can I be Shaggy? Zoiks! *munches a scooby snack*

Ok. Who is Scooby?

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

seriously!? ;)
Just to follow up, I can't replicate this in today's nightly.  Huzzah!
as per comment #64
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.