Flash: Mouse input flickers when view is offset in window

[dreijer]

I'm using CEF3 in OSR mode and I'm rendering a webpage that has a Twitch Flash player on it. When I hover the mouse over the player's buttons (play, pause, mute, etc.), the buttons flicker, i.e. it's like the Flash player registers the mouse input, but then immediately considers the mouse to have been moved away.

After doing a little bit more digging, it turns out that this behavior only happens if the browser's viewport is offset from the top-left of the browser's parent window. That is, in OSR mode, you call SetAsOffScreen() with an HWND to the browser's parent window. This HWND is somewhat irrelevant in OSR mode since there isn't necessarily a one-to-one mapping between a browser and a physical window. In my case, if I happen to have a physical window, I pass its handle to CEF; if I don't have a physical window, I just create a dummy hidden window and pass its handle to CEF (I'm not exactly sure what CEF needs the HWND for in OSR mode actually?).

Now, if the browser view is positioned at 0,0 in the physical window, the input in the flash player is just fine and dandy. However, if the view is offset, the input starts to flicker. My guess is that Flash somehow uses the coordinates of the HWND that was passed in when I created the browser despite me providing the proper view coordinates and translation to screen coordinate via GetViewRect(), GetScreenPoint(), etc.

[magreenblatt]

Are you getting correct calls to OnCursorChange?

[dreijer]

Yep, they're coming in just fine. Right-clicking with the mouse in the player also shows the context menu at the correct location.

[magreenblatt]

Unfortunately I don't know any good fix for this. You can debug the Chromium plugin code to at least verify that the issue is in flash. You could also try the ppapi plugin to see of that makes a difference.

[dreijer]

Unfortunately I don't know any good fix for this. You can debug the Chromium plugin code to at least verify that the issue is in flash. You could also try the ppapi plugin to see of that makes a difference.

Right okay, I'll give that a shot. Do you have some pointers to where this code lives in Chromium / what controls the input to windowless plugins?

[magreenblatt]

See webplugin_* in webkit/plugins/npapi.

[paulkatto]

you are seeing exactly the same I am seeing, same problem, see:

viewtopic.php?f=6&t=10579

No solution there though, I am debugging, but I can't find the bug. I confirm your observation with the HWND handle (matching position and size). But I need to pass SetAsOffScreen(0).

[dreijer]

you are seeing exactly the same I am seeing, same problem, see:

viewtopic.php?f=6&t=10579

No solution there though, I am debugging, but I can't find the bug. I confirm your observation with the HWND handle (matching position and size). But I need to pass SetAsOffScreen(0).

I haven't had a chance to take a closer look myself yet, but hopefully sometime this week. Why do you have to pass NULL to SetAsOffScreen()? You could always create an invisible window and use its handle. The bigger question is whether the HWND is actually used for anything (which it looks like it is) and why.

[paulkatto]

Have to pass null because I'm not a full screen application and my texture is not necessarily mapped as a 2d rect on screen. So I would have to take care of moving around the invisible hwnd (or perhaps just create one big enough?) It feels as a bug to me anyway. Reading the comment around the critical code it looks to me as someone fixed something on mac and broke it on windwos. Furhtermore the --singe-process variant works well, it uses different code, haven't yet figured out why and which code.

[dreijer]

Is there a way in Chromium to translate a windowless coordinate to an actual screen coordinate? I'm talking specifically about WebPluginDelegateImpl and PluginHost.