Closed Bug 736998 Opened 8 years ago Closed 7 years ago
Flash click-to-play broken when opening swf directly
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.
8 years ago
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.
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".
Assignee: joshmoz → nobody
Component: General → Plug-ins
Product: Fennec Native → Core
QA Contact: general → plugins
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").
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: 766946
We can confirm that the newly announced click_to_play feature in v14 breaks loading of PDFs through Acrobat Plugin v188.8.131.52. 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"?
Duplicate of this bug: 778386
Duplicate of this bug: 743060
Duplicate of this bug: 747105
Looks like this got fixed in a recent trunk build. broken (2012-08-07): http://hg.mozilla.org/mozilla-central/rev/1bbc0b65dffb working (2012-08-08): http://hg.mozilla.org/mozilla-central/rev/e55638d4037a push log: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1bbc0b65dffb&tochange=e55638d4037a Probably Bug 745030.
I'm waiting for John to land a bit more stream cleanup that will greatly simplify fixing this bug.
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
You need to log in before you can comment on or make changes to this bug.