If the mouse is hold on a flash animation keyboard and mouse scrolling stop to work

Bug #50839 reported by Marco Cimmino on 2006-06-24
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
firefox (Ubuntu)
Nominated for Jaunty by Savvas Radevic
Nominated for Lucid by Savvas Radevic
flashplugin-nonfree (Ubuntu)
Nominated for Jaunty by Savvas Radevic
Nominated for Lucid by Savvas Radevic

Bug Description

Tried three browser under kubuntu 6.06:

- with Konqueror if you pass and hold on the mouse on a flash image then scrolling with mouse scroll stop to work, but keyboard is ok
- with Firefox scrolling and keyboard stop to work until the mouse moves out to the flash image
- with Opera cannot reproduce, seems all ok!

Don't know if they are flash problems or browser problems :)

Marco Cimmino (cimmo) on 2006-06-24
description: updated
Daniel T Chen (crimsun) wrote :

I can reproduce the symptom on all three browsers mentioned in the original submitter's report, but there's not much that can be done about it. It seems to be an upstream issue.

Changed in flashplugin-nonfree:
importance: Untriaged → Low
status: Unconfirmed → Confirmed
Marco Cimmino (cimmo) wrote :

it's strange that can be flash upstream bug, why I cannot reproduce in Opera for example?

Bart Martens (bartm) wrote :

I confirm this bug to exist on Debian with these packages:

firefox 1.5.dfsg+

Marco Cimmino (cimmo) wrote :

