1255856 - [e10s] Flash Plugin repaint failure after scroll page with scrollbar thumb

Status: VERIFIED FIXED

(Core :: Panning and Zooming, defect)

Description

[Alice0775 White]

Build Identifier:
https://hg.mozilla.org/mozilla-central/rev/102886e9ac63b3fa33a6f1b394aea054abce2dfd
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0 ID:20160311030233


Reproducible: always

Steps To Reproduce:
1. Reduce browser height to 500px so that the vertical scroll bar is displayed
2. Open http://edition.cnn.com/2014/11/23/showbiz/music/katy-perry-super-bowl/index.html?hpt=en_bn1
     OR http://emk.name/test/swftxt.html
3. Drag scrollbar thumb up or down and release mouse button outside of the browser window

Actual Results:
Plugin repaint fails
See screencast https://www.youtube.com/watch?v=rLH5ODsy_pk

Graphics
--------

Adapter Description: AMD Radeon HD 6450
Adapter Drivers: aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64
Adapter RAM: 1024
Asynchronous Pan/Zoom: wheel input enabled; touch input enabled
ClearType Parameters: Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 300
Device ID: 0x6779
Direct2D Enabled: true
DirectWrite Enabled: true (6.2.9200.17568)
Driver Date: 7-28-2015
Driver Version: 15.200.1062.1003
GPU #2 Active: false
GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC)
Subsys ID: 23111787
Supports Hardware H264 Decoding: Yes
Vendor ID: 0x1002
WebGL Renderer: Google Inc. -- ANGLE (AMD Radeon HD 6450 Direct3D11 vs_5_0 ps_5_0)
windowLayerManagerRemote: true
AzureCanvasAccelerated: 0
AzureCanvasBackend: direct2d 1.1
AzureContentBackend: direct2d 1.1
AzureFallbackCanvasBackend: cairo

Comment 1

[Alice0775 White]

Attachment: screenshot

Comment 2

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=412c5cae8dea7b52da7c6981eec6a2a2884897c9&tochange=cd65b31bdeb565c34ae8e9d56107289ce71d9885

Regressed by Bug 1253860

Comment 3

[Alice0775 White]

FYI, Bug 1255705 does not fix this problem

Comment 4

[Kartikaya Gupta (email:[e-mail])]

I'm not able to reproduce this on either the March 11 build or the latest nightly. When I scroll the page the flash plugin remains in the right place always - in your screencast it looks like it lags behind the scroll position and I'm not seeing that. Do you have any other prefs set that might be affecting this?

Comment 5

[Alice0775 White]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #4)
> I'm not able to reproduce this on either the March 11 build or the latest
> nightly. When I scroll the page the flash plugin remains in the right place
> always - in your screencast it looks like it lags behind the scroll position
> and I'm not seeing that. Do you have any other prefs set that might be
> affecting this?

The problem is reproduced with new profile.

Comment 6

[Alice0775 White]

And also I can reproduce the problem(Comment 1) with Windows10 ip build 14279 on VM.

https://hg.mozilla.org/mozilla-central/rev/f0c0480732d36153e8839c7f17394d45f679f87d
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0 ID:20160314030215

Graphics
--------

Adapter Description: VMware SVGA 3D
Adapter Drivers: vm3dum64 vm3dum64_10 vm3dum vm3dum_10
Adapter RAM: 1024
Asynchronous Pan/Zoom: wheel input enabled; touch input enabled
Device ID: 0x0405
Direct2D Enabled: Blocked for your graphics card because of unresolved driver issues.
DirectWrite Enabled: false (10.0.14279.1000)
Driver Date: 10-16-2015
Driver Version: 8.15.1.33
GPU #2 Active: false
GPU Accelerated Windows: 1/1 Direct3D 11 WARP (OMTC)
Subsys ID: 040515ad
Supports Hardware H264 Decoding: No; Hardware video decoding disabled or blacklisted
Vendor ID: 0x15ad
WebGL Renderer: Blocked for your graphics card because of unresolved driver issues.
windowLayerManagerRemote: true
AzureCanvasAccelerated: 0
AzureCanvasBackend: skia
AzureContentBackend: cairo
AzureFallbackCanvasBackend: cairo

Comment 7

[Kartikaya Gupta (email:[e-mail])]

