Closed Bug 1128238 Opened 5 years ago Closed 5 years ago
[e10s] Facebook's Flash video player does not respond to mouse input
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:38.0) Gecko/20100101 Firefox/38.0 Build ID: 20150131030230 Steps to reproduce: Find a video on Facebook and hover over it to try to reveal the video controls. Actual results: The controls may appear for a split second, but disappear again. They may respond better with a mouse click, but again that will only work for a split second.
Looks like there are still some issues with mouse coords and windowless.
major plugin bugs are aurora uplift blockers.
Summary: [e10s] Facebook's Flash video player does not respond to mouse hover → [e10s] Facebook's Flash video player does not respond to mouse input
It appears that we're not adjusting the coordinates for mouse events for the chrome correctly here - https://dxr.mozilla.org/mozilla-central/source/layout/generic/nsPluginFrame.cpp#764 In non-e10s, windowless delivers events relative to the browser window. In e10s, our coords are relative to content. However, adjusting this doesn't fix the entire problem. Flash does some funny stuff behind the scene with mouse input. I see a series of api calls when mouse input is processed: GetCursorPos WindowFromPoint ScreenToClient .. Still doing some compares between e10s and non-e10s here to try and figure out where flash is going wrong.
Not complete yet, flash still has an issue with origin and the lower youtube controls. Other plugins seems fine.
Flash is doing something under the hood here which messes mouse move events up, not sure at this point what it is they do. I see a few common calls by the flash library in processing mouse input: 1) flash calls GetCursorPos, which returns cursor position in screen coordinates 2) flash call WindowFromPoint using the point returned above 3) flash checks the window handle returned by WindowFromPoint to see if it's visible 4) flash calls ScreenToClient([hwnd from WindowFromPoint], [point from GetCursorPos]) In step four, they get back a point equal to the point we hand in through handleevent.
Attachment #8578705 - Attachment is obsolete: true
benjamin, do we have any contacts at adobe who might be able to help poke at this from their end?
This is ADBE 3959281
Lets get this part landed since I'm confident we need it.
thanks for the quick review! try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=aec320da560c
This bug occurs on most video players on my end, even youtube.
Attachment #8586322 - Attachment is obsolete: true
Same basic patch except I'm adjusting coords in slightly different places this time. This completely fixes the problem in flash for me, without breaking silverlight afaict.
No longer blocks: 1151310
Duplicate of this bug: 1151310
FYI, I changed the name of nsPluginFrame::GetTabChromeOffset() to GetRemoteTabChromeOffset() to prevent confusion. I don't want people calling that in non-e10s and expecting it to return a good value.
Confirming this fix on latest DevEdition, build ID:20150720004006 and latest Nightly, build ID: 20150720030213. The video controls are now properly displayed.
You need to log in before you can comment on or make changes to this bug.