After landing Bug 1137944, a bad effect appears. it is worse than before landing it. Steps to reproduce: 1. Open testcase or http://uz.zgora.pl/index.php?pl 2. Turn mouse wheel Actual Results: The flash plugin disapares while page is scrolling. And the flash plugin re-appears when stop page scrolling Actual Results: Should not flicker(disappear/appear) Regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=2a51d8766dfbfd272518ab3a47d2ca5f452dc971&tochange=e1e281f04f27 Regressed by Bug 1137944

testcase

This is currently "by design", unless we decided to revisit the decision. I think we'll probably end up discussing this more in december at the next summit.

this is now implemented in layout.

(In reply to Jim Mathies [:jimm] from comment #4) > This is currently "by design", unless we decided to revisit the decision. I > think we'll probably end up discussing this more in december at the next > summit. This is really something not pleasant. The main issue here is that the flickering is attracting the eye a lot.

Has it been mentioned that if you turn off HWA in Flash (HWA can still be left on in Fx) you don't get any flickering or the flash video box becoming white/black when scrolling?

The test URL given flashes but that might be caused by the fact that the Settings option is grayed out. Perhaps it's hard coded to use HWA. If you play the videos over at weather.com with Flash HWA off you will see no flashing. With HWA on you will.

Disabling HWA doesn't work for me. When I scroll (using mouse) the flash window is turning black and returns to normal when I finish scrolling, even with HWA disabled.

I(In reply to Bartosz Piec from comment #11) > Disabling HWA doesn't work for me. When I scroll (using mouse) the flash > window is turning black and returns to normal when I finish scrolling, even > with HWA disabled. I was using beta version 20.0.0.285 and it worked with that. I just started using the new stable version 20.0.0.286 (which btw fixes some flash crashes) and disabling HWA in Flash doesn't work anymore to fix the video box going block when scrolled. However, if I disable e10s and turn off Flash HWA it works. Scrolling is smooth and the video keeps playing when scrolling. Scrolling is really atrocious with e10s disabled and Flash HWA enabled. Eventually e10s will be the default so I guess there won't be a pref to turn it off. It seems to me that this whole problem could potentially be solved with a little more research. Lots of Flash stuff on other sites work just fine with e10s and HWA enabled.

Jim... Do you think this problem can be resolved without blanking out some flash videos as is currently the case? This action can be annoying.

(In reply to Gary [:streetwolf] from comment #15) > Jim... Do you think this problem can be resolved without blanking out some > flash videos as is currently the case? This action can be annoying. No, don't think so. I'm currently looking at replacing them with window captures in bug 1232181 as an improvement. Eventually (a year from now?) we're going to deprecate windowed plugins completely and all these crazy windowed plugin problems go away.

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0 Build ID: 20160207004019 Reproducible also on the latest Aurora 46.0a2 on Windows 10.

- I was able to reproduce this issue on Firefox Firefox 47.0a1 (2016-02-24), Firefox 46.0a2 (2016-02-24) and Firefox 45 beta 9 with e10s enabled under Windows 10 64-bit and Ubuntu 12.04 32-bit. - Encountered this issue while scrolling on: http://www.bbc.com/news/world-europe-34332759 http://www.dailymotion.com/video/x3qq2se_11-artists-who-shockingly-don-t-have-grammys_news - Mac platform is not affected.

We're going to live with this.

This is very bad news since e10s will be enabled by default. I hope it will be possible to turn it off, at least until flash is not dead.

What is the rationale behind the decision ? This is one of the small things that make the experience quite not smooth and hurt the eyes.

Looking at the duplicates count we can also feel this is not an edge case.

There's no easy fix here. Window placement needs to be managed by the browser main thread which can only receive async messages from the compositor. There's a pref that turns this off but I don't think it's hooked up to apz yet. I can try to get that working. You'll end up with laggy plugin window updating though, which looks worse.

I agree this would look ugly as well. So there is no solution with e10s to make it work nicely?

Tracking so we will be sure to keep an eye on this for 49+ if it isn't resolved for 48. The duplicate reports here seem worrisome as that means the problem may be widespread.

Actually since the entire bug is wontfixed, I'll stop tracking this. If we see widespread complaints when we release e10s to more users then we will surely notice from more bug reports or from SUMO.

Removing tracking flags for all branches per Comment 34.

No longer reproduces on Fx 53b8, Ubuntu 16.04 x86.

Flash v25.0.0.127, forgot to mention.

This issue is still reproducible on Firefox 54.0.1 (64 bit) in a Windows 10 VM with the Flash Player 26.0.0.131 (debug version). But I'm not able to reproduce this issue anymore on Linux but the Flash Player (NPAPI) got there more or less recently a major update. I remember that it was claimed that this version does not target to support all new hardware acceleration features which the PPAPI version does if I'm not wrong. Maybe hardware acceleration is limited for the NPAPI version now even more than the previous version 11.2.202.x. Also I'm noticing a significant perfomance impact as pointed out in bug #1378071 which could be an indication for this theory. Assuming this theory is true we would have to wait until the subset of the PPAPI is ready to support the PPAPI version of the Flash Player (I think project Mortar does target this if it hasn't been abandoned) which would increase the performance again but also reintroduce the flickering.