Closed Bug 409669 Opened 17 years ago Closed 3 years ago

Mouse wheel scroll on some pages not working when pointer hovers over flash object

Categories

(Core :: Widget: Gtk, defect, P5)

Product:
Core
Component:
Widget: Gtk
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: aleksander.adamowski, Unassigned)

References

Details

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).
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.
I can confirm that this flash video http://kotaku.com/gaming/clips/dante-vs-nero-+-pew-pew-pew-331564.php 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.
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.
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. http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2004/12/2004-12-05-07-trunk/firefox-1.0+.en-US.linux-i686.tar.gz Oh, I believe the testcase I used is cut down from the site below, which was stated to showcase the bug (comment 9). http://kotaku.com/gaming/clips/dante-vs-nero-+-pew-pew-pew-331564.php
Sorry. bug 386687, comment 2 linked incorrectly in the above post.
See Also: → https://launchpad.net/bugs/50839
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. https://wiki.mozilla.org/Gecko:Mouse_Wheel_Scrolling#Mouse_wheel_transaction http://tronche.com/gui/x/xlib/input/XAllowEvents.html 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. http://tronche.com/gui/x/xlib/input/XGrabButton.html

Flash is no longer supported

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.