Closed Bug 1094304 Opened 10 years ago Closed 9 years ago

[e10s] Windowless flash video player on facebook displays fullscreen window behind browser window on first try

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(e10sm6+)

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
e10s m6+ ---

People

(Reporter: martin, Assigned: jimm)

References

(
URL
)

Details

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.
tracking-e10s: --- → ?
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.
Blocks: e10s
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 15.0.0.222 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.
tracking-e10s: + → ?
No longer depends on: e10s-windowed-plugin
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: flashplayer
Martin, Jim just landed a bunch of changes to how plugins work on windows. Can you retest with tomorrow's nightly?
Flags: needinfo?(martin)
(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
Flags: needinfo?(martin)
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.
tracking-e10s: m6+ → ?
Depends on: 1086718
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.
tracking-e10s: ? → m6+
Depends on: 1128238
No longer depends on: 1086718
QA Contact: jmathies
Assignee: nobody → jmathies
QA Contact: jmathies
woot - appears to be fixed by the patch in bug 1128238.
wfm on 

https://www.facebook.com/video.php?v=1550644941743049&set=vb.1318800798260799&type=2&theater
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.