I was able to reproduce it today on a local build. No idea what changed between yesterday and today though. I think the problem is that when dragging the scrollbar, we do a bunch of instant scrolls, and so the code to hide plugins on scroll doesn't kick in (that only kicks in for smooth scrolls on the main thread).

With my patches, these "instant main-thread scrolls" don't trigger a repaint but instead go through APZ, so the windowed plugin ends up getting left behind and repaints badly.

I think the two options here are to (1) disable the paint-skipping if there are windowed plugins on the page or (2) hide the plugins if we're doing a bunch of apz scrolls. (2) would be nicer in terms of perf but probably harder to implement since it's hard to tell when to start/stop the plugin hiding.

Comment 8

[Kartikaya Gupta (email:[e-mail])]

I think (2) is almost impossible to implement well, because it happens with other types of scrolling as well - autoscroll, for example, or keyboard arrow scrolling with the smooth scrolling option disabled. So option (1) is probably the way to go.

Comment 9

[Kartikaya Gupta (email:[e-mail])]

Attachment: Disable paint-skipping if we have windowed plugins

r? to jimm for reusing the plugin-callback machinery he added, and r? to mstange for the paint-skipping integration.

Comment 10

[Jim Mathies [:jimm]]

So prior to bug 1253860 we triggered paints for these scrolls? (A thumb drag would trigger numerous paints of content?)

If that was the case, each of those paints would generate a layer tree update plus updated plugin data, which gets pushed over to the compositor where plugin data gets applied. With bug 1253860 the paints stopped and so plugins got stuck in content.

If this is correct this bug is very similar to bug 1229429, which is another case where we compose the window without receiving layer tree updates after a tab switch. The only difference, in bug 1229429 the metric that changes is visibility, in this bug window position changes.

Comment 11

[Jim Mathies [:jimm]]

Comment on attachment 8730778 [details] [diff] [review]
Disable paint-skipping if we have windowed plugins

Review of attachment 8730778 [details] [diff] [review]:
-----------------------------------------------------------------

Approving. Scrolling is going to be slower with plugin windows no matter what. The long term fix is to kill windowed plugins off.

Comment 12

[Kartikaya Gupta (email:[e-mail])]

(In reply to Jim Mathies [:jimm] from comment #10)
> So prior to bug 1253860 we triggered paints for these scrolls? (A thumb drag
> would trigger numerous paints of content?)

Yes.

> If that was the case, each of those paints would generate a layer tree
> update plus updated plugin data, which gets pushed over to the compositor
> where plugin data gets applied. With bug 1253860 the paints stopped and so
> plugins got stuck in content.

I believe that's correct, yeah.

> If this is correct this bug is very similar to bug 1229429, which is another
> case where we compose the window without receiving layer tree updates after
> a tab switch. The only difference, in bug 1229429 the metric that changes is
> visibility, in this bug window position changes.

Do we not repaint and push over a new layer tree to the compositor on tab switch? I remember rumblings about caching more layer trees in the compositor but I thought that hadn't been implemented yet.

Comment 13

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/8f609479ba37

Comment 14

[Jim Mathies [:jimm]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #12)
> (In reply to Jim Mathies [:jimm] from comment #10)
> > If this is correct this bug is very similar to bug 1229429, which is another
> > case where we compose the window without receiving layer tree updates after
> > a tab switch. The only difference, in bug 1229429 the metric that changes is
> > visibility, in this bug window position changes.
> 
> Do we not repaint and push over a new layer tree to the compositor on tab
> switch? I remember rumblings about caching more layer trees in the
> compositor but I thought that hadn't been implemented yet.

There's work on this taking place currently in bug 1176019. George is aware of the possible fallout for windowed plugins.

I'd like to try and find a way to fix this without new layer updates coming over. We have all the plugin data cached in the LayerTreeState data. The trick is figuring out when to send that over to the main thread. (CompositorParent blocks composition waiting for an ack from the child for each update so we want to avoid this as much as possible.) I've been thinking about possible solutions while looking at bug 1229429. If you have any ideas I'd love to hear them.

Comment 15

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/8f609479ba37

Comment 16

[Kartikaya Gupta (email:[e-mail])]

Not really sure why this is marked m9+, it's a regression from bug 1253860 and affects 48 only.

Comment 17

[Petruta Horea [:phorea], Desktop QA]

Verified as fixed using Firefox 48 beta 2 under Win 10 64-bit.