Closed Bug 1323750 Opened 7 years ago Closed 7 years ago

Flash Stage3D fails on youngjump.jp in 64-bit Firefox

Categories

(Core Graveyard :: Plug-ins, defect)

x86_64
Windows 10
defect
Not set
normal

Tracking

(firefox-esr45 unaffected, firefox50 wontfix, firefox51 wontfix, firefox52 wontfix, firefox53 wontfix, firefox54 wontfix)

RESOLVED DUPLICATE of bug 1271398
Tracking Status
firefox-esr45 --- unaffected
firefox50 --- wontfix
firefox51 --- wontfix
firefox52 --- wontfix
firefox53 --- wontfix
firefox54 --- wontfix

People

(Reporter: jimm, Unassigned)

References

()

Details

(Keywords: regression)

Attachments

(1 file)

+++ This bug was initially created as a clone of Bug #1323403 +++

Reproducible: always

Steps to Reproduce:
1. Activate Flash Plugin 24
2. Open http://youngjump.jp/manga/kingdom/
3. Wait for few seconds

Actual Results:
Black

Expected Results:
Flash content should appear
Tracy, could you please test current 64-bit releases and update the status flags here based on what you find. Note, avoid hitting bug 1323403.
Flags: needinfo?(twalker)
New potential 64-bit rollout blocker.
Flags: needinfo?(cpeterson)
Depends on: 1246574
Flags: needinfo?(cpeterson)
I believe the page this is reported against has a bug (wmode not set).  So I have a second STR.  I'll spell this out:

---------------

Original STR (slightly updated):

1. Launch 32-bit or 64-bit Firefox.  Set dom.ipc.plugins.asyncdrawing.enabled to false.  If running 32-bit, set dom.ipc.plugins.sandbox-level.flash to 2.  This isn't really sandbox related -- this is needed due to this conditional:
https://dxr.mozilla.org/mozilla-central/rev/6dbc6e9f62a705d5f523cc750811bd01c8275ec6/dom/plugins/ipc/PluginModuleParent.cpp#2724

2. Go to http://youngjump.jp/manga/kingdom/ and give the page a few seconds to load.

Expected Result:
The page renders normally.

Actual Result: 
All black content.

---------------

The situation appears to be that the page uses Flash's StageVideo/Stage3D extensions.  This requires the embed object to have a <param> element setting "wmode" to "direct".  The page does not have this -- so it defaults to "window" mode which is known to work... sometimes.  Note that forcing the plugin to use wmode=direct (by changing the following line to use "direct" instead of "opaque") corrects the issue:
https://dxr.mozilla.org/mozilla-central/rev/6dbc6e9f62a705d5f523cc750811bd01c8275ec6/dom/plugins/ipc/PluginModuleParent.cpp#2736

The page has some security that doesn't allow the Flash plugin to be hosted locally but I've got a page that uses Stage3D and does set the wmode correctly.  Note that it sports the same bugs the aforementioned page does.

STR with the new page:

----------------

1. Launch 32-bit or 64-bit Firefox.  Set dom.ipc.plugins.asyncdrawing.enabled to false.  If running 32-bit, set dom.ipc.plugins.sandbox-level.flash to 2.  

2. Go to http://blog.bwhiting.co.uk/?p=314

Expected result:
The demo that says "Click to start", after clicking, draws a bunch of spinning tori.

Actual Result: The HUD is drawn but the rest is blackness.

--------------------------

