627399 - Html5 video (ogg) blocks if hovered

Status: VERIFIED FIXED

(Core :: Graphics, defect)

Description

[pietro.brenna]

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0b10pre) Gecko/20110120 Firefox/4.0b10pre
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b10pre) Gecko/20110120 Firefox/4.0b10pre

An html5 ogg freezes the video component if hovered, while the bottom part (under the controls) continues playing. This happens either in embedded video and navigating directly to the video file. The top part continues showing video onmouseout. The audio plays correctly.

Processor: Intel Pentium processor SU4100
Graphics card: Intel GMA 4500M 
GPU Accelerated Windows: 0/2

No about:config graphics-related options changed.

Reproducible: Always

Steps to Reproduce:
1.Play video
2.Hover with cursor
Actual Results:  
Video freezes excepted the bottom part

Expected Results:  
Normal video playing

Comment 1

[David Humphrey (:humph)]

WFM in Mac 10.6 with trunk.

Comment 2

[Matthias Versen [:Matti]]

wfm with  Mozilla/5.0 (Windows NT 6.1; rv:2.0b10pre) Gecko/20110120 Firefox/4.0b10pre SeaMonkey/2.1b2pre

Comment 3

[Chris Pearce [:cpearce (Not reading bugmail)]]

I can't repro this on Windows, but I can repro it on Linux x64 in a VM (no hardware acceleration).

I can reproduce this if I repeatedly move the mouse over and then out of the video, so that the controls flash on and off.

This seems to be a regression introduced between
Mozilla/5.0 (X11; Linux x86_64; rv:2.0b10pre) Gecko/20110121 Firefox/4.0b10pre
and
Mozilla/5.0 (X11; Linux x86_64; rv:2.0b9pre) Gecko/20110101 Firefox/4.0b9pre

I will find a smaller regression range.

Comment 4

[Chris Pearce [:cpearce (Not reading bugmail)]]

Regression range is:
Mozilla/5.0 (X11; Linux x86_64; rv:2.0b10pre) Gecko/20110120 Firefox/4.0b10pre

Mozilla/5.0 (X11; Linux x86_64; rv:2.0b10pre) Gecko/20110119 Firefox/4.0b10pre

So it is a regression from a changeset in this range:

http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2011-01-19+03&enddate=2011-01-20+03

Comment 5

[Chris Pearce [:cpearce (Not reading bugmail)]]

This is a regression from the landing of:
http://hg.mozilla.org/mozilla-central/rev/a18080aa75d6
Robert O'Callahan — Bug 621601. Part 1: Change empty transaction API to EndEmptyTransaction. r=bas,tnikkel,a=joe

I also wonder if that changeset caused bug 627489.

Comment 6

[Bas Schouten (:bas.schouten)]

Attachment: Do not forget mTarget if a transaction is incomplete

We shouldn't be clearing state associated with the transaction if the transaction is incomplete.

Comment 7

[Bas Schouten (:bas.schouten)]

Attachment: Do not forget mTarget if a transaction is incomplete v2

Updated not to contain other unrelated stuff.

Comment 8

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Comment on attachment 505683 [details] [diff] [review]
Do not forget mTarget if a transaction is incomplete v2

This fixes the video issue for me.

  NS_ASSERTION(!aCallback || !mTransactionIncomplete,
               "If callback is not null, transaction must be complete");

I think we also want to add here, || mTarget == GetDefaultTarget().  Attempting on transient targets seems like bad news.

Looks good.

Comment 9

[Bas Schouten (:bas.schouten)]

http://hg.mozilla.org/mozilla-central/rev/b7ea3d9683ba

Comment 10

[Carsten Book [:Tomcat]]

verified fixed with the steps to reproduce from comment#0 and:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b10pre) Gecko/20100101 Firefox/4.0b10pre ID:20110121115232 - Firefox Debug Build

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b10pre) Gecko/20100101 Firefox/4.0b10pre ID:20110121110747 Opt Build

Mozilla/5.0 (Windows NT 6.1; rv:2.0b10pre) Gecko/20100101 Firefox/4.0b10pre ID:20110121044643 Debug Build

Mozilla/5.0 (Windows NT 6.1; rv:2.0b10pre) Gecko/20100101 Firefox/4.0b10pre ID:20110121015814  Opt build

Mozilla/5.0 (X11; Linux i686; rv:2.0b10pre) Gecko/20110120 Firefox/4.0b10pre ID:20110121034444

Comment 12

[Jeff Muizelaar [:jrmuizel]]

Any chance we can get a test that would have shown this?

Comment 13

[Timothy Nikkel (:tnikkel)]

I don't think anything with drawWindow would work for a test, the code path affected is for drawing to the screen and isn't taken for drawWindow.