This is 4.0b7 and current nightlies. Take a site like http://boingboing.net that embeds YouTube videos and try to scroll down. Once the mouse cursor hits one of the embedded videos, scrolling stops working and you have to move the mouse off the plugin area to continue. So far I've only been able to reproduce this with embedded YouTube videos of that kind (e.g. on arstechnica and other places). Other Flash content seems fine.

This looks to be a duplicate of bug 483136.

(In reply to comment #1) > This looks to be a duplicate of bug 483136. Except it works in Firefox 3.5 and 3.6...

Requesting blocking as this is a separate bug from bug 483136, as this bug is a new regression in Firefox 4. http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=aa800589db70&tochange=07e74f1f0561 Bug 519100? - implement scroll wheel events for Cocoa NPAPI (NPCocoaEventScrollWheel) The URL (data uri) is just a youtube embed that prevents scrolling from working in builds since 20091109.

The testcase doesn't work for me, using: Mozilla/5.0 (Windows; U; Windows NT 6.1; nl; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 So for me, it's not a recent regression since Firefox 4.

philiKON: Did you test this on other platforms when you initially filed the bug or your default bug template uses All/All? This wasn't newly regressed for Windows on 20091109.

mw22: Yeah I can confirm that it's broken on Windows for 3.6.13 and 3.5.16. It seems like there's an underlying plugin issue that is affecting all platforms, but perhaps the change from bug 519100 is making OS X Firefox acting more like the Windows version and hitting the same bug. So for OS X users upgrading to Firefox 4, this would be a new regression.

(In reply to comment #5) > philiKON: Did you test this on other platforms when you initially filed the bug > or your default bug template uses All/All? This wasn't newly regressed for > Windows on 20091109. Yeah, this is probably OSX only (my default bug template is All/All)

I can confirm this is a problem on Mac OS X. Any ideas when it might be fixed?

now I remember why I went back to FF 3.6. any solution available?

Stephen, I have a feeling you know what's going on here :-)

(In reply to comment #10) Off the top of my head, I'd say that at least some of the behavior described here is not a bug but a feature. But I need to dig into the example given here, plus whatever others I can find, and test in different browsers on different OSes, before I'll really know what's going on. Which will take a while :-)

OK, I've now started looking at this in more detail, and it's *enormously* more complicated than I first realized. There's also no consensus among different browser vendors about how the underlying problem should be solved. Masayuki Nakano's working on the Windows equivalent of this bug (bug 483136), and is having a hard time of it. But his understanding of the issues is clearly much more advanced than mine is. So I'm going to say we shouldn't do anything about this bug until Masayuki's work is finished, and his patch for bug 483136 has had a chance to bake for a while. Then I can try to port Masayuki's solution from Windows to OS X. Here's the underlying problem, as I currently understand it: On the one hand, we should pass events to plugins that belong to them. Surely this should include scroll events that take place when the mouse is over the plugin, whether or not the plugin is focused -- many plugins can have scrollable contents. And surely if a plugin's contents are scrolled, the page that contains the plugin shouldn't also be scrolled. But on the other hand, many plugins' contents' *aren't* scrollable (whether or not their contents might sometimes be scrollable). And it's annoying to have a browser page stop scrolling when the mouse wheel brings the mouse over a plugin, particularly when a page contains many plugins. One possible solution is for the browser to always send scroll events to a plugin whenever the mouse is over that plugin, and for the plugin to somehow communicate to the browser whether or not it's "using" these events. If plugin is "using" the scroll events, the browser should allow the plugin to eat them. If the plugin isn't "using" them, the browser should re-route them to the next object up than can handle them appropriately.

The reason FF 3.6.X doesn't have this bug is that it never sends any scroll events to plugins (testing with FF 3.6.17 on OS X 10.5.8). Clearly this is wrong.

> One possible solution is for the browser to always send scroll events > to a plugin whenever the mouse is over that plugin, and for the plugin > to somehow communicate to the browser whether or not it's "using" > these events. If plugin is "using" the scroll events, the browser > should allow the plugin to eat them. If the plugin isn't "using" > them, the browser should re-route them to the next object up than can > handle them appropriately. Yeah, that's ideal. However, there are complex issues. First of all, I'm not sure the Cocoa's plugin event model. Can we detect whether the plugin consumes the scroll event or not? If we couldn't do it, this idea were not implemented. Current my idea of improving this issue is: 1. Don't redirect scroll event to plugin in widget level. 2. Dispatch normal scroll event on the document under the mouse cursor. 3. When the scroll event reaches a plugin, send native scroll event to the plugin via widget. But if the DOM event were already consumed, we shouldn't do it. 4. nsEventStateManager shouldn't scroll any scrollable element even if the DOM event were not consumed. 5. After that, widget might be receive internal scroll event from child process when the plugin didn't consumed it. This time, widget dispatches a new event for ESM and ESM scrolls something which isn't scrolled by #4. But this idea have a issue. Even if the DOM event was consumed by after the plugin (i.e., in bubbling phase), ESM would scroll something when the plugin didn't consume it. I think that this issue isn't as important as current buggy behavior. So, I think I should write the patch ASAP...

I don't understand why step 5 is needed? ESM scrolls in PostHandleEvent which happens after DOM event dispatch. Also, I think step 3 should happen when nsObjectFrame::HandleEvent is called (it happens between default and system event group).

I think nsObjectFrame sends events to plugin asynchronously and nsObjectFrame doesn't receive any event result, no?

Youtube is no longer using Flash. WFM.