+++ This bug was initially created as a clone of Bug #840439 +++ Bug 840439 discusses navigator.plugins with respect to pdf.js; this bug is about navigator.plugins wrt shumway. Of particular concern is that some (many?) sites rely on navigator.plugins to determine if flash content should be served. If shumway is available but no flash plugins are installed, the browser is flash-capable but appears otherwise.

Well... sorta flash-capable ;-) And this really only applies to full-shumway, not shumway-as-previewer. And we probably need to understand whether most sites look for Flash by MIME type or by plugin name if they are doing detection.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #1) > And we probably need to understand whether most sites look for Flash by MIME > type or by plugin name if they are doing detection. We would need to handle both - e.g. Flash helper libraries like swfobject check by name: http://code.google.com/p/swfobject/source/browse/trunk/swfobject/src/swfobject.js ... while other libraries check by mimetype: http://www.featureblend.com/flash_detect_1-0-4/flash_detect.js

While I am generally willing that we should add an entry for the Flash MIME type, I'm worried that we should probably *not* claim "Shockwave Flash" but should instead have our own named "Shumway SWF Player" entry.

"Shumway SWF Player (like Flash 11.x)" or something like that should cover most (if not all) use cases.

Given that swfobject.js is widely deployed and would not work, I'm not sure that's true. But we could certainly submit a patch to swfobject to detect Flash by MIME type instead of description, but it would take a while to get that out to most of the internet ;-)

Geoff, can you try Florian's suggestion and report back how successful it is in getting use the content we want?

We still don't (yet) fully support shumway-as-plugin do we? It seems like we need a bug to fully allow js-implemented plugins that would include this as a side-effect. Right now it uses the playPreview API, which would not make sense to hook to navigator.plugins

(In reply to Brad Lassey [:blassey] from comment #6) > Geoff, can you try Florian's suggestion and report back how successful it is > in getting use the content we want? I experimented using this procedure, mostly on Ubuntu: - disable all plugins except Shockwave Flash 11.2 r202 - edit <profile>/pluginreg.dat manually - start firefox - verify plugin entry changes with http://www.pinlady.net/PluginDetect/All/navarray.php - load a variety of video sites from https://wiki.mozilla.org/Shumway/Flash_video_sites#Top_25_flash_video_sites Findings: - most (virtually all) sites require a plugin entry with a mime type of application/x-shockwave-flash supporting swf - some sites (eg vimeo, foxnews) require enabledPlugin.name to be "Shockwave Flash"; no variation ("Shockwave Flash x", "x Shockwave Flash") seems to be tolerated - some sites (eg ted.com, cnn) require enabledPlugin.description to contain "Shockwave Flash", but allow variations like "Shumway SWF Player (like Shockwave Flash 11.2 r202)" - screen.yahoo.com does not accept enabledPlugin.description = "Shumway SWF Player (like Shockwave Flash 11.2 r202)" or "Shumway SWF Player, like Shockwave Flash 11.2 r202" but does accept "Shumway SWF Player like Shockwave Flash 11.2 r202" As far as I can tell, we need to mimic most of the Shockwave Flash entry in order to convince a variety of popular sites to serve Flash, but there is room for modification of the plugin description. I found no problems with this entry: Let A = navigator.mimeTypes[0] A.description: Shockwave Flash A.enabledPlugin: [object Plugin] A.suffixes: swf A.type: application/x-shockwave-flash enabled: true A.enabledPlugin == navigator.plugins[0] A.enabledPlugin.0: [object MimeType] A.enabledPlugin.1: [object MimeType] A.enabledPlugin.length: 2 A.enabledPlugin.description: Shumway SWF Player like Shockwave Flash 11.2 r202 A.enabledPlugin.filename: libflashplayer.so A.enabledPlugin.version: A.enabledPlugin.name: Shockwave Flash A.enabledPlugin.item: function item() { [native code] } A.enabledPlugin.namedItem: function namedItem() { [native code] }

This approach may be too simple-minded, but it works for me: If a (new, shumway-specific) pref is set, and no Flash plugin exists, insert a flash entry in the array of plugin descriptions returned from nsPluginHost::GetPlugins. The inserted entry is very similar to the one described in Comment 8.

(In reply to Geoff Brown [:gbrown] from comment #9) > This approach may be too simple-minded, but it works for me: If a (new, > shumway-specific) pref is set, and no Flash plugin exists, insert a flash > entry in the array of plugin descriptions returned from > nsPluginHost::GetPlugins. The inserted entry is very similar to the one > described in Comment 8. But, Comment 7 :( Right now we register shumway only as a "play preview" handler. If we also wanted the ability to register it as a stand-in for a full plugin when no flash is present, we could add the ability to do so pretty easily, without adding shumway-specific navigator.plugins hacks

(In reply to John Schoenick [:johns] from comment #10) > But, Comment 7 :( Sorry! I didn't understand what you meant on first-reading and forgot to re-visit your comment. > Right now we register shumway only as a "play preview" handler. If we also > wanted the ability to register it as a stand-in for a full plugin when no > flash is present, we could add the ability to do so pretty easily, without > adding shumway-specific navigator.plugins hacks The idea of something more generic / less hacky is appealing, but I wonder if that's more than we need. I think Shumway only needs a Flash-like entry to appear in navigator.plugins -- it doesn't need to be a "stand-in for a full plugin". Also, if we go to the trouble of providing a generic API, would anything other than Shumway (and maybe pdf.js) ever use it? I don't have any experience in plugins and have little faith in my perspective here -- happy to hear other opinions.

(In reply to Geoff Brown [:gbrown] from comment #11) > The idea of something more generic / less hacky is appealing, but I wonder > if that's more than we need. I think Shumway only needs a Flash-like entry > to appear in navigator.plugins -- it doesn't need to be a "stand-in for a > full plugin". Also, if we go to the trouble of providing a generic API, > would anything other than Shumway (and maybe pdf.js) ever use it? > > I don't have any experience in plugins and have little faith in my > perspective here -- happy to hear other opinions. Well, right now we have two addons that will want the option to 'replace' a native plugin, and the current code is 99% of the way to supporting JS-implemented plugins -- the only difference is that they do not show up in navigator.plugins or the UI as such. Adding a shumway-specific hack when we're only a small patch away from properly supporting fully-JS plugins seems silly. I think what we should do is replace nsPluginHost::RegisterPlayPreviewMimeType with RegisterJSPluginType, and have the list it stores include a play-preview flag and a act-as-real-plugin flag. If the latter flag is set, we insert a dummy PluginTag in the list, and everything that uses this (UI code, preferences) would just work. Then nsObjectLoadingContent would just need to be aware of the dummy tags so that it doesn't try to accidentally instantiate one, and switches to the relevant sub-document mode instead. If that sounds reasonable I could put this patch together in the next day or so, seeing as I've already reworked all this goop to be sane.

(In reply to John Schoenick [:johns] from comment #12) > If that sounds reasonable I could put this patch together in the next day or > so, seeing as I've already reworked all this goop to be sane. That sounds great - thanks!

John, any update here?

(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #14) > John, any update here? Sorry for the delay on this, there ended up being a lot of related changes to this code for click-to-play I didn't want to trip over. I'm working on this now. ("next day or so" roughly means about six weeks, right?)

The API for this will be landing in bug 558184, we'll use this bug for tracking making that work with shumway

could someone post here the syntax for prefs.js? i tried to reproduce comment 8 to be able to test shumway but i failed. currently most flash pages are looking for adobe flash and shumway does not even start.

(In reply to e3k from comment #17) > could someone post here the syntax for prefs.js? i tried to reproduce > comment 8 to be able to test shumway but i failed. currently most flash > pages are looking for adobe flash and shumway does not even start. I am not sure I understand your question. In comment 8, I was manipulating the plugins registry, visiting video sites, and then manually determining if flash content was served (look at page source, or look for error messages on the page). prefs.js was not involved and as I recall, Shumway was not capable of playing videos at that time. I have not been working on Shumway lately and can't say what the current video capabilities are -- I'll leave that to others.

ok thanks for answer. i thought it would be enough to fake the adobe prefs in FF to be able to pretend that adobe is installed and i could run shumway on pages which check for adobe presence.

The priorities and importance of the blocking bugs are less then this bug. Is it better to implement solution proposed here in the attachment 748890 [details] [diff] [review] for now while bug 558184 and bug 853995 are being implemented?

(In reply to Yury Delendik (:yury) from comment #20) > The priorities and importance of the blocking bugs are less then this bug. > Is it better to implement solution proposed here in the attachment 748890 [details] [diff] [review] > [details] [diff] [review] for now while bug 558184 and bug 853995 are being > implemented? This bug only requires the core work already done on bug 558184, I split out bug 964435 and bug 964436 for better initial-stream and parameter handling respectively, and will try to land the basic API in bug 558184 this week.

Make bugs with "[shumway-fb2]" whiteboard tag block shumway-fb2 meta bug 1110300.

As long as this bug is not fixed, is there any hacky work-around other than installing a free or non-free Flash plug-in? I should be able to work it out from reading the entries above, but I am a C developer, not a browser person (bad excuse, I know!)

Unfortunately, there is currently no workaround other than installing a Flash plugin. You can configure the Flash plugin to be click-to-play ("Ask to Activate" in the Add-ons Manager) so the Flash plugin will never load but it will still be listed in navigator.plugins.

Exposing Shumway in navigator.plugins for plugin detection does not need to block Nightly testing.

This Shumway bug is no longer relevant.

(In reply to Chris Peterson [:cpeterson] from comment #26) > This Shumway bug is no longer relevant. Why is it no longer relevant?

(In reply to Michał Gołębiowski [:m_gol] from comment #27) > (In reply to Chris Peterson [:cpeterson] from comment #26) > > This Shumway bug is no longer relevant. > > Why is it no longer relevant? Shumway is still on GitHub, but it's not on a path to ship bundled in Firefox. Given our limited resources, other product priorities are currently more important.