User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0 Build ID: 20150122214805 Steps to reproduce: I attach example files to the issue, anyway to reproduce: 1. Create flash movie with some transparent places/background 2. Insert flash movie to the HTML and add wmode=transparent parameter to the flash object code 3. Make flash object position fixed and scroll down website In the archive you will also find screenshot, where you can see how transparent background of flash movie flickers during scrolling up and down. Actual results: In transparent places of flash object, while scrolling down, background of website is flickering, looks like some bug with transparent places rendering. Expected results: In transparent places of flash object, while scrolling down, just proper transparency should be dispayed, well you should simple see through the transparent parts of flash movie.

Firefox: 35.0.1 Shockwave Flash 16.0.0.296 Shockwave Flash 16.0 r0 Last updated 2015.01.25 File: NPSWF32_16_0_0_296.dll Other browsers (Chrome, IE) render the background transparency properly - item parts are transparend and do not flicker while scrolling.

This seemed to be fixed in Beta36+. Could you test with latest Beta36[1], Dev37.0a2[2] and Nightly38.a2[3]? [1] https://www.mozilla.org/en-US/firefox/channel/#beta [2] https://www.mozilla.org/en-US/firefox/channel/#developer [3] https://nightly.mozilla.org/

Aha, I can reproduce the problem on Firefox 34 and 35 with/without HWA, and Firefox Beta36, Dev37.0a2 and Nightly38.a2 without HWA. Pushlog : https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=6eded676da83&tochange=9b44cf686aba Regressed by: Bug 947781

More flash web breakage to add to the OMTC ReadbackLayer regressions from 34.

Not sure I care enough about disabled HWA to continue the tracking for this bug.

[Tracking Requested - why for this release]:(In reply to Sylvestre Ledru [:sylvestre] from comment #5) > Not sure I care enough about disabled HWA to continue the tracking for this > bug. It is reproduced with Blocked GPU. So, I think this should be tracked.

OK. Anyway, I don't think anything is going to happen for 36.

(In reply to Alice0775 White from comment #6) > [Tracking Requested - why for this release]:(In reply to Sylvestre Ledru > [:sylvestre] from comment #5) > > Not sure I care enough about disabled HWA to continue the tracking for this > > bug. > > It is reproduced with Blocked GPU. > > So, I think this should be tracked. Note it's only reproduced with a blocked GPU on Windows XP for 37. We now use D3D11 with WARP when the GPU is blocked on Win7+ (sadly, yes, this means layers.acceleration.disabled gives you different behavior than a blocked GPU on Win7+).

The shift you see, which for the record for me occurs with hardware acceleration on as well, is expected behavior as far as I can tell. It occurs because of the readback layer asynchronously being updated from the layer in front of it. This is more or less intended behavior I believe, it'd be interesting for Roc to weigh in to see if he agrees.

I agree with your diagnosis. We have the option of using alpha recovery instead, to produce an RGBA bitmap for the Flash object. That would eliminate this problem --- for static Flash objects. Basically if the background is changing but the Flash is not, alpha recovery works well. If the Flash is changing but the background is not, readback works well. If they're both changing there's not much we can do... Andrius, in the actual site where you encountered this issue, is the Flash object animated or not?

Hello. Flash object is animated. Background is not. But flash object has fixed position and flickering appears when you are scrolling background. Well this is connected to displaying ads on website. Floating ad has fixed position on website in front of website. And transparent parts of that flash layer are displayed inproperly while scrolling website. Hope it helps.

Bas, is this actionable?

(In reply to Milan Sreckovic [:milan] from comment #12) > Bas, is this actionable? From my own assessment and Roc's agreeing with me I feel that it is not.

Lawrence, we can stop tracking this? I don't know if we need a user communication about this, not sure what we do there for "won't fix" things.

I don't think we need to publish anything more about this than noting that this is wontfix in the bug (which we've done.) Thank you for following up on this bug. I've marked the releases that were previously marked as affected as wontfix.