526393 - Electrolysis: mousewheel scrolling fails when OOP XEmbed plugin content is under the pointer.

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Karl Tomlinson (:karlt)]

STR:
1) enable out of process plugins
2) visit http://www.flashgames247.com/play/1117.html
3) Mouse over the game
4) Move the scroll wheel.

Expected results:
Page scrolls

Actual results:
Nothing

(Works as expected with in-process plugins.)

Comment 1

[Karl Tomlinson (:karlt)]

It seems likely that this is a difference in implementation of GtkPlug/GtkSocket when in and out of process.  That should be fixable, I think.

Also, something that maybe could be done in Gecko to limit the effects of this is described in bug 409669 comment 11.

Comment 2

[Karl Tomlinson (:karlt)]

(In reply to comment #1)
> It seems likely that this is a difference in implementation of
> GtkPlug/GtkSocket when in and out of process.  That should be fixable, I think.

To be clear: fixable in GTK.

Comment 3

[Karl Tomlinson (:karlt)]

We should consider what to do about this before porting to 1.9.2.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

See also Bug 483136.

Comment 5

[Karl Tomlinson (:karlt)]

Thanks Olli.  Doing something similar but different to attachment 427889 [details] [diff] [review], possibly using the same nsEventStateManager would be a good solution for when the transaction begins outside the plugin and should probably be done for bug 409669.  That (or the X11 implementation) may be a bit complex to back port to 1.9.2 though.

The difference between IPP and OOPP is that the GtkPlug doesn't propagate unhandled scroll events to the parent (GtkSocket) when OOP.  This is something that is not specified in the XEmbed spec, but just happened to work well with GTK's in-process implementation.  I think we can probably do a fairly self-contained propagation of synthetic events, so I'll try this out.  This will solve the problem even when the transaction begins in the plugin, but won't help transactions that start outside the plugin and get blocked by a plugin that says it is handling the events (which is the situation we have on 1.9.2 anyway).

Comment 6

[Karl Tomlinson (:karlt)]

The GtkPlug implementation seems the best place to do this so I attached a patch to https://bugzilla.gnome.org/show_bug.cgi?id=613308.

With GTK+ libraries that don't have that patch, we should be able to "install" the same implementation into the GtkPlugClass from PluginModuleChild.

Comment 7

[Karl Tomlinson (:karlt)]

Attachment: propagate scroll events from GtkPlug to the embedder

Much of this is copied from the patch in the GTK bug report.  Functionally it's equivalent except for a socket_window check that I forgot, and we don't need to specify GDK_SCROLL_MASK events with GDK_NATIVE_WINDOWS=1.
I probably would have done some things a little differently if I'd written this in C++, but there are some advantages in keeping it similar to the C patch for GTK.

Comment 8

[Karl Tomlinson (:karlt)]

http://hg.mozilla.org/mozilla-central/rev/60fb978130f5

Comment 9

[Benjamin Smedberg]

http://hg.mozilla.org/projects/firefox-lorentz/rev/8405e6c74a6e

(wrong bug# in both commits, oops)

Comment 10

[Karl Tomlinson (:karlt)]

I backed out and relanded with the correct bug number to fix the blame on m-c:
http://hg.mozilla.org/mozilla-central/rev/5202fb68e9a7
http://hg.mozilla.org/mozilla-central/rev/7f2361a66046

Comment 11

[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 12

[Benjamin Smedberg]

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