736998 - Flash click-to-play broken when opening swf directly

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[James Willcox (:snorp) ([e-mail]) (he/him)]

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.

Comment 1

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

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.

Comment 2

[Gabriela [:gaby2300]]

This happens in my Galaxy S2 phone, using Android 2.3.4 and build 20120330.

Comment 3

[Josh Aas]

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".

Comment 5

[Josh Aas]

Attachment: fix v1.0

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.

Comment 6

[Josh Aas]

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").

Comment 7

[Benjamin Smedberg]

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.

Comment 8

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Side note:

Odd.  I found a website that does have swf playing in a window by itself:
www.albinoblacksheep.com

Comment 11

[presenta]

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.

Comment 12

[Benjamin Smedberg]

The click-to-play feature is still in development. It is off by default and is not exposed in the browser UI.

Comment 13

[Alice Wyman]

(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"?

Comment 17

[Matthew Turnbull [Bluefang]]

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.

Comment 18

[Josh Aas]

I'm waiting for John to land a bit more stream cleanup that will greatly simplify fixing this bug.

Comment 20

[Josh Aas]

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.

Comment 21

[Harry Strongburg]

I have this issue in version 16, but I can also confirm that the issue appears to be fixed in Nightly.

Comment 22

[John Schoenick [:johns]]

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.