This is e10s specific issue with low performance laptops (specs are given below). It does not reproduce when e10s is disabled or high performance computer is used instead. It is also not affected by hardware acceleration conditions (checked or unchecked). Steps to Reproduce: 1. Play music from https://www.yahoo.com/music/tagged/performances 2. Click the zoom arrows at the bottom-right of the movie window to watch in full-screen mode 3. Verify the window switches between full-screen and default-screen sizes before it turns to be a stable full-screen Actual Result: Player window does not directly go to full-screen mode. Expected Result: The player window should directly go to full-screen mode when zoom-In arrows are clicked. Test Machines: Laptop 1) PROCESSOR: Z3735F@1.33GHz RAM: 2GB GRAPHICS: Intel HD Graphics Direct 3D11 BUILD ARCH: Version 10.0 - 10240 Laptop 2) PROCESSOR: AMD A6-5200 APU @2.00GHZ RAM: 4GB / 3.45 USEABLE GRAPHICS: AMD Radeon HD 8400 / R3 Series Direct3D11 BUILD ARCH: Version 10.0 - 10240 Laptop 3) PROCESSOR: N3050@1.60GHz RAM: 2GB GRAPHICS: Intel HD Graphics Direct3d11 BUILD ARCH: Version 10.0 - 10240 Laptop 4) PROCESSOR: "AMD A4-6210 APU @1.80ghZ " RAM: 4GB GRAPHICS: AMD Radeon R3 Graphics Direct 3D11 BUILD ARCH: Version 6.3 - 9600 Laptop 5) PROCESSOR: Intel Core i3-4005U @1.70GHz RAM: 8GB GRAPHICS: Intel HD Graphics Family Direct 3D11 BUILD ARCH: Version 10.0 (Build 10240)

