Closed Bug 526393 Opened 13 years ago Closed 13 years ago
Electrolysis: mousewheel scrolling fails when OOP XEmbed plugin content is under the pointer
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.)
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.
(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.
We should consider what to do about this before porting to 1.9.2.
See also Bug 483136.
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).
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.
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.
Attachment #434213 - Flags: review?(roc)
Attachment #434213 - Flags: review?(roc) → review+
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a4
http://hg.mozilla.org/projects/firefox-lorentz/rev/8405e6c74a6e (wrong bug# in both commits, oops)
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
Blanket approval for Lorentz merge to mozilla-1.9.2 a=beltzner for 126.96.36.199 - 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
You need to log in before you can comment on or make changes to this bug.