Closed Bug 1094304 Opened 5 years ago Closed 4 years ago
[e10s] Windowless flash video player on facebook displays fullscreen window behind browser window on first try
Story: Create Clean Profile enable e10s browse to https://www.facebook.com/video.php?v=1550644941743049&set=vb.1318800798260799&type=2&theater (no login needed) play the video click the enter fullscreen icon in the player Result: Playback comes up fullscreen but behind firefox window (perhaps behind all other windows) This happens only on e10s enabled tabs and ONLY on the first try for the browser session. The second try to go to full screen in a browser session is ok. Expected Result: Flash video should take over the screen when you click the fullscreen icon Reproducible: Always, on Firefox Buildid: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:36.0) Gecko/20100101 Firefox/36.0 ID:20141105030203 CSet: 62990ec7ad78 Other observations: If you do not select the background video and try to click inside the flash area of the page hosting the player, playback will start to stutter.
Why e10s: Opening the Url in a non e10s window after browser start will make "enter fullscreen" work on the first try.
The Flash icon is visible in task bar when using FF33 without e10s enabled, but it doesn't prevent Flash going in fullscreen mode. So I guess e10s enabled in FF36 exacerbates this behaviour becoming buggy for the user.
Component: General → Plug-ins
Product: Firefox → Core
In E10S mode the facebook video player freezes the entire session forcing me everytime to kill he main process
I can confirm this behavior. It seems to be with every Flash content that can be switched to fullscreen. Tested with: Mozilla/5.0 (Windows NT 6.4; Win64; x64; rv:36.0) Gecko/20100101 Firefox/36.0 [build-id: 20141108030205] Mozilla/5.0 (Windows NT 6.4; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0 [build-id: 20141108030205] Flash Player 184.108.40.206 beta Windows 10 Technical Preview build 9860
Unrelated to flash, this looks like html5 video to me using our dom fullscreen functionality. marking for re-triage.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Martin, Jim just landed a bunch of changes to how plugins work on windows. Can you retest with tomorrow's nightly?
(In reply to Jim Mathies [:jimm] from comment #5) > Unrelated to flash, this looks like html5 video to me using our dom > fullscreen functionality. marking for re-triage. Hmm, actually I think this is flash (the full screen window is owned by a flash process, but the applet is windowless.
Summary: [e10s] flash player video player on facebook will come up behind the firefox window on the _first_ attempt to enter fullscreen mode → [e10s] Windowless flash video player on facebook displays fullscreen window behind browser window on first try
So this should probably block an e10s milestone, since it involves hacking flash fullscreen probably m5 or m6.
Hi Jim, just retested on BuildID: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:36.0) Gecko/20100101 Firefox/36.0 ID:20141113030201 CSet: ab137ddd3746 Result: Unchanged as reported
Retested on : Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:36.0) Gecko/20100101 Firefox/36.0 ID:20141114030206 CSet: 7f0d92595432 Still comes up in background with e10s enabled
By the way this definitely is Flash, since I have set my preferences for click to activate and need to activate the flash plugin when testing.
Just re-tested on Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:38.0) Gecko/20100101 Firefox/38.0 ID:20150123093302 CSet: a6bbabebed2f Bug still exists as reported. FYI:just so you know, non of the changes since I originally reported did 'accidentally' fix it ;-)
Before we can fix this, we need to get mouse coordinates in windowless flash working right. That bug though is currently m8, and this one is currently m6.
Moving this back to m6 and blocking it on m6 bug 1128238, which I can use to cover mouse coord issues. bug 1086718 is specific to flash context menus.
woot - appears to be fixed by the patch in bug 1128238.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.