1239037 - [e10s] On first mouse wheel scroll, plugin is flashing and page scrolled

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect)

Description

[Alice0775 White]

On first mouse wheel scroll, plugin is flashing and page scrolled

Comment 1

[Alice0775 White]

Attachment: WheelTest.swf

Comment 2

[Alice0775 White]

Attachment: Bug1239037.html

Comment 3

[Alice0775 White]

Attachment: Bug1239037.html

Comment 4

[Alice0775 White]

Steps to reproduce:
1. Open attachment 8707024 [details]
2. Click white content area
3. Turn mouse wheel on the plugin

Actual Results:
plugin is flashing and page scrolled once

Expected Results:
Plugin should not be flashing. And page should not scroll.


Bug 1193055 does not seem to fix the problem.

Comment 5

[Benjamin Smedberg]

Jim, does your work on windowed-mode Flash fix this?

Alice, does this work properly if you set wmode="opaque" for the Flash?

Comment 6

[Jim Mathies [:jimm]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #5)
> Jim, does your work on windowed-mode Flash fix this?

This is a windowed plugin so you would expect the wheel events to get consumed by the applet and firefox wouldn't react to them. However some wheel events bleed through to the browser, and that's where things start to fall apart.

For non-e10s, some of the events go to the app, some go to firefox, so the page scrolls up slightly over time. Usually not far enough to move the app out from underneath the mouse.

For e10s, as soon as the first wheel even bleeds through, the plugin window is hidden. This lets even more events through to content causing the page to scroll faster. Eventually scrolling stops and the flash app reappears. What you see is a broken mixture of scrolling, flash consuming events, and window flicker as these systems fight against each other.

The central problem though is that wheel events get through windowed flash to content. If we could fix that, the other problems go away. I think the reason wheel events get through has to do with how we handle scroll wheel events as content passes under the mouse. Generally we don't want windowed plugins getting in the way of content scroll.

Masayuki, any thoughts here?

Comment 7

[Jim Mathies [:jimm]]

apz seems to help bit, it does a better job of delivering wheel events to the applet vs. scrolling content. It's still pretty broken though.

Comment 8

[Alice0775 White]

Attachment: Bug1239037_wmode=opaque.html

Comment 9

[Alice0775 White]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #5)
> 
> Alice, does this work properly if you set wmode="opaque" for the Flash?

Setting wmode="opaque" fixes this problem.

Comment 10

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

Sorry for the delay.

Although, I don't understand well, is this reproducible without APZ?

> The central problem though is that wheel events get through windowed flash to content. If we could
> fix that, the other problems go away. I think the reason wheel events get through has to do with
> how we handle scroll wheel events as content passes under the mouse. Generally we don't want
> windowed plugins getting in the way of content scroll.

I think that it's possible because I made a new path to post wheel events as default action of Gecko to windowless plugin (bug 376679). So, we can send wheel events to windowed mode too (we need to write a new path for windowed mode, use PostMessageW()). But this needs a big change in WinMouseScrollHandler.cpp. So, I cannot work on this in Q1. Perhaps, I can do it in Q2. (I think that we need to fix bug 1234958 before this)

Comment 11

[Jim Mathies [:jimm]]

Ok, so this is kinda broken in both e10s and non-e10s. It's worse in e10s because once we hide the window to scroll, wheel events get delivered to content and the page jumps. But this is also a problem in non-e10s which exhibits the same behavior.

Comment 12

[Paul Pasca[Away. Please needinfo? Paul Oiegas [:pauloiegasSV]]]

Hi Alice,

I want to preform a regression on this issue, but I'm not sure what test case to use, since each one behaves different. The attachment from comment 1 works correctly on both e10s and non-e10s.
On the attachment form comment 3 and comment 4, this issue reproduces on both e10s and non-e10s.
The attachment from the comment 8 works correctly again on both e10s and non-e10s.

I've tested this on a Windows 7 x32, on latest release(44.0) and latest Nightly(47.0a1).

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20160123151951

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160126030244

Which test case should I use to perform a regression?  Is this still a valid bug, or did Benjamin's comment helped you solve the problem? Two of the three provided test cases don't reproduce the issue.

Thanks,
Paul.

Comment 13

[Jim Mathies [:jimm]]

I can reproduce this using the Bug1239037.html test case and e10s, e10s+apz, and non-e10s.

Comment 14

[Alice0775 White]

(In reply to PaulMircea from comment #12)
> Hi Alice,
> 
> Which test case should I use to perform a regression?
attachment 8707019 [details] of comment 1 is not testcase, just data for the comment 2 and comment 3.
attachment 8707020 [details] of Comment 2 is reproducible testcase.
attachment 8707024 [details] of Comment 3 is workaround.

So, you should use attachment 8707019 [details] of comment 1.

>  Is this still a valid
> bug, or did Benjamin's comment helped you solve the problem? Two of the
> three provided test cases don't reproduce the issue.
> 

You should follow STR of comment 4.
And yes, this is still valid bug. I can reproduce with e10s, but not non-e10s.

Comment 15

[Paul Pasca[Away. Please needinfo? Paul Oiegas [:pauloiegasSV]]]

I was not able to find a regression window for this issue. I went back as far as Firefox 13 and the issue still reproduces. Firefox 12 and previous versions crash on start, so I was not able to test on older versions than 13.

Considering this, I will remove the "regression, regressionwindow-wanted" keywords. Seams like this was a bug in Firefox all along.

Comment 16

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

I realized that this is a problem of high resolution scroll vs. Flash Player.

Flash Player doesn't support high resolution scroll yet. Therefore, the swf does *NOT* consume posted WM_MOSUEWHEEL message if the scroll amount is less than 0. That's the why turning mouse wheel on the swf causes scroll the whole page.

Additionally, I see flashing swf content always if I scroll the page intentionally. So, there are two bugs:

1. Flashing swf content by scroll as the summary explained.
2. Some mouse wheel message is consumed by Flash Player but not all mouse message.