1128238 - [e10s] Facebook's Flash video player does not respond to mouse input

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Josh Tumath]

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.

Comment 1

[Jim Mathies [:jimm]]

Looks like there are still some issues with mouse coords and windowless.

Comment 2

[Jim Mathies [:jimm]]

major plugin bugs are aurora uplift blockers.

Comment 4

[Jim Mathies [:jimm]]

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.

Comment 5

[Jim Mathies [:jimm]]

Attachment: wip

Not complete yet, flash still has an issue with origin and the lower youtube controls. Other plugins seems fine.

Comment 6

[Jim Mathies [:jimm]]

Attachment: wip

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.

Comment 7

[Jim Mathies [:jimm]]

benjamin, do we have any contacts at adobe who might be able to help poke at this from their end?

Comment 10

[Jeromie Clark]

This is ADBE 3959281

Comment 11

[Jim Mathies [:jimm]]

Attachment: offset mouse input by the tasb offset

Lets get this part landed since I'm confident we need it.

Comment 12

[Jim Mathies [:jimm]]

thanks for the quick review!

try push:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=aec320da560c

Comment 13

[Rag]

This bug occurs on most video players on my end, even youtube.

Comment 14

[Jim Mathies [:jimm]]

Attachment: patch v.2

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.

Comment 17

[Jim Mathies [:jimm]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=bacb9a1dc841

Comment 18

[Jim Mathies [:jimm]]

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.

Comment 19

[Jim Mathies [:jimm]]

https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=9902d3bf59e4

Comment 20

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/9902d3bf59e4

Comment 21

[Cornel Ionce [:noni] [Hubs QA]]

Confirming this fix on latest DevEdition, build ID:20150720004006 and latest Nightly, build ID: 20150720030213.
The video controls are now properly displayed.