Still here with 9.0.31 final :(

GaaL (gaal33) wrote :

A bug report is still open at firefox's bugzilla


Changed in firefox:
status: Unknown → Confirmed
Marco Cimmino (cimmo) wrote :

and also to this bug, seems it's not fixed for linux :(

Marco Cimmino (cimmo) wrote :

this is the linux specific bugreport for mouse wheel, marked as wontfix because they don't know how to fix it :(

Changed in firefox:
status: Confirmed → Invalid
Marco Cimmino (cimmo) wrote :

ok with flash 9.0.64 from adobe the keyboard is no more locked, but scrolling still locked, I have pinged mozilla devels, they said that will take care, hopefully for 3.0

Marco Cimmino (cimmo) wrote :

ok the bug regarding MOUSE SCROLL is now fixed thanx that I a bit pressed in the bug report.
Firefox nightly is just fixed and patch will be pushed into firefox 3.0 beta2, so it will be finally fixed in Ubuntu as soon as beta2 (or later) will reach Hardy.

for KEYBOARD instead can be fixed switching to flash 9.0.115 that is already present in Hardy!


Changed in firefox:
status: Unknown → Fix Released
Marco Cimmino (cimmo) on 2007-12-12
Changed in flashplugin-nonfree:
status: Confirmed → Invalid
Changed in firefox-3.0:
status: New → Confirmed
mouse (mr.mouse) wrote :

the same problem with totem plug for firefox.

is that also fixed, or is that different bug ?

Alexander Sack (asac) wrote :

hardy will soon received firefox 3 beta2 ... once you have it please confirm that this is fixed.

 - Alexander

Changed in firefox-3.0:
status: Confirmed → In Progress
Marco Cimmino (cimmo) wrote :

well seems that for only 1 day the beta2 has not the patch, so will have to wait till beta3 or rc1 whatever it will be :(

This but is a sort-of follow-up to bug 386687.

Since bug 386687 has been closed because most scenarios have been fixed on the Mozilla trunk with Flash Player versions newer than 9.0.64, I am opening this bug since there are clearly some pages where this symptom persits, probably due to another hidden bug.

The problem is demonstrated on the following page:

http://www.ikea.com/pl/pl/ - when mouse hovers over the large flash banner,
mouse wheel doesn't scroll (but keyboard arrows DO scroll).

While it's not present on most other pages, e.g.:

http://www.arkadia.com.pl/ - mouse wheel scrolling works fine.

It's hard to tell what causes the problem on the IKEA page, while the Arkadia
page works fine. They both use JavaScript for creating the SWF object, although
in a slightly different way.

An isolated, minimal testcase would be welcome if anybody could come up with one.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2007122400 Minefield/3.0b3pre

No problem here scrolling with mouse wheel over the flash ad.

The difference (between pages on Linux that scroll fine and those that don't) may be in whether or not the Flash script handles the scroll event.

Currently the event is first passed (by GTK) to the Flash plugin (if the pointer is over the plugin window) and only comes to Mozilla if not handled by the plugin.

This means that scrolling behavior will be like FF2 where the element scrolled is the inner-most scrollable element containing the pointer position. (And perhaps the Flash script is handling the event even though there is nothing to scroll.)

To get the new behavior like other scrollable elements on trunk (where it is the pointer position when scrolling starts that is significant), perhaps something can be done with plugin_client_message_filter in nsWindow.cpp. The fun bit might be ensuring that the event still gets to the plugin when it should.

bug 78414 and bug 87383 are related because they may also be resolved by intercepting the events before GTK delivers them (but the plugin can also intercept events earlier if it wants to).

Marco Cimmino (cimmo) wrote :

with the latest update for firefox in Hardy now the bug is totally gone!

Changed in firefox-3.0:
status: In Progress → Fix Released
verb3k (verb3k) wrote :

Still reproducible on the latest Firefox 3 trunk (built in Jan 10 2008) with the flash plugin that shipped with gutsy (not the recently released version)

Example site:
The flash banner that is *under* the SpeedTouch ad still catches the mouse scrolling.

Marco Cimmino (cimmo) wrote :

Ali to have the bug fixed you MUST have firefox 3 post beta2 AND flash 9.0.115

verb3k (verb3k) wrote :

Thanks for your reply Cimmo,
I have the latest trunk, so I think the problem is related to the Flash plugin itself, I didn't upgrade to the new plugin because I tried it and it was very slow (I have an old machine).

Marco Cimmino (cimmo) wrote :

there is another big problem: konqueror doesn't work with new flash, however there is no others solution to solve thig bug, you have to update flash ;)

Ria: could you test under Linux with the same browser versions?

(In reply to comment #4)
> Ria: could you test under Linux with the same browser versions?
No Linux available here.

I posted a similar bug ( bug 407500 ), but I'm on Windows XP.

I have no problems with mouse scrolling over flash on the two links you provided.

Could you test the URL I posted in bug 407500 to see if those two bugs are somewhat related ?

Confirming problem on http://kotaku.com/gaming/clips/dante-vs-nero-+-pew-pew-pew-331564.php with Linux version of Firefox 3 nightly build from 2008-02-28 (Mozilla/5.0
(X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008022804 Minefield/3.0b4pre).

When I hover the mouse cursor over the embedded video, mouse wheel doesn't
scroll. However, keyboard cursor keys still work for scrolling.

But what intriguies me, is that on the IKEA page mouse wheel scrolling has started working. I don't know if it's a change on the page or a fix in latest Firfox nightly builds (have any fixes been commited recently?). I think it's safe to mark this bug as a duplicate of bug 407500 since we've lost the testcase over here.

Bug 407500 is for MS Windows OS. The code that handles this code be quite different for Linux. So its best to have a separate bug for each OS.

Savvas Radevic (medigeek) wrote :

Hardy heron 8.04 alpha updated, 64-bit/amd64
Unfortunately this is not fixed in Firefox 3 beta 4. Cannot scroll the page while the mouse pointer is over flash content

$ apt-cache policy firefox-3.0 nspluginwrapper flashplugin-nonfree
  Installed: 3.0~b4+nobinonly-0ubuntu1
  Candidate: 3.0~b4+nobinonly-0ubuntu1
  Version table:
 *** 3.0~b4+nobinonly-0ubuntu1 0
        500 http://archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status
  Version table:
 *** 0
        500 http://archive.ubuntu.com hardy/multiverse Packages
        100 /var/lib/dpkg/status
  Version table:
 *** 0
        500 http://archive.ubuntu.com hardy/multiverse Packages
        100 /var/lib/dpkg/status

$ lsusb
Bus 003 Device 004: ID 046d:c016 Logitech, Inc. M-UV69a Optical Wheel Mouse

Changed in firefox-3.0:
status: Fix Released → Confirmed
Savvas Radevic (medigeek) wrote :

have a look at the followup of the mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=409669

Savvas Radevic (medigeek) wrote :

example: Place your mouse pointer over the flash "test" content at http://www.adobe.com/shockwave/welcome/
Use the scroll button of your mouse to scroll the page, whereas the up/down arrow keys work.

I can confirm that this flash video

trigger the bug again with:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4) Gecko/2008031317 Firefox/3.0b4

no wheel scrolling but keyboard works.

Marco Cimmino (cimmo) wrote :

unfortunetaly I can confirm with only *some* flash like this:

Firefox 3.0b4

Changed in firefox:
status: Unknown → Confirmed
Alexander Sack (asac) wrote :

... not a big issue, but indeed a bit annoying.

Changed in firefox-3.0:
importance: Undecided → Medium
mouse (mr.mouse) wrote :

this bug existent also on totem browser plugin (is that a different bug ?)

Alexander Sack (asac) on 2008-11-23
Changed in firefox-3.0:
status: Confirmed → Triaged
Tom (tom6) wrote :

still happens in firefox 3.0.4

personally i don't mind as i can move the mouse arrow outside the playback area and anyway i'd be happier if the scroll-wheel adjusted the volume when it's inside an animation/video. It is a little annoying i guess

Good luck all :)

bug still present in intrepid.
any chance to get this fixed?

is the linux equivalent of bug 483136 - a regression of bug 333166 with regression range per bug 407500 comment 9?

(In reply to comment #10)
> is the linux equivalent of bug 483136 - a regression of bug 333166 with
> regression range per bug 407500 comment 9?

Although this isn't a regression from bug 333166, it's likely the same issues: 1) a scroll event sent to the plugin does not get propagated to the browser.
2) scroll events are sent to the plugin even when scrolling begins with
   the mouse outside the plugin.

If the scrolling begins with the mouse outside the plugin, one thing that maybe could be done is to grab the pointer for the duration of scrolling, sending events to the window where scrolling started.

If the scrolling begins with the mouse over the plugin, then the user may be trying to scroll something in the plugin, so the plugin needs to receive the scroll event. If the plugin replies saying that it has consumed the event, then there is not much Gecko can do but assume that the plugin acted on the scroll event.

*** Bug 102573 has been marked as a duplicate of this bug. ***

*** Bug 407414 has been marked as a duplicate of this bug. ***

I am not sure this is a regression in Linux. It was suggested in bug 386687, comment 2 (the bug that spawned this one) that this is a very old bug (going back to 2001).

Furthermore, I used the testcase from bug 407500, comment 8 and could not find a build that scrolled correctly. This included the latest all the way back to the build listed below. Earlier than that, I couldn't get flash working.


Oh, I believe the testcase I used is cut down from the site below, which was stated to showcase the bug (comment 9).


Sorry. bug 386687, comment 2 linked incorrectly in the above post.

The problem only happens if the Flash Movie has the "wmode=window" (default), if the wmode is "opaque" or "transparent" the mouse wheel event is propagated the HTML on the right way. - that's the reason why the bug only happen on some pages...

The problem happens on FF3.6 for windows but not on the mac.

The flash object shouldn't capture the event even if it started inside the flash movie since any other browser does it and previous versions of Firefox also worked on a different way.

I hope this bug gets fixed soon.

Same problem is on https://www.bwin.com/liveBets.aspx. You can't scroll with the mouse wheel, but keyboard arrows work. Firefox has really big problems with handling flash web pages (classical Ctrl+t seems to be unsolvable).

(In reply to comment #11)
> If the scrolling begins with the mouse outside the plugin, one thing that maybe
> could be done is to grab the pointer for the duration of scrolling, sending
> events to the window where scrolling started.

Because the length of the grab would depend on a timeout, we should probably use a GrabModeSync pointer grab and XAllowEvents with SyncPointer so that we can ReplayPointer to send events that are not part of a scroll transaction to the right window.

GDK doesn't support synchronous grabs so we'd have to use Xlib directly.

Starting a GrabModeSync pointer grab asynchronously with XGrabPointer may work OK. XGrabButton could be used to start the grab synchronously on ButtonPress, if necessary.

Changed in firefox:
importance: Unknown → Medium
affects: firefox-3.0 (Ubuntu) → firefox (Ubuntu)
Changed in firefox:
status: Confirmed → Unknown
Changed in firefox:
status: Unknown → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.