Closed Bug 526393 Opened 15 years ago Closed 15 years ago

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


(Core Graveyard :: Plug-ins, defect)

Not set


(status1.9.2 .4-fixed)

Tracking Status
status1.9.2 --- .4-fixed


(Reporter: karlt, Assigned: karlt)



(Keywords: regression, Whiteboard: [fixed-lorentz])


(1 file)

1) enable out of process plugins
2) visit
3) Mouse over the game
4) Move the scroll wheel.

Expected results:
Page scrolls

Actual results:

(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.
Blocks: LorentzBeta1
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

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)
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a4

(wrong bug# in both commits, oops)
Whiteboard: [fixed-lorentz]
I backed out and relanded with the correct bug number to fix the blame on m-c:
Blanket approval for Lorentz merge to mozilla-1.9.2
a=beltzner for - please make sure to mark status1.9.2:.4-fixed
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.