Closed Bug 1051636 Opened 5 years ago Closed 5 years ago

Fullscreen video has blank menu bar at top of screen on Windows

Categories

(Core :: Layout, defect)

x86_64
Windows 8.1
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla35
Tracking Status
firefox34 + verified
firefox35 --- verified
b2g-v2.1 --- verified
b2g-v2.2 --- verified

People

(Reporter: cpearce, Assigned: roc)

References

Details

(Keywords: regression)

Attachments

(3 files)

When you enter fullscreen on a video on Windows 8.1, you see a blank window/titlebar at the top of the screen, and a window frame around the video. See attached screenshot.

I tested in my Linux VM, and this did not happen, so I suspect this is Windows only.

STR:
1. Open http://people.mozilla.org/~cpearce/video/avatar.webm
2. Click the "fullscreen" button on the video controls.
3. Observe blank window titlebar and frame around the window.

It's as if the top-level widget/window isn't going fullscreen.

This is a regression.

Last good revision: 2014-07-20-03-02-03
First bad revision: 2014-07-21-03-02-05

Range:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0894d2cdb16d&tochange=e743fd8c57ed
This is a regression from one of the parts of bug 1022612. Am narrowing the regression range further now...
Blocks: 1022612
Flags: needinfo?(roc)
This regressed in d1df8efc0422.
(moving this to core::layout per comment #1 and bug 1022612)
Component: General → Layout
Keywords: regression
Product: Firefox → Core
[Tracking Requested - why for this release]:
We should not ship a regression in fullscreen behaviour...
Tracking this but can we also get an assignee?
I don't see this on Windows 7 on trunk. So I'll probably need some help from Chris on Windows 8.1 when he gets back.
Assignee: nobody → roc
Status: NEW → ASSIGNED
Flags: needinfo?(roc)
The problem seems to be that something is drawing the window frame when it shouldn't.

The generated layer tree looks fine when we dump it from layout. The chrome document gets a 1px-high layer at the top of the screen, and the content document gets a ThebesLayer filling the screen and an ImageLayer for the video. Nothing in the two latter documents corresponds to theme drawing or anything else that could draw the window frame.

I'm not sure what the problem is. Bas, Jim, do you know how that window frame gets drawn?
Flags: needinfo?(jmathies)
Flags: needinfo?(bas)
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #7)
> The problem seems to be that something is drawing the window frame when it
> shouldn't.
> 
> The generated layer tree looks fine when we dump it from layout. The chrome
> document gets a 1px-high layer at the top of the screen, and the content
> document gets a ThebesLayer filling the screen and an ImageLayer for the
> video. Nothing in the two latter documents corresponds to theme drawing or
> anything else that could draw the window frame.
> 
> I'm not sure what the problem is. Bas, Jim, do you know how that window
> frame gets drawn?

Windows 8 could be doing this, maybe this has something to do with window styles.

I noticed the html5 fullscreen window (same window type) for youtube doesn't have the problem, I think because youtube paints the entire window. In the avatar video chris posted, we only paint the wide screen strip.
Flags: needinfo?(jmathies)
Yeah it looks like the bug is that the ThebesLayer that's supposed to be covering the window isn't drawn by the compositor at all! Only the ImageLayer is drawn.
I found the bug. The problem is that nsVideoFrame::BuildLayer marks the ImageLayer as opaque but FrameLayerBuilder computes a visible region for the layer that extends outside the actual image, so layout lies; the opaque flag should only be used when a layer is opaque everywhere in its visible region.

The computed visible region for the ImageLayer is actually the entire window, so the compositor culls out the ThebesLayer that contains the window contents that need to be drawn.
Flags: needinfo?(bas)
Attachment #8489803 - Flags: review?(tnikkel) → review+
Comment on attachment 8489803 [details] [diff] [review]
fix

Approval Request Comment
[Feature/regressing bug #]: 1022612
[User impact if declined]: Bad visual regression for fullscreen video on Windows
[Describe test coverage new/current, TBPL]: nothing specific but lots of tests test this code
[Risks and why]: risk is low. we're just disabling an optimization that doesn't do much anyway. The regression has to be fixed.
[String/UUID change made/needed]: none.
Attachment #8489803 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/66bad3def025
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
Comment on attachment 8489803 [details] [diff] [review]
fix

Aurora+
Attachment #8489803 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Note that this got backed out of aurora in bug 1073252 for b2g only.
Flags: qe-verify+
Reproduced using Nightly 2014-08-10.
Verified as fixed on Firefox 34 beta 1 (20141014134955).
Blocks: 1088452
I was able to reproduce this issue on Firefox 34.0a1 (2014-08-10) using Windows 8.1 x64.

Verified fixed on Latest Firefox 35.0a2 (2014-11-24) using Windows 8.1 x64.
Attached video Verify_Video_Flame.MP4
This issue has been verified successfully on Flame 2.1 & 2.2.
See attachment: Verify_Video_Flame.MP4
Reproducing rate: 0/20

Flame v2.1 version:
Gaia-Rev        db2e84860f5a7cc334464618c6ea9e92ff82e9dd
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/211eae88f119
Build-ID        20141126001202
Version         34.0

Flame v2.2 version:
Gaia-Rev        41b7be7c67167f367c3c4982ff08651d55455373
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/ff4a63d66806
Build-ID        20141126160201
Version         36.0a1
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.