Closed Bug 1312242 Opened 3 years ago Closed 3 years ago

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

Categories

(Core :: Plug-ins, defect, major)

49 Branch
x86_64
Windows 7
defect
Not set
major

Tracking

()

RESOLVED WORKSFORME
mozilla52
Tracking Status
firefox49 --- wontfix
firefox50 --- wontfix
firefox51 + wontfix
firefox52 + fixed

People

(Reporter: ifire, Assigned: jimm)

References

Details

(Keywords: regression, Whiteboard: layout/gfx, tests, STR in comment #0 with attached test case)

Attachments

(4 files, 3 obsolete files)

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.
Severity: normal → major
Component: Untriaged → General
OS: Unspecified → Windows 7
Hardware: Unspecified → x86_64
49.0.1 works fine. 49.0.2 have this bug
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?
Component: General → Plug-ins
Flags: needinfo?(ifire)
Product: Firefox → Core
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Attached file testcase
Attached image screenshot
Blocks: 1229961
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?
Flags: needinfo?(ifire)
Duplicate of this bug: 1312276
Summary: Missing transparency in Adobe Flash objects → Missing transparency in Adobe Flash objects with wmode="tansparent"
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.
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.
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.
Blocks: 1311928
Whiteboard: adobe
Bas, is this something we can fix on the graphics side, or is it more of a layout?
Flags: needinfo?(bas)
Duplicate of this bug: 1313852
(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.
Flags: needinfo?(bas)
Duplicate of this bug: 1312043
Duplicate of this bug: 1312293
Duplicate of this bug: 1311928
Whiteboard: adobe → layout/gfx
Summary: Missing transparency in Adobe Flash objects with wmode="tansparent" → Missing transparency in Adobe Flash objects with wmode="transparent"
[Tracking Requested - why for this release]: Moving over the tracking flags from the duplicate bug.
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?
Flags: needinfo?(jmathies)
Track 51+ as regression.
(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?
Flags: needinfo?(jmathies) → needinfo?(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.
Flags: needinfo?(mtalistu)
(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.
Attached patch bgcolor testing patch (obsolete) — Splinter Review
Attached patch bgcolor testing patch (obsolete) — Splinter Review
Attachment #8806700 - Attachment is obsolete: true
Attached patch bgcolor testing patch (obsolete) — Splinter Review
Attachment #8806701 - Attachment is obsolete: true
Duplicate of this bug: 1312342
Duplicate of this bug: 1311990
Duplicate of this bug: 1312208
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.
Attachment #8806702 - Flags: review?(aklotz)
Assignee: nobody → jmathies
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?
Attachment #8806702 - Flags: review?(aklotz) → review+
With Jim's try build at https://ftp.mozilla.org/pub/firefox/try-builds/jmathies@mozilla.com-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.
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.
Duplicate of this bug: 1311374
Tracking 52+ for this regression involving painting.
Whiteboard: layout/gfx → layout/gfx, tests
Attached patch bgcolor patchSplinter Review
updated per comments
Attachment #8806702 - Attachment is obsolete: true
Attachment #8807660 - Flags: review+
Keywords: checkin-needed
Pushed by ryanvm@gmail.com:
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
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/0b21bc7c6cb0
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
Blocks: 1315507
Duplicate of this bug: 1311867
Duplicate of this bug: 1276426
Hi :jimm,
Is this worth uplifting to 51 aurora?
Flags: needinfo?(jmathies)
(In reply to Gerry Chang [:gchang] from comment #41)
> Hi :jimm,
> Is this worth uplifting to 51 aurora?

we might, haven't decided yet.
Flags: needinfo?(jmathies)
Depends on: 1316438
Depends on: 1320631
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?
Flags: needinfo?(jmathies)
(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.
Flags: needinfo?(jmathies)
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.
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.
(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.
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?
Too late to fix in 50.1.0 release
Depends on: 1331951
This workaround was backed out in bug 1331951. The bug should be fixed in the current adobe release (194).
Resolution: FIXED → WORKSFORME
Whiteboard: layout/gfx, tests → layout/gfx, tests, STR in comment #0 with attached test case
You need to log in before you can comment on or make changes to this bug.