1312242 - Missing transparency in Adobe Flash objects with wmode="transparent"

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect)

Description

[Dmitry]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID: 20161019084923

Steps to reproduce:

Open any page with embeded flash object with wmode="tansparent"


Actual results:

Flash object rendered without transparency.


Expected results:

Flash object backgroung should be transparent.

Comment 1

[Dmitry]

49.0.1 works fine. 49.0.2 have this bug

Comment 2

[Loic]

It's probably due to bug 1229961 enabled in FF49.
Could you type about:config in the location bar and set dom.ipc.plugins.asyncdrawing.enabled to false, then restart Firefox to apply and test again. Does it work normally?

Comment 3

[Alice0775 White]

Attachment: testcase

Comment 4

[Alice0775 White]

Attachment: screenshot

Comment 5

[Dmitry]

Yes. Now it works normally.

(In reply to Loic from comment #2)
> It's probably due to bug 1229961 enabled in FF49.
> Could you type about:config in the location bar and set
> dom.ipc.plugins.asyncdrawing.enabled to false, then restart Firefox to apply
> and test again. Does it work normally?

Comment 7

[Liviu Cirdei]

I can confirm this issue is reproducible on Firefox 49.0.2 (Build ID 20161019084923 - both 32/64-bit builds) with  Flash 23.0.0.185 on the following OS-es and Graphics:
 
- Windows 10x64 - Intel(R) HD Graphics
- Windows 10x64 - AMD Radeon HD 5450
- Windows 7x64 - NVIDIA GeForce 210

If I set dom.ipc.plugins.asyncdrawing.enabled to false the issue is no longer reproducible.

The issue is not reproducible at all on Mac OS X 10.12 - Intel Iris Pro 1536 MB.

Comment 8

[mtalistu]

If I add the following to the <object> tag for the SWF, then the transparency works as expected:

      <param name="bgcolor" value="#ffffff" />

I believe this is something that is passed along to the SWF and shouldn't affect Firefox's layout/display of the object, so I will continue investigating this issue from our end.

Comment 9

[Maciej Jaros]

Adding `bgcolor` param resolves the issue. Color specified don't have to match the color of actual background used in Flash. So adding `bgcolor` param is a good workaround.

Comment 10

[Milan Sreckovic [:milan] (needinfo for best results)]

Bas, is this something we can fix on the graphics side, or is it more of a layout?

Comment 12

[Bas Schouten (:bas.schouten)]

(In reply to Milan Sreckovic [:milan] from comment #10)
> Bas, is this something we can fix on the graphics side, or is it more of a
> layout?

Almost certainly seems to be layout.

Comment 16

[Marcia Knous [:marcia]]

[Tracking Requested - why for this release]: Moving over the tracking flags from the duplicate bug.

Comment 17

[Matt Woodrow (:mattwoodrow)]

This doesn't seem to be a layout issue, I believe it's in Flash.

The shmem surfaces we allocate start out as transparent (all 0's), but contain opaque content when they get returned by the plugin.

Setting a value for bgcolor hits all the same code paths within gecko, but the surfaces returned from the plugin now contain transparent content.

It doesn't look like gecko parses the bgcolor value at all, just forwards it directly to the plugin.

I guess we could inject a value for this ourselves if one isn't specified, since it doesn't seem to actually render the color and fixes the bug.

What do you think Jim?

Comment 18

[Gerry Chang [:gchang]]

Track 51+ as regression.

Comment 19

[Jim Mathies [:jimm]]

(In reply to Matt Woodrow (:mattwoodrow) from comment #17)
> This doesn't seem to be a layout issue, I believe it's in Flash.
> 
> The shmem surfaces we allocate start out as transparent (all 0's), but
> contain opaque content when they get returned by the plugin.
> 
> Setting a value for bgcolor hits all the same code paths within gecko, but
> the surfaces returned from the plugin now contain transparent content.
> 
> It doesn't look like gecko parses the bgcolor value at all, just forwards it
> directly to the plugin.
> 
> I guess we could inject a value for this ourselves if one isn't specified,
> since it doesn't seem to actually render the color and fixes the bug.
> 
> What do you think Jim?

This sounds like a reasonable one-off fix. Adobe is also looking into this on their end.

Matt (Talistu) do you see any issues with this work around?

Comment 20

[mtalistu]

I attempted a similar fix on our end in the plugin code. While it fixed the test case in this bug report, we had a few other cases where the fix didn't resolve all transparency issues (for example: http://www.stpauls.w-berks.sch.uk/ still had some issues with the transparent SWFs after my fix) 

Adding the "bgcolor" param seems like a valid partial fix, but I will need to do some more investigation on our end to fix every case, it seems.

Also, we have locked down our upcoming November release, so we won't be able to ship my fix (partial or otherwise) until our December release at the earliest. Not sure if that affects whether you want to attempt something on the browser side to get a partial fix out to users earlier than that.

Comment 21

[Jim Mathies [:jimm]]

(In reply to mtalistu from comment #20)
> I attempted a similar fix on our end in the plugin code. While it fixed the
> test case in this bug report, we had a few other cases where the fix didn't
> resolve all transparency issues (for example:
> http://www.stpauls.w-berks.sch.uk/ still had some issues with the
> transparent SWFs after my fix) 

Hmm, if I'm seeing the same issue you are (a drawing anomaly in the hopscotch game) www.stpauls.w-berks.sch.uk looks like a different problem? 

> Adding the "bgcolor" param seems like a valid partial fix, but I will need
> to do some more investigation on our end to fix every case, it seems.

I'll put a try build together with the bgcolor fix and get QA to take it for a spin. Lets find out how much the fix helps.

> Also, we have locked down our upcoming November release, so we won't be able
> to ship my fix (partial or otherwise) until our December release at the
> earliest. Not sure if that affects whether you want to attempt something on
> the browser side to get a partial fix out to users earlier than that.

Thanks for the update Matt, this is useful to know.

Comment 22

[Alice0775 White]

Attachment: Bug 1312242 testcase2 - Missing transparency in Adobe Flash objects with wmode=“transparent”.zip

Comment 23

[Jim Mathies [:jimm]]

Attachment: bgcolor testing patch

Comment 24

[Jim Mathies [:jimm]]

Attachment: bgcolor testing patch

Comment 25

[Jim Mathies [:jimm]]

Attachment: bgcolor testing patch

Comment 26

[Jim Mathies [:jimm]]

try builds - 
https://treeherder.mozilla.org/#/jobs?repo=try&revision=d3569bc26272bfe0302fe6840bd5b1922df92ac4

Comment 30

[Jim Mathies [:jimm]]

Comment on attachment 8806702 [details] [diff] [review]
bgcolor testing patch

This address a majority of these painting bugs. Lets go ahead and get this landed. We can always back this out if adobe finds a better fix on their side of things down the road.

Comment 31

[(No longer employed by Mozilla) Aaron Klotz]

Comment on attachment 8806702 [details] [diff] [review]
bgcolor testing patch

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

::: dom/plugins/ipc/PluginModuleParent.cpp
@@ +2732,5 @@
> +      if (supportsAsyncRender) {
> +        NS_NAMED_LITERAL_CSTRING(bgcolorAttributeName, "bgcolor");
> +        NS_NAMED_LITERAL_CSTRING(bgcolorAttributeDefault, "#FFFFFF");
> +        auto bgcolorAttributeIndex =
> +            names.IndexOf(bgcolorAttributeName, 0, comparator);

Could you use nsTArray::Contains here for better readability?

Comment 32

[Tracy Walker [:tracy]]

With Jim's try build at https://ftp.mozilla.org/pub/firefox/try-builds/[e-mail]-d3569bc26272bfe0302fe6840bd5b1922df92ac4/try-win32/ and

Shockwave Flash

    File: NPSWF32_23_0_0_205.dll
    Path: C:\Windows\system32\Macromed\Flash\NPSWF32_23_0_0_205.dll
    Version: 23.0.0.205
    State: Enabled
    Shockwave Flash 23.0 r0

This works for me.  Mouse cursor was correctly positioned over table play buttons even after resizing the table window to larger and/or smaller than default size.

Comment 33

[reginaldlather]

I have the same issue with Firefox 49.0.2 and 50.0. With 'wmode', 'transparent', removed from javascript it works fine with 'wmode', 'transparent', included. Flash player 23.0.0.205. However I have no animation, the fault appears the moment content is loaded.

Comment 35

[Marcia Knous [:marcia]]

Tracking 52+ for this regression involving painting.

Comment 36

[Jim Mathies [:jimm]]

Attachment: bgcolor patch

updated per comments

Comment 37

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/0b21bc7c6cb0
Provide a default bgcolor flash var. Addresses a background transparency problem with transparent flash and async painting. r=aklotz

Comment 38

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/0b21bc7c6cb0

Comment 41

[Gerry Chang [:gchang]]

Hi :jimm,
Is this worth uplifting to 51 aurora?

Comment 42

[Jim Mathies [:jimm]]

(In reply to Gerry Chang [:gchang] from comment #41)
> Hi :jimm,
> Is this worth uplifting to 51 aurora?

we might, haven't decided yet.

Comment 43

[reginaldlather]

Jim, Similar to 1311867, I've noticed that with an Adobe Captivate presentation that is password protected (and Adobe feature apparently), textbox for password will not accept focus until you navigate to another tab and then back again. Does the fixing of this bug also address this type of scenario or do I need to raise a separate bug.. Also, when is Firefox 52 likely to land with the general public?

Comment 44

[Jim Mathies [:jimm]]

(In reply to reginaldlather from comment #43)
> Jim, Similar to 1311867, I've noticed that with an Adobe Captivate
> presentation that is password protected (and Adobe feature apparently),
> textbox for password will not accept focus until you navigate to another tab
> and then back again. Does the fixing of this bug also address this type of
> scenario or do I need to raise a separate bug.. Also, when is Firefox 52
> likely to land with the general public?

Depends, if the focus issue is painting related, it might be. I would suggest filing a separate bug though to be sure, this bug is closed out so no additional work will happen here. Also, to confirm your focus issues is tied to async plugin painting, you can try with 'dom.ipc.plugins.asyncdrawing.enabled' enabled and disabled to see where it shows up.

Comment 45

[reginaldlather]

Jim, it is paiting related. I should have checked before shouting out. Apologies for that. with dom.ipc.plugins.asyncdrawing.disabled it focuses  without issue so I'll hold fire on raising  another bugs for now.. Thanks for your support and speedy response.

Comment 46

[Jim Mathies [:jimm]]

Based on the results of a triage with fx51 beta (which does not have this fix) and flash beta 24, this appears to be mostly fixed on adobe's side. So I'm planning to back this one-off fix out.

Comment 47

[Alice0775 White]

(In reply to Jim Mathies [:jimm] from comment #46)
> Based on the results of a triage with fx51 beta (which does not have this
> fix) and flash beta 24, this appears to be mostly fixed on adobe's side. So
> I'm planning to back this one-off fix out.

Firefox51.0b6 is disabled asyncdrawing by default, so unable to reproduce on Firefox51.0b6.

If you set dom.ipc.plugins.asyncdrawing.enabled=true, you can reproduce on Firefox51.0b6 even if 
Latest Flash beta 24.0.0.170 is used. 

So, Adobe does not fix anyway.

Comment 48

[Tracy Walker [:tracy]]

jimm: a few of the duped bugs, that were white flash content, are fixed by Flash 24 beta.  However, this is one of the bugs that is *not* fixed by AFP 24 beta.  This bug is fixed on Nightly 53 (by patch).  Unless Adobe plans to address this particular bug, on their end, shouldn't we leave your fix in?

Comment 49

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Too late to fix in 50.1.0 release

Comment 50

[Jim Mathies [:jimm]]

This workaround was backed out in bug 1331951. The bug should be fixed in the current adobe release (194).