Closed Bug 1051636 Opened 5 years ago Closed 5 years ago
Fullscreen video has blank menu bar at top of screen on Windows
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...
This regressed in d1df8efc0422.
(moving this to core::layout per comment #1 and bug 1022612)
Component: General → Layout
Product: Firefox → Core
[Tracking Requested - why for this release]: We should not ship a regression in fullscreen behaviour...
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
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?
(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.
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.
5 years ago
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?
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.
Reproduced using Nightly 2014-08-10. Verified as fixed on Firefox 34 beta 1 (20141014134955).
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.
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
You need to log in before you can comment on or make changes to this bug.