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.

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.

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.

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.

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 on attachment 418881 [details] [diff] [review] serialization errors Should that NS_WARNING be an NS_ASSERTION? What case are we protecting against?

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.

(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.

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

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

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