611223 - [mac] Scrolling over embedded YouTube videos content doesn't work

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect)

Description

[Philipp von Weitershausen [:philikon]]

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.

Comment 1

[juan becerra [:juanb]]

This looks to be a duplicate of bug 483136.

Comment 2

[Philipp von Weitershausen [:philikon]]

(In reply to comment #1)
> This looks to be a duplicate of bug 483136.

Except it works in Firefox 3.5 and 3.6...

Comment 3

[Ed Lee :Mardak]

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.

Comment 4

[Martijn Wargers (dead)]

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.

Comment 5

[Ed Lee :Mardak]

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.

Comment 6

[Ed Lee :Mardak]

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.

Comment 7

[Philipp von Weitershausen [:philikon]]

(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)

Comment 8

[Eli Greenberg]

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

Comment 9

[simon]

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

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 11

[Steven Michaud [:smichaud] (Retired)]

(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 :-)

Comment 12

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 13

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 14

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

> 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...

Comment 15

[Olli Pettay [:smaug][[e-mail]]]

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).

Comment 16

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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

Comment 17

[Benjamin Smedberg]

Youtube is no longer using Flash. WFM.