619281 - Can't scroll the website when i put the mouse pointer over a Flash using Gnash Plugin

Status: RESOLVED INCOMPLETE

(Plugins Graveyard :: Flash (Gnash), defect)

Description

[maximi89]

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0b8pre) Gecko/20101203 Firefox/4.0b8pre
Build Identifier: 

When i'm using Gnash player i can't scroll the website if the mouse pointer are over a Flash, probably it's just the implementation of gnash, but could be great to get more information about this.

https://savannah.gnu.org/bugs/index.php?31836

Reproducible: Always

Steps to Reproduce:
1.just put the mouse pointer over a flash
2.try to scroll the site
3.
Actual Results:  
it fails every time

Expected Results:  
to scroll when the mouse pointer is over a flash, like Adobe Flash plugin

Gnash is an OpenSource Flash player

Comment 1

[Karl Tomlinson (:karlt)]

If you request XEmbed and use a GtkPlug, the plugin-container has code to propagate the scroll events.

Comment 2

[Bastiaan Jacques]

Hi Karl,

We do indeed use XEmbed and GtkPlug.

The problem for us that we can't propagate the event back to Firefox so that it can be handled as Firefox scroll as opposed to a plugin scroll. (If there is a way to do that, I'd love to know how, provided it isn't too hacky.)

In practice, I would like the scroll event to stay with Firefox until the user clicks on the plugin window (in which case Gnash would grab the focus, causing scroll events to go to Gnash from that point on).

Comment 3

[Karl Tomlinson (:karlt)]

Returning false from the scroll-event signal should be sufficient to propagate the event to the browser.

(In reply to comment #2)
> In practice, I would like the scroll event to stay with Firefox until the user
> clicks on the plugin window (in which case Gnash would grab the focus, causing
> scroll events to go to Gnash from that point on).

That sounds like it could be a sensible approach.  Gnash could choose whether to propagate scroll events based on whether it has focus.  (When the mouse is outside the plugin window, the plugin wouldn't get scroll events, even if it has focus, but I assume that's fine.)

Usually in the browser we try to make scroll event dispatch depend on where the scroll began, but that's harder to make work well with X11 events.

Comment 4

[Bastiaan Jacques]

(In reply to comment #3)
> Returning false from the scroll-event signal should be sufficient to propagate
> the event to the browser.

Unfortunately, that does not work. In fact, it works for all other key events, but not scroll ones.

My theory is that's because Mozilla is forwarding the scroll events by rolling its own XEvent, rather than letting GTK deal with it. See https://mxr.mozilla.org/mozilla-central/source/dom/plugins/PluginModuleChild.cpp#428 (In our case, the GtkPlug is in a different process.)

Comment 5

[Karl Tomlinson (:karlt)]

(In reply to comment #4)
> (In our case, the GtkPlug is in a different process.)

Ah, I wasn't aware of that.

GtkPlug only propagates scroll events when it is on the same display as the GtkSocket.  https://bugzilla.gnome.org/show_bug.cgi?id=613308

For out-of-process plugins, we had to add our own code to make that work when the plug and socket were in different processes.

If Gnash's GtkPlug is in yet another process, it will be unaffected by our forwarding code, and subject to https://bugzilla.gnome.org/show_bug.cgi?id=613308

Bug 409669 comment 18 describes an approach that perhaps the browser could use to capture scroll events when scrolling begins while the mouse is outside the plugin.

Comment 6

[Benjamin Smedberg]

Closing old bugs in the Plugins component. We aren't going to track issues in 3rd-party plugins in the Mozilla bug tracker. In addition, support for NPAPI plugins will be removed at the end of this year; for more details see the post at https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/

If there is a serious bug in Firefox, it needs to be filed in the "Core" product, "Plug-Ins" component.