536369 - OOPP: Right clicking flash object shows context menu at screen coords, not object coords

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[(not currently active) Ted Mielczarek]

I have OOPP enabled. Loading the URL on this bug, and right clicking on the flash video displays the context menu up at the top left of my screen. It appears on the screen at the coordinates relative to the object where I clicked. If I right click at nearly (0,0) on the plugin, the popup displays at nearly (0,0) on my screen.

Comment 1

[Jim Mathies [:jimm]]

Hmm, coords for the event are correctly getting translated. Might be the lack of a parent hwnd? I'm also getting ipc deserialization errors on this event. Will take a look.

Comment 2

[Jim Mathies [:jimm]]

This will be interesting to fix. Flash makes calls to NPN_GetValue for NPNVnetscapeWindow, which should return the hwnd of the window the applet is rendering to. My guess is flash uses this in a call to ClientToScreen (or similar) to get the correct positioning for a call to CreateWindow for the popup. Even if we get the hwnd over there, input/paint events are translated to the origin of the offscreen dib we're rendering to, so the positioning would still be incorrect.

One way to solve this might be to create a hidden window in the same position on the desktop as the plugin rectangle, and hand that back for NPNVnetscapeWindow. Not sure if that's the simplest fix at this point but it would at least confirm the assumptions I'm making here about what's going on.

Comment 3

[Jim Mathies [:jimm]]

Attachment: serialization errors

This touches up the plugin/nsobjectframe/nswindow code to address wm_mouseleave events we didn't handle correctly. These were the source of the serialization errors I was seeing.

Comment 4

[Jim Mathies [:jimm]]

Attachment: NPNVnetscapeWindow patch

This addresses positioning issues with both windowed and windowless. 

Unfortunately there are still some other problems with flash UI that I'll file a separate bug on.

Comment 5

[Benjamin Smedberg]

Comment on attachment 418881 [details] [diff] [review]
serialization errors

Should that NS_WARNING be an NS_ASSERTION? What case are we protecting against?

Comment 6

[Benjamin Smedberg]

Comment on attachment 420987 [details] [diff] [review]
NPNVnetscapeWindow patch

There is no implementation of NPNVnetscapeWindow for non-windows? Please see http://code.google.com/p/chromium/issues/detail?id=20474 and file a followup for non-Windows if appropriate.

Comment 7

[Jim Mathies [:jimm]]

(In reply to comment #5)
> (From update of attachment 418881 [details] [diff] [review])
> Should that NS_WARNING be an NS_ASSERTION? What case are we protecting against?

Fall through from event processing in nsObjectFrame. Cases where we add / send events to the plugin that we don't handle correctly here - 

http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsObjectFrame.cpp#4337

I guess an assert would be alright as well, I was more interested in just warning people since these are pretty harmless.

Comment 8

[Jim Mathies [:jimm]]

http://hg.mozilla.org/mozilla-central/rev/b31af5a35e90
http://hg.mozilla.org/mozilla-central/rev/8464e2aaddea

Comment 9

[Benjamin Smedberg]

http://hg.mozilla.org/projects/firefox-lorentz/rev/17dabf9aebb6

Comment 10

[Mike Beltzner [:beltzner, not reading bugmail]]

Blanket approval for Lorentz merge to mozilla-1.9.2
a=beltzner for 1.9.2.4 - please make sure to mark status1.9.2:.4-fixed

Comment 11

[Benjamin Smedberg]

Merged into 1.9.2 at http://hg.mozilla.org/releases/mozilla-1.9.2/rev/84ba4d805430