In this case, although the page sets the wmode correctly, we override it.  That's what the patch fixes.  I'm not exactly sure why we do this but you reviewed the original patch and suggested this behavior (over a "transparent" wmode override, which also wouldn't work) in bug 1201904 comment 37.  I kind of think the original point was just to override "window" (which is also the default if wmode is missing) but I'm not sure so I just 'permit' direct (the only mode that would be left is "gpu" anyway -- see https://helpx.adobe.com/flash/kb/flash-object-embed-tag-attributes.html#main_Using_Window_Mode__wmode__values_).
Attachment #8819162 - Flags: review?(benjamin)
Assignee: nobody → davidp99
David, my understanding of wmode="direct" is that it uses a windows widget and is basically a windowed plugin. Since we do not want to allow windowed plugins in the sandbox because of the many other regressions, I suspect this is not a good solution.

At this point until we have async drawing, Stage3D not working is a known and expected behavior on win64. I think we should keep this bug open as a tracker to perhaps block rollout of win64, I don't think we should actually fix it. Jim do you agree?
Flags: needinfo?(twalker) → needinfo?(jmathies)
(In reply to Benjamin Smedberg [:bsmedberg] from comment #5)
> At this point until we have async drawing, Stage3D not working is a known
> and expected behavior on win64. I think we should keep this bug open as a
> tracker to perhaps block rollout of win64, I don't think we should actually
> fix it. Jim do you agree?

Yes, although I wonder if cpeterson is aware of the Stage3D trade off we currently have? Async drawing is stuck on nightly for a bit while adobe fixes bugs.
Flags: needinfo?(jmathies) → needinfo?(cpeterson)
(In reply to Jim Mathies [:jimm] from comment #6)
> Yes, although I wonder if cpeterson is aware of the Stage3D trade off we
> currently have? Async drawing is stuck on nightly for a bit while adobe
> fixes bugs.

Jim, do we have bugs filed for the Adobe async drawing bugs?

The Stage3D tests in bug 1271398 comment 0 work correctly with Flash 23+. What is different about this youngjump.jp site?
Flags: needinfo?(cpeterson) → needinfo?(jmathies)
(In reply to Chris Peterson [:cpeterson] from comment #7)
> The Stage3D tests in bug 1271398 comment 0 work correctly with Flash 23+.
> What is different about this youngjump.jp site?

oops. I was testing in Nightly, which has Flash async drawing enabled. Those Stage3D sites fail to load in 64-bit Firefox 50, as expected.

Broken Stage3D does sound like a 64-bit release blocker. :(

Jim, if you have a list of async drawing bugs that Adobe needs to fix, I can follow up with them.
Summary: Flash fails on youngjump.jp in 64-bit firefox builds → Flash Stage3D fails on youngjump.jp in 64-bit Firefox
(In reply to Chris Peterson [:cpeterson] from comment #8)
> if you have a list of async drawing bugs that Adobe needs to fix, I can
> follow up with them.

Are bug 1229961 blockers insufficient? (Currently we have 19 unresolved bugs!) Is it really practical to fix them soon?
Flags: needinfo?(jmathies)
Benjamin, what version of Firefox are we targeting for npapi-sandbox-64bit? (Note you have a pending review request on this one)
Flags: needinfo?(benjamin)
Attachment #8819162 - Flags: review?(benjamin) → review-
davidb I don't understand the question. We already shipped the NPAPI sandbox for 64-bit, hence this bug. Perhaps you meant what version we're going to ship async drawing in again? We don't know that yet; jimm owns next steps and is working with Adobe.
Flags: needinfo?(benjamin)
This is a side effect of our forcing windowless in 64-bit builds. The right fix is async drawing support which we're working on in other bugs.
Assignee: davidp99 → nobody
Marking fix-optional/disabled based on comment 12. Jim, please correct if that's incorrect.
Flags: needinfo?(jmathies)
this is a long standing bug in 64-bit builds related to our forcing windowless there.
Then we do not move 32-bit users in Firefox 53 time frame anymore? Although this is a long standing bug in 64-bit builds, it is not in 32-bit builds.
(In reply to Masatoshi Kimura [:emk] from comment #15)
> Then we do not move 32-bit users in Firefox 53 time frame anymore?

Can you clarify? Not sure what you're asking here.
I mean bug 1274659. Is it postponed?
(In reply to Masatoshi Kimura [:emk] from comment #17)
> I mean bug 1274659. Is it postponed?

Thanks for the clarification. Pretty sure that bug should be is blocked by our current work on wider distribution of 64-bit installs, which is blocked on async drawing, which will fix this bug. ni'ing cpeterson to be sure.
Flags: needinfo?(cpeterson)
(In reply to Masatoshi Kimura [:emk] from comment #17)
> I mean bug 1274659. Is it postponed?

Upgrading 32-bit users to 64-bit is still blocked waiting for Adobe to fix the async drawing bugs in the Flash plugin (which will fix this bug). They expect to fix their bugs in the February or March Flash release.

We didn't expect to be able to upgrade 32-bit users in 2017 H1, so I wouldn't call the upgrade "postponed", exactly. :) I keep the following wiki up to date with our 64-bit plans and schedule:

https://wiki.mozilla.org/Firefox/Win64#Schedule
Flags: needinfo?(cpeterson)
Jim, can we close this bug as a duplicate of bug 1323403?
Flags: needinfo?(jmathies)
(In reply to Chris Peterson [:cpeterson] from comment #20)
> Jim, can we close this bug as a duplicate of bug 1323403?

don' think so. bug 1323403 is a layout bug, this is broken flash feature bug.
Flags: needinfo?(jmathies)
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Mark 54 won't fix as bug 1271398 has been fixed.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: