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)
Tracking
(firefox-esr45 unaffected, firefox50 wontfix, firefox51 wontfix, firefox52 wontfix, firefox53 wontfix, firefox54 wontfix)
RESOLVED
DUPLICATE
of bug 1271398
People
(Reporter: jimm, Unassigned)
References
()
Details
(Keywords: regression)
Attachments
(1 file)
1.50 KB,
patch
|
benjamin
:
review-
|
Details | Diff | Splinter Review |
+++ 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
Reporter | ||
Comment 1•7 years ago
|
||
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)
Updated•7 years ago
|
status-firefox50:
--- → ?
status-firefox51:
--- → ?
status-firefox52:
--- → ?
Depends on: 1246574
Flags: needinfo?(cpeterson)
Comment 3•7 years ago
|
||
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)
Updated•7 years ago
|
Assignee: nobody → davidp99
Comment 4•7 years ago
|
||
Tests: https://treeherder.mozilla.org/#/jobs?repo=try&revision=1c5152e392d0d0b2ca0ca79d741333c03cd93a46
Comment 5•7 years ago
|
||
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)
Reporter | ||
Comment 6•7 years ago
|
||
(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)
Comment 7•7 years ago
|
||
(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)
Comment 8•7 years ago
|
||
(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
Comment 9•7 years ago
|
||
(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?
Reporter | ||
Updated•7 years ago
|
Flags: needinfo?(jmathies)
Comment 10•7 years ago
|
||
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)
Updated•7 years ago
|
Attachment #8819162 -
Flags: review?(benjamin) → review-
Comment 11•7 years ago
|
||
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)
Updated•7 years ago
|
Reporter | ||
Comment 12•7 years ago
|
||
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
Comment 13•7 years ago
|
||
Marking fix-optional/disabled based on comment 12. Jim, please correct if that's incorrect.
status-firefox53:
affected → ---
Flags: needinfo?(jmathies)
Reporter | ||
Updated•7 years ago
|
status-firefox53:
--- → disabled
status-firefox54:
--- → affected
status-firefox-esr45:
--- → unaffected
Flags: needinfo?(jmathies)
Reporter | ||
Comment 14•7 years ago
|
||
this is a long standing bug in 64-bit builds related to our forcing windowless there.
Comment 15•7 years ago
|
||
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.
Reporter | ||
Comment 16•7 years ago
|
||
(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.
Comment 17•7 years ago
|
||
I mean bug 1274659. Is it postponed?
Reporter | ||
Comment 18•7 years ago
|
||
(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)
Comment 19•7 years ago
|
||
(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
Blocks: win64-migration
Flags: needinfo?(cpeterson)
Comment 20•7 years ago
|
||
Jim, can we close this bug as a duplicate of bug 1323403?
Flags: needinfo?(jmathies)
Updated•7 years ago
|
Blocks: flash-async-drawing
Reporter | ||
Comment 21•7 years ago
|
||
(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)
Reporter | ||
Updated•7 years ago
|
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Comment 23•7 years ago
|
||
Mark 54 won't fix as bug 1271398 has been fixed.
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•