Closed Bug 526393 Opened 12 years ago Closed 11 years ago

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

Categories

(Core :: Plug-ins, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.9.3a4
Tracking Status
status1.9.2 --- .4-fixed

People

(Reporter: karlt, Assigned: karlt)

References

Details

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

Attachments

(1 file)

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.
Blocks: LorentzBeta1
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)
http://hg.mozilla.org/mozilla-central/rev/60fb978130f5
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a4
http://hg.mozilla.org/projects/firefox-lorentz/rev/8405e6c74a6e

(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:
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 1.9.2.4 - please make sure to mark status1.9.2:.4-fixed
You need to log in before you can comment on or make changes to this bug.