As per https://bugzilla.mozilla.org/show_bug.cgi?id=546700#c16 and https://bugzilla.mozilla.org/show_bug.cgi?id=546700#c17, there seems to be an issue with playing a couple of videos. http://www.0xdeadbeef.com/~blizzard/weblog-videos/2010-02-14-difference-engine/VID00212.ogv http://media.xiph.org/basilgohar/timelapse/work-clouds-vga-30fps-q7.ogv Both buffer and play as expected, but the video pauses when the mouse cursor is not over the video and resumes when the mouse cursor is on top of the video. According to Matthew, this could be a variation of bug 633261.

I tested on Windows 7. I would've thought I was using D3D10 given the hardware and drivers, but about:support is reporting D3D9: Adapter Description AMD Radeon HD 6900 Series Vendor ID 1002 Device ID 6719 Adapter RAM 2048 Adapter Drivers aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64 Driver Version 8.821.0.0 Driver Date 1-26-2011 Direct2D Enabled false DirectWrite Enabled false (6.1.7601.17514, font cache 18.89 MB) WebGL Renderer Google Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.541) GPU Accelerated Windows 1/1 Direct3D 9 The bug doesn't manifest if layers.acceleration.disabled set to true. Anthony, can you please post your config as well?

My about:support page is nowhere near as detailed as yours: Adapter Description 0x22600,0x20400 Vendor ID 0000 Device ID 0000 Adapter RAM Adapter Drivers Driver Version Driver Date Direct2D Enabled false DirectWrite Enabled false WebGL Renderer NVIDIA Corporation -- NVIDIA GeForce 320M OpenGL Engine -- 2.1 NVIDIA-1.6.26 GPU Accelerated Windows1/1 OpenGL FWIW, I'm using a MacBookPro7,1 (Early 2010 - Macbook Pro 13"). Here is the information about my videocard from About This Mac: NVIDIA GeForce 320M: Chipset Model: NVIDIA GeForce 320M Type: GPU Bus: PCI VRAM (Total): 256 MB Vendor: NVIDIA (0x10de) Device ID: 0x08a0 Revision ID: 0x00a2 ROM Revision: 3533 Displays: Display Connector: Status: No Display Connected W2353: Resolution: 1920 x 1080 @ 60 Hz Pixel Depth: 32-Bit Color (ARGB8888) Main Display: Yes Mirror: Off Online: Yes Rotation: Supported

This is a dupe of bug 635445. FWIW this seems to happen with any accelerated layers option (D3D9/D3D10/OGL).

(In reply to comment #4) > > *** This bug has been marked as a duplicate of bug 635445 *** This bug has more detail than bug 635445. We might want to dupe the other way.

(In reply to comment #1) > I tested on Windows 7. I would've thought I was using D3D10 given the hardware > and drivers, but about:support is reporting D3D9: This was caused by gfx.direct2d.enabled being set to false. It was set when I disabled HW accel in the prefs pane, and then missed when re-enabled because I did that via about:config and only reset layers.acceleration.disabled.

unsetting blocker request because we have that set in the duped to bug.

Maybe bug 626602 or something nearby caused this?

I can only reproduce this bug if I open the video in a tab, close the tab, and then undo-close-tab. Otherwise I cannot reproduce this bug. Anthony: 1. Do you only see this bug on videos which are either opened due to the browser re-opening their tabs on startup, or when you undo-close-tab? 2. If you close all tabs, restart your browser, then open a new tab and load the video in the new tab, do you still see the problem?

(In reply to comment #10) > I can only reproduce this bug if I open the video in a tab, close the tab, and > then undo-close-tab. Otherwise I cannot reproduce this bug. > > Anthony: > 1. Do you only see this bug on videos which are either opened due to the > browser re-opening their tabs on startup, or when you undo-close-tab? > 2. If you close all tabs, restart your browser, then open a new tab and load > the video in the new tab, do you still see the problem? I dont need to do undo close tab or anything like that; simply open the URL and it works as I described.

Ok, I think I'm reproducing a variant of bug 633261 then, not this bug. It would also be good if someone who can reproduce this bug could find a regression window.

At first I was able to reproduce this bug in a nightly instance with 4 windows open and about 10 tabs in each window. Then I restarted without a sessionstore.js and I was not able to reproduce it. After restarting with the old sessionstore.js (so, 4 windows and about 10 tabs in each), I am not able to reproduce it still.

Hmmm, it seems that it shows up again a few minutes after Firefox has been running. However, if I tried loading the file locally, the problem did not show up whereas it did when buffering (using http://www.0xdeadbeef.com/~blizzard/weblog-videos/2010-02-14-difference-engine/VID00212.ogv).

With OpenGL force-enabled on x86_64 Linux, the regression window is: Last good nightly: 2011-02-02-03 (http://hg.mozilla.org/mozilla-central/rev/1c2d53a2dcfb) First bad nightly: 2011-02-03-09 (http://hg.mozilla.org/mozilla-central/rev/094a7967e171) http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2011-02-01+21%3A31&enddate=2011-02-03+03%3A57 So, it looks like this reduces to the change as bug 633261 for Linux and OS X. I haven't done a backout to verify, though. Windows is probably doing to have a different regression window.

Maybe bug 627084?

Windows 7 x86, D3D10 regression window: Last good nightly: 2011-01-19-03 (http://hg.mozilla.org/mozilla-central/rev/e807269acaa3) Last bad nightly: 2011-01-20-03 (http://hg.mozilla.org/mozilla-central/rev/efbf1fa4c70e)

So http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e807269acaa3&tochange=efbf1fa4c70e Probably empty transactions for D3D10 then.

So it looks like LayerManagerForDocumentInternal is failing to find the correct layer manager (no root frame) and instead returning a temporary BasicLayerManager. Because of this nsHTMLMediaElement::GetImageContainer always returns an image container backed by basic layers. In a normal transaction we call BuildLayer which detect the different container types, creates a temporary OGL container and manually copies the image data across. This is slow (yuv->rgb conversion on the cpu) but still works. In an empty transaction, the media decoder pushes the new image into the basic layer container owned by nsHTMLMediaElement, and layers renders the temporary opengl container from the last full frame. No BuildLayer, no manual copying, and no new frame drawn. This is probably the cause of bug 633261 too.

Patch written by tn! This fixes the problem for me :)

Do we need LayerManagerForDocument to always return non-null? Should we keep the BasicManager fall back in this function?

I'll make the patch review-ready tomorrow.

I can't watch the video on this page: http://www.concur.com/en-us/features/small-business-expense unless I click somewhere in the popup window. Even then, I can't get the video controls to show. Could this be caused by the issue being discussed here? If not, I'll file a new bug. Here is the selection source: <div class="description"> <a href="#"><span class=" ">Concur Breeze on a smartphone</span></a><div class="desc-body"><p>You can take it with you - expense reporting hits the smartphone</p> </div> <form action=""> <input name="hasForm" value="" type="hidden"> <input name="videoUrl" value="http://assets.concur.com/videos/concur-breeze-mobile.mov" type="hidden"> <input name="campaignId" value="70160000000X5CYAA0" type="hidden"> </form> <a class="ShareURL" href="http://www.concur.com//resource-center?modalNID=988&amp;resourceType=video"></a> </div> I have hardware acceleration enabled on my MacBook with Graphics Card: Chipset Model: NVIDIA GeForce 320M Type: GPU Bus: PCI VRAM (Total): 256 MB Build identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b13pre) Gecko/20110228 Firefox/4.0b13pre From about:buildconfig: Configure arguments --target=x86_64-apple-darwin10.2.0 --with-macos-sdk=/Developer/SDKs/MacOSX10.6.sdk --enable-application=browser --enable-update-channel=nightly --enable-update-packaging --enable-tests --enable-codesighs --disable-install-strip --enable-debug-symbols=-gdwarf-2

It could be, do you want to check to see if it is fixed when the patch in this bug lands?

Comment on attachment 515759 [details] [diff] [review] patch Hmm, I thought I already reviewed this.

Pushed: http://hg.mozilla.org/mozilla-central/rev/eccac62d0092

This patch apparently caused a test failure on its first run http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1298998168.1298999410.2866.gz s: talos-r3-fed-047 8607 ERROR TEST-UNEXPECTED-FAIL | chrome://mochitests/content/chrome/toolkit/content/tests/chrome/test_titlebar.xul | paneltop move popup horizontal - got -224, expected 15 Bug 543760 - Intermittent failures in test_titlebar.xul Bug 587051 - Intermittent Linux64 Mdoth test_titlebar.xul timeout 8608 ERROR TEST-UNEXPECTED-FAIL | chrome://mochitests/content/chrome/toolkit/content/tests/chrome/test_titlebar.xul | paneltop move popup vertical - got -240, expected 52 8609 ERROR TEST-UNEXPECTED-FAIL | chrome://mochitests/content/chrome/toolkit/content/tests/chrome/test_titlebar.xul | paneltop horizontal after mouse on button - got -224, expected 15 8610 ERROR TEST-UNEXPECTED-FAIL | chrome://mochitests/content/chrome/toolkit/content/tests/chrome/test_titlebar.xul | paneltop vertical after mouse on button - got -240, expected 52 PROCESS-CRASH | Main app process exited normally | application crashed (minidump found) Thread 0 (crashed) but on the second run, there wasn't a failure. Should this be backed out?

I will verify that the issue on concur.com has been fixed by the patch for this bug. Looks like it will be available in tomorrow's nightly.

(In reply to comment #28) > This patch apparently caused a test failure on its first run > > http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1298998168.1298999410.2866.gz > s: talos-r3-fed-047 > 8607 ERROR TEST-UNEXPECTED-FAIL | > chrome://mochitests/content/chrome/toolkit/content/tests/chrome/test_titlebar.xul > | paneltop move popup horizontal - got -224, expected 15 > Bug 543760 - Intermittent failures in test_titlebar.xul > Bug 587051 - Intermittent Linux64 Mdoth test_titlebar.xul timeout 8608 ERROR > TEST-UNEXPECTED-FAIL | > chrome://mochitests/content/chrome/toolkit/content/tests/chrome/test_titlebar.xul > | paneltop move popup vertical - got -240, expected 52 > 8609 ERROR TEST-UNEXPECTED-FAIL | > chrome://mochitests/content/chrome/toolkit/content/tests/chrome/test_titlebar.xul > | paneltop horizontal after mouse on button - got -224, expected 15 > 8610 ERROR TEST-UNEXPECTED-FAIL | > chrome://mochitests/content/chrome/toolkit/content/tests/chrome/test_titlebar.xul > | paneltop vertical after mouse on button - got -240, expected 52 > PROCESS-CRASH | Main app process exited normally | application crashed > (minidump found) > Thread 0 (crashed) > > but on the second run, there wasn't a failure. Should this be backed out? I filed bug 637806.

Thanks everyone. I'll check tomorrow's nightly to verify this fix.

Both videos now play fine for me using Firefox 4.0b13pre 20110302 -- marking verified.

Verified with the video on concur.com. Thanks for fixing this bug.