Closed Bug 736998 Opened 8 years ago Closed 7 years ago

Flash click-to-play broken when opening swf directly

Categories

(Core :: Plug-ins, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla17
Tracking Status
blocking-fennec1.0 --- -

People

(Reporter: snorp, Assigned: johns)

References

()

Details

(Keywords: testcase)

Attachments

(1 file)

With click-to-play enabled, opening a swf directly shows 'tap to activate' area. After tapping it, though, the plugin is not successfully loaded. Usually I see a white area.
Assignee: nobody → joshmoz
blocking-fennec1.0: --- → ?
I don't think this is a blocker, because it's opening up flash by itself.  Not sure how common this is; setting to blocking only to go through triage process.
blocking-fennec1.0: ? → -
This happens in my Galaxy S2 phone, using Android 2.3.4 and build 20120330.
Did some debugging, I'm pretty sure the full page plugin instance isn't getting stream data for the Flash content. This is because the content system starts a stream and we abort it when we don't start the plugin instance for click-to-play. Once the users clicks we don't restart the stream in the full page instance loading path. The embedded instance path does restart the stream. This can be seen in nsPluginHost::InstantiateFullPagePlugin vs. nsPluginHost::InstantiateEmbeddedPlugin. Both create a stream listener, but only the embedded path restarts the stream if necessary via "NewEmbeddedPluginStream".
Duplicate of this bug: 745183
Assignee: joshmoz → nobody
Component: General → Plug-ins
Keywords: testcase
Product: Fennec Native → Core
QA Contact: general → plugins
Blocks: 90268
Assignee: nobody → joshmoz
OS: Android → All
Hardware: ARM → All
Attached patch fix v1.0Splinter Review
This works by adding stream retry logic to the fullpage instantiation path. This patch includes the fix for bug 745842, which I was working on top of. Once I land that I'll post another patch here without that fix.
Note to self: In the next revision of the patch I need to fix my usage of NewEmbeddedPluginStream ("Embedded") for the full page path. Also check to make sure the listener is getting set properly on the document ("aStreamListener" out-param for "InstantiateFullPagePluginInstance").
Depends on: 745842
As noted on IRC, since fullpage plugins can be POSTs and not just GETs, we need to be careful about retry logic and especially about not rePOSTing streams but instead trying to keep them cached. This is especially important for some kinds of PDF downloads for receipts and other transactions.
Side note:

Odd.  I found a website that does have swf playing in a window by itself:
www.albinoblacksheep.com
Duplicate of this bug: 773977
We can confirm that the newly announced click_to_play feature in v14 breaks loading of PDFs through Acrobat Plugin v9.1.0.163. It also breaks a plugin which we develop and the problem is that when plugins.click_to_play is true, NPP_NewStream function is no longer called. 

The proposed patch is from 2012-04-18 and now at the end of July and having the official announcement, click_to_play option still breaks a lot of plugins not calling NPP_NewStream. Fortunately, this option is off by default.
The click-to-play feature is still in development. It is off by default and is not exposed in the browser UI.
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #12)
> The click-to-play feature is still in development. It is off by default and
> is not exposed in the browser UI.

Even so, Firefox users are turning on this feature in Firefox 14.0.1 and  reporting problems in the support forum.   Related discussion:
* https://support.mozilla.org/en-US/forums/contributors/708518 [Firefox 14.0.1] Problems ahead with "plugins.click_to_play"?
Depends on: 767627
Depends on: 767633
Depends on: 767638
I'm waiting for John to land a bit more stream cleanup that will greatly simplify fixing this bug.
Duplicate of this bug: 801406
This actually appears to be working now, probably fixed somewhere along the line by jschoenick's work. Assigning to John.

James - can you confirm?

If this is fixed we should still investigate the possibility that the feature doesn't work properly with data from a POST request.
Assignee: joshmoz → jschoenick
I have this issue in version 16, but I can also confirm that the issue appears to be fixed in Nightly.
This was fixed probably by bug 745030, and bug 767638 greatly cleaned up full page plugin handling so its codepath no longer substantially differs from other plugins.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
You need to log in before you can comment on or make changes to this bug.