Version 48.0a1 Build ID 20160412030231 Update Channel nightly User Agent Mozilla/5.0 (Windows NT 10.0; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0

Barbara, should this block rollout? It's a polishy but the experience is kinda yucky.

FWIW, I can reproduce this on my reasonably high-powered engineering-spec MBP, so I don't think this is restricted to just low-end hardware.

After comment #3, I believe this is a thing to investigate further. Audio/video remains a big piece to our users and hence should not be worse than before. I was able to reproduce the issues as well with my MacBook Pro. I wondered if it's "just" a flash issue but went over to YouTube, played a few videos in full-screen, exited and noticed also all kinds of wacky resizing issues. I'd say this blocks rollout.

Hmph, none of these videos play for me on Windows 7 in Nightly. The ads transition fine though.

(In reply to Jim Mathies [:jimm] from comment #5) > Hmph, none of these videos play for me on Windows 7 in Nightly. The ads > transition fine though. Filed bug 1265238.

(In reply to Jim Mathies [:jimm] from comment #6) > (In reply to Jim Mathies [:jimm] from comment #5) > > Hmph, none of these videos play for me on Windows 7 in Nightly. The ads > > transition fine though. > > Filed bug 1265238. Managed to track this down and get these playing. Still not able to see anything on my main Windows workstation or my Windows laptop though. Tracy, could you try to reproduce and if so, post a screen capture video of this so we can all see it?

Xidorn, any chance you can take a look at this?

I guess this is because the fullscreen fade-through-black transition ends earlier than the content is painted correctly on e10s, which is probably due to the same issue mentioned in the dev-platform post about MozAfterPaint with e10s [1]. Fullscreen transition listen to this event for unblack the screen, so if that event is received earlier, it could be an issue. I'll have a look. [1] https://groups.google.com/forum/#!topic/mozilla.dev.platform/pCLwWdYc_GY

Review commit: https://reviewboard.mozilla.org/r/47327/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/47327/

Comment on attachment 8742576 [details] MozReview Request: Bug 1264091 - Ensure we unblack the screen for a right after-paint event. r?dao A comment on the transactionId check would be nice. I have a rough idea what this is (more like a guess based your patch description) but I don't really know.

I'd be interested in knowing if this fixes the issue that Abe was seeing. At least for OS X, I'm still seeing the same behaviour with this patch (the fullscreen transition ends, but after the fade-up, we see the web content at normal scale for some seconds before the video transitions to fullscreen). If this fixes it for Abe on Windows, perhaps we should open a separate bug for the OS X case (which barbara was hitting too in comment 4). It's been a while since I dealt with the fullscreen stuff, but perhaps we need to wait until content has finished its fullscreen transition before doing the fade-up?

not sure this is gonna work. but here goes. :)

Comment on attachment 8742949 [details] full screen switching unsmooth yep. no good. have to do some research on how to get a video of this up. But I can reproduce on window, fwiw.

Are you able to reproduce with xidorn's patch? Here's a try build you can try (when it's done building): https://treeherder.mozilla.org/#/jobs?repo=try&revision=984ae03eb2fc

(In reply to Mike Conley (:mconley) - Needinfo me! from comment #12) > I'd be interested in knowing if this fixes the issue that Abe was seeing. At > least for OS X, I'm still seeing the same behaviour with this patch (the > fullscreen transition ends, but after the fade-up, we see the web content at > normal scale for some seconds before the video transitions to fullscreen). > > If this fixes it for Abe on Windows, perhaps we should open a separate bug > for the OS X case (which barbara was hitting too in comment 4). > > It's been a while since I dealt with the fullscreen stuff, but perhaps we > need to wait until content has finished its fullscreen transition before > doing the fade-up? We wait until that, but with a timeout of 0.5s (was 1s), because there are some cases we cannot guarantee to have that done, and also a too long black screen would annoy user as well. The reflow time could sometimes take several hundreds of milliseconds, so the boundary is not too hard to be broken. This specific page could take ~3s on my local debug build to do fullscreen reflow. To check the effectiveness of this patch, you may want to set pref "full-screen-api.transition.timeout" to something like 5000 (5s) so that the time limit is never reached. There is another e10s-specific fullscreen issue that the message between processes could sometimes be very slow (up to ~100ms). I'm going to rewrite that part with native IPC call in bug 1251122 with expectation that it could reduce code complexity and improve performance here.

The issue still reproduces in the try-build from Mike (comment 15). --- Version 48.0a1 Build ID 20160419153036 Update Channel default User Agent Mozilla/5.0 (Windows NT 10.0; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0

The try build is a little better in that the transition goes directly to and from full screen without hitting an intermediate sized window in between. However, and it may just be stressed machine, painting just after transition is choppy and the audio is choppy for a second or two, as well.

(In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #16) > The reflow time could sometimes take several hundreds of milliseconds, so > the boundary is not too hard to be broken. This specific page could take ~3s > on my local debug build to do fullscreen reflow. To check the effectiveness > of this patch, you may want to set pref "full-screen-api.transition.timeout" > to something like 5000 (5s) so that the time limit is never reached. > > There is another e10s-specific fullscreen issue that the message between > processes could sometimes be very slow (up to ~100ms). I'm going to rewrite > that part with native IPC call in bug 1251122 with expectation that it could > reduce code complexity and improve performance here. This is possible, and I think what needs to be investigated. I don't think the patch in this bug actually addresses the issue being reported here. We need to figure out where the delay is in transitioning the web content to full screen mode, when compared against non-e10s.

(In reply to Mike Conley (:mconley) - Needinfo me! from comment #19) > (In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #16) > > The reflow time could sometimes take several hundreds of milliseconds, so > > the boundary is not too hard to be broken. This specific page could take ~3s > > on my local debug build to do fullscreen reflow. To check the effectiveness > > of this patch, you may want to set pref "full-screen-api.transition.timeout" > > to something like 5000 (5s) so that the time limit is never reached. > > > > There is another e10s-specific fullscreen issue that the message between > > processes could sometimes be very slow (up to ~100ms). I'm going to rewrite > > that part with native IPC call in bug 1251122 with expectation that it could > > reduce code complexity and improve performance here. > > This is possible, and I think what needs to be investigated. I don't think > the patch in this bug actually addresses the issue being reported here. Well, there are two issues: 1. MozAfterPaint could be dispatched before we finish the reflow; 2. the message could be dispatched too slow. To know which is issue here, you can set "full-screen-api.transition.timeout" to a large value (e.g. 5000). If it doesn't happen anymore, then it is just 2), however if it still happens, it could be 1) or a mix of 1) and 2). The patch in this bug addresses the first issue, and the second issue is relatively non-trivial. I set feedback? you because I hope to confirm with you whether this is the right way to use transitionId given you sent that email to dev-platform. If that is the right way, let's close this bug with this patch, and probably open another bug for the second issue. Do you agree?

Comment on attachment 8742576 [details] MozReview Request: Bug 1264091 - Ensure we unblack the screen for a right after-paint event. r?dao Yep, okay. Sounds good.

https://hg.mozilla.org/integration/mozilla-inbound/rev/2f34f0a20c58059be4ccac8f2023ca2a9defedd3 Bug 1264091 - Ensure we unblack the screen for a right after-paint event. r=dao