938722 - Need a recommended way for web pages to determine that plugins are not supported in Metro

Status: RESOLVED INCOMPLETE

(Firefox for Metro Graveyard :: General, defect)

Description

[Matt Brubeck (:mbrubeck)]

Web pages that use plugins should have a way to determine that Metro Firefox does not support plugins, so they can offer appropriate instructions/errors to users:

https://support.mozilla.org/en-US/questions/977481

I'm not sure if we have any current way to detect this.

Comment 1

[Matt Brubeck (:mbrubeck)]

Do we have any existing API that content could use to determine if they are in an environment where plugin installation is completely unavailable (like Metro or B2G)?

Comment 2

[Jim Mathies [:jimm]]

How about a new field in the navigator object. Something like 'pluginFeatures' = { supported: true/false }.

Comment 3

[Benjamin Smedberg]

Are there any existing browser (android/chromebook) that have any indicators like this?

What's the target audience? Note that we are going to support JS-implemented plugins on browsers, so what you're actually saying is more "no binary plugins" or something. Unless we can get other browser vendors to sign on and make this actually valuable, I'm skeptical that we should do anything here.

Comment 4

[Matt Brubeck (:mbrubeck)]

The use case is for web pages that check for a plugin, and if it is not present, direct users to download the plugin.  They can use the platform information in the User-Agent header to adjust their messaging based on whether the plugin is available for that platform.  But Firefox for Metro has the same User-Agent as Firefox for desktop, so Metro users get the same messaging as other Windows users, and it's misleading.

We're also looking at messaging in the browser chrome to try to mitigate this (bug 936907), but it'll be confusing as long as there is conflicting (and misleading) messaging from the sites themselves.

Comment 5

[Gervase Markham [:gerv]]

Am I right in thinking that Metro is merely a few years ahead of our other desktop browsers in this way, in that eventually we would like binary plugins to die - and when we do, we'll need a method of indicating lack of support to sites in that situation?

bsmedberg: you say we are planning to support JS-implemented NPAPI plugins? Is that the alternative to binary ones? We don't support those yet, do we? Are we planning to support that with no planned end date, as it were? (I know we can't commit to "for ever".)

The other related use case for this is plugin download pages - it would be useful if the Flash plugin download page on adobe.com said "if you download this, it won't work in your browser". So even if sites don't update to check this signal, the Flash plugin download page could check.

I agree that the UA is the wrong place for this signal. We should provide some sort of JS-based API. But the question is: exactly what semantics should it have, and where should it be?

Gerv

Comment 6

[Benjamin Smedberg]

Whether we would like NPAPI plugins to die is sorta-irrelevant. We have no plan to make them die on existing platforms that support them, at least in the 3-year timeframe that we could look into the future.

> bsmedberg: you say we are planning to support JS-implemented NPAPI plugins?

JS-implemented plugins. "NPAPI" is a binary API that doesn't make sense in this context.

> Is that the alternative to binary ones? We don't support those yet, do we?

We do through extensions; that's how pdf.js and shumway work. johns is working on a better API for these. Currently it's not a standardized proposal, but we'd consider standardizing it once we have some more implementation experience.

> The other related use case for this is plugin download pages - it would be
> useful if the Flash plugin download page on adobe.com said "if you download
> this, it won't work in your browser". So even if sites don't update to check
> this signal, the Flash plugin download page could check.

I'd say that UA detection is normally exactly what you want in this situation. Plugin install pages already use UA detection to send people to the correct mac/windows installer. I'm not aware of all the reasons the Metro UA is exactly the same as desktop, although I can imagine some good reasons.

But also note that often we *do* want to send people to the desktop Windows plugin page, and then prompt them to switch into desktop mode if they need to use a site which requires a plugin. So I'm not convinced that this is the right thing to do at all.

Comment 7

[Jim Mathies [:jimm]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #6)
> > bsmedberg: you say we are planning to support JS-implemented NPAPI plugins?
> 
> JS-implemented plugins. "NPAPI" is a binary API that doesn't make sense in
> this context.
> 
> > Is that the alternative to binary ones? We don't support those yet, do we?
> 
> We do through extensions; that's how pdf.js and shumway work. johns is
> working on a better API for these. Currently it's not a standardized
> proposal, but we'd consider standardizing it once we have some more
> implementation experience.

If we did have something like this installed, would navigator.plugins reflect it? In which case with proper docs sites could still make the right decision on what to load. What we want to communicate to sites is: do not prompt for the install of a binary plugin, it won't work in this browser even if the user agrees.

> But also note that often we *do* want to send people to the desktop Windows
> plugin page, and then prompt them to switch into desktop mode if they need
> to use a site which requires a plugin. So I'm not convinced that this is the
> right thing to do at all.

Shouldn't sites be responsible for doing this? "This web page is not compatible with your browser, reason: no flash support. Please switch to a browser that supports flash." Users then switch to desktop, and if they don't have flash, they get prompted to install. What we want to avoid is having the user prompted for an install of flash in metrofx, installing, and then expecting it to work in metrofx. 

We can save ourselves a lot of effort and hassle here if we provide the info sites need and let them do the work.

Comment 8

[Benjamin Smedberg]

> If we did have something like this installed, would navigator.plugins
> reflect it?

Yes.

> Shouldn't sites be responsible for doing this?

This is a pipe-dream. The vast majority of sites have poor plugin detection already, and you're definitely not going to get any but a few very highly-trafficed sites to change their detection algorithms.

Comment 9

[Jim Mathies [:jimm]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #8)
> > If we did have something like this installed, would navigator.plugins
> > reflect it?
> 
> Yes.
> 
> > Shouldn't sites be responsible for doing this?
> 
> This is a pipe-dream. The vast majority of sites have poor plugin detection
> already, and you're definitely not going to get any but a few very
> highly-trafficed sites to change their detection algorithms.

Maybe but providing the information to sites and documenting how they should handle the situation still seems like the right approach. Case and point, this bug was initiated via a support request by a site author interested in handing this situation in a correct way.

Stepping back here, we have two issues:

1) sites that don't check for plugin support and serve up content with plugin tags.
2) sites that detect plugin support and serve up installer pages or links to installer pages.

There are things we can do to mitigate #1 like notifying / providing a way to switch to desktop. This is covered by bug 936907.

For #2 AFAICT we only have two options:

- we provide information via js or UA and docs so sites can properly deal with it if they choose to.
- we do nothing in which case sites continue with this practice because they can't tell browser apart.

Am I missing other options here?

Comment 10

[Benjamin Smedberg]

> Stepping back here, we have two issues:
> 
> 1) sites that don't check for plugin support and serve up content with
> plugin tags.
> 2) sites that detect plugin support and serve up installer pages or links to
> installer pages.

There are at least four possibilities:

* sites that use <object> and have working fallback content nested inside the tag
* sites that use <object> and have install instructions or an error message nested inside the tag
* sites that check for plugin support using navigator.plugins or navigator.mimeTypes and serve working fallback content when plugins are not present
* sites that check for plugin support using plugins/mimeTypes and present an error message or install instructions out-of-band using scripts

> - we provide information via js or UA and docs so sites can properly deal
> with it if they choose to.
> - we do nothing in which case sites continue with this practice because they
> can't tell browser apart.

The "good" site-options are:

A. use fallback code which works, either just as well as the plugin or in some degraded way
B. prompt the user to switch to desktop mode, or write some code to ask the browser to switch automatically

A is almost always the preferable option!
If B is what they want, then we'd need to expose to the client whether the plugin is installed (in desktop mode), no?

It may be that we need a different solution for Flash and for everything else, because of Flash pervasiveness, because we may be able to interpret Flash with Shumway soon, and because we know that Flash is always available on win8, since it comes bundled with Windows.

Metro is special enough for site authors that I don't think a generic "are binary plugins supported" API is what we want. If you want to expose an "are we running in metro mode" API, I don't object or really have much of an opinion, and it would solve the use cases you have here just as well.

Comment 11

[Jim Mathies [:jimm]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #10)
> There are at least four possibilities:
> 
> * sites that use <object> and have working fallback content nested inside
> the tag
> * sites that use <object> and have install instructions or an error message
> nested inside the tag
> * sites that check for plugin support using navigator.plugins or
> navigator.mimeTypes and serve working fallback content when plugins are not
> present
> * sites that check for plugin support using plugins/mimeTypes and present an
> error message or install instructions out-of-band using scripts

Thanks for itemizing.

> > - we provide information via js or UA and docs so sites can properly deal
> > with it if they choose to.
> > - we do nothing in which case sites continue with this practice because they
> > can't tell browser apart.
> 
> The "good" site-options are:
> 
> A. use fallback code which works, either just as well as the plugin or in
> some degraded way
> B. prompt the user to switch to desktop mode, or write some code to ask the
> browser to switch automatically
> 
> A is almost always the preferable option!
> If B is what they want, then we'd need to expose to the client whether the
> plugin is installed (in desktop mode), no?

I don't think so, at least not unless a lot of authors scream for it. Just switch and let desktop deal with its plugin state as it does now.

> It may be that we need a different solution for Flash and for everything
> else, because of Flash pervasiveness, because we may be able to interpret
> Flash with Shumway soon, and because we know that Flash is always available
> on win8, since it comes bundled with Windows.

We can cover this in bug 936907.

> Metro is special enough for site authors that I don't think a generic "are
> binary plugins supported" API is what we want. If you want to expose an "are
> we running in metro mode" API, I don't object or really have much of an
> opinion, and it would solve the use cases you have here just as well.

Agreed. I think we should avoid anything in the UA, that discussion has been hashed and rehashed and we always come back to the same conclusion - don't encourage UA sniffing. Something in navigator seems pretty harmless.

Comment 12

[Gervase Markham [:gerv]]

bsmedberg: when you say "Flash is always available", does that mean we've found a way to integrate with IE's bundled Flash on Windows 8, including in Metro mode?

If we do have a JS API for this, we should spec it with something like the following values:

"available" - plugin support is available; you may suggest installing missing plugins
"unavailable" - plugin support is not available; do not suggest installing missing plugins 
"switch" - plugin support is available in another configuration of the same browser

Anyone know what Chrome are doing on Windows 8, UA-wise and about this problem specifically?

Gerv

Comment 13

[Benjamin Smedberg]

Gerv, I mean that Flash (both the ActiveX and the NPAPI plugin) is bundled with Windows 8, so that in *desktop* mode it's always available.

I oppose a JS API that specifically talks about plugins. I would much prefer something specific to metro, e.g. navigator.windowsRT or somesuch.

Comment 14

[Gervase Markham [:gerv]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #13)
> I oppose a JS API that specifically talks about plugins. I would much prefer
> something specific to metro, e.g. navigator.windowsRT or somesuch.

Why is that? If we make an API which talks about plugins, it allows us to communicate that other platforms don't support plugins (e.g. Firefox OS, IINM). A clear way of indicating "this browser does not even support binary plugins" and allowing sites to take action appropriately will hasten their death, IMO.

Saying "this is Windows 8; infer details about plugin support from that" is basically doing the exact thing which makes user agent sniffing suck - telling people the name of the platform rather than its capabilities, and making them do the mapping themselves.

Gerv

Comment 15

[Benjamin Smedberg]

Plugins are inherently platform-specific, so anyone who is sniffing for plugins needs to know the platform anyway. And it's clearly not true that Firefox for Windows doesn't support plugins: it supports them, but only in desktop mode, and the user has the ability to switch.

Comment 16

[Brian R. Bondy [:bbondy]]

If we end up doing this, we'll also need to do another task for separating out HTTP cache since we have shared profiles. It may introduce other tasks too.  Even know it's not designed as a general way to distinguish Metro from Dektop Firefox, it would be a way web page authors use to detect the browser used.

I think we should punt on this for v1.  I understand and agree there's a problem, but I don't think it needs to be fixed in v1.

re Comment 15:
We do consider Metro and Desktop as 2 products even know they are exposed through some of the same binaries, and they have different search defaults and info.

Comment 17

[Jim Mathies [:jimm]]

(In reply to Brian R. Bondy [:bbondy] from comment #16)
> If we end up doing this, we'll also need to do another task for separating
> out HTTP cache since we have shared profiles. It may introduce other tasks
> too.  Even know it's not designed as a general way to distinguish Metro from
> Dektop Firefox, it would be a way web page authors use to detect the browser
> used.
> 
> I think we should punt on this for v1.  I understand and agree there's a
> problem, but I don't think it needs to be fixed in v1.
> 
> re Comment 15:
> We do consider Metro and Desktop as 2 products even know they are exposed
> through some of the same binaries, and they have different search defaults
> and info.


I think the cache should be separated anyway. We don't want metrofx polluting the desktop cache and causing us headaches down the road. There are other differences in the browsers that can impact content served to us - touch input support for example.

Also, I think there's a risk that if we don't provide something for plugins in v1, authors will just ignore the difference going forward.

Comment 18

[Jim Mathies [:jimm]]

(If we don't differentiate, we're going to get desktop browser content served to us, and that's going to suck for our users.)

Comment 19

[Gervase Markham [:gerv]]

(In reply to Jim Mathies [:jimm] from comment #18)
> (If we don't differentiate, we're going to get desktop browser content
> served to us, and that's going to suck for our users.)

By that do you mean "If we don't differentiate, then for websites which have a specifically Metro version, and which otherwise would have bothered to implement sniffing for whatever signal we set, then instead of the Metro version we will get the desktop version that everyone else gets, and that we get in desktop mode, and which is the kind of thing we get even in Metro mode from all sites which don't have a Metro version"?

I agree not getting the Metro version of sites which have one isn't awesome, but it's hardly a disaster.

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #15)
> Plugins are inherently platform-specific, so anyone who is sniffing for
> plugins needs to know the platform anyway. 

But "plugins are not supported on this platform" does not need to be a platform-specific message. If we invent one signal for that, we can use it on many platforms and sites will not have to update their code. If we do "this is Windows 8 Metro", then when/if there's another platform not supporting plugins, we'll need yet another signal.

> And it's clearly not true that
> Firefox for Windows doesn't support plugins: it supports them, but only in
> desktop mode, and the user has the ability to switch.

Which is precisely why my simple spec wasn't just "yes/no", but had 3 states, one of which was "you need to switch".

Gerv

Comment 20

[Benjamin Smedberg]

Solving the issue of a platform-generic message wasn't what this bug is about. It's not something that the b2g or android teams have asked for, because everyone already does UA sniffing to determine whether they can offer you a plugin at all. Metro specifically has the problem that we're not changing the UA string, so everyone thinks they can offer you a plugin.

I don't think that a generic API about whether plugins are available is something we should implement without general agreement from other vendors, and I don't think that the timeframe for Metro v1 allows for general agreement. So we should either have an API for detecting metro mode and solving the case for specific websites that care enough, or we should do nothing at all right now, discuss this on whatwg@, and perhaps implement a generic API later.

Comment 21

[Gervase Markham [:gerv]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #20)
> Solving the issue of a platform-generic message wasn't what this bug is
> about. It's not something that the b2g or android teams have asked for,
> because everyone already does UA sniffing to determine whether they can
> offer you a plugin at all. 

Right. And if we ever want them to stop UA sniffing, we need to provide a better, capabilities-based alternative.

> Metro specifically has the problem that we're not
> changing the UA string, so everyone thinks they can offer you a plugin.

(Where and when did we make that decision - someone remind me?)

> I don't think that a generic API about whether plugins are available is
> something we should implement without general agreement from other vendors,
> and I don't think that the timeframe for Metro v1 allows for general
> agreement.

What is that timeframe?

> So we should either have an API for detecting metro mode and
> solving the case for specific websites that care enough, or we should do
> nothing at all right now, discuss this on whatwg@, and perhaps implement a
> generic API later.

Having a quick conversation on the WHAT-WG mailing list won't take too long, and would be a good start. Someone may have a bright idea. Do we have official reps there who can do that for us, or do I need to join?

Gerv

Comment 22

[Jim Mathies [:jimm]]

(In reply to Gervase Markham [:gerv] from comment #21)
> > Metro specifically has the problem that we're not
> > changing the UA string, so everyone thinks they can offer you a plugin.
> 
> (Where and when did we make that decision - someone remind me?)

(In reply to Gervase Markham [:gerv] from comment #9)
> Site-specific UA stuff is coming, although it needs to be used sparingly.
> 
> I think we should follow Chrome's lead and have the Metro Firefox UA, by
> default, be the same as the desktop one. If the device has a touchscreen we
> might want to add a "Tablet" token (or "Touch" - that debate still isn't
> entirely dead). But otherwise we should keep it the same.
> 
> MetroFirefox/18.0a1 certainly needs to go.
> 
> Mozilla/5.0 (Windows NT 6.2; WOW64; rv:18.0) Gecko/18.8 Firefox/18.0 
> 
> Gerv

;) 

bug 787786

> > I don't think that a generic API about whether plugins are available is
> > something we should implement without general agreement from other vendors,
> > and I don't think that the timeframe for Metro v1 allows for general
> > agreement.
> 
> What is that timeframe?

We're rolling out to release with 28.

Comment 23

[Benjamin Smedberg]

> Right. And if we ever want them to stop UA sniffing, we need to provide a
> better, capabilities-based alternative.

You're making an incorrect assertion that we want them to stop UA-sniffing. Any site that provides a plugin installer needs to know the OS, and the UA (or navigator.platform) is the correct long-term way to do that. And if they don't require plugins, then this whole discussion is moot.

Comment 24

[Gervase Markham [:gerv]]

(In reply to Jim Mathies [:jimm] from comment #22)
> (In reply to Gervase Markham [:gerv] from comment #21)
> > > Metro specifically has the problem that we're not
> > > changing the UA string, so everyone thinks they can offer you a plugin.
> > 
> > (Where and when did we make that decision - someone remind me?)
> 
> (In reply to Gervase Markham [:gerv] from comment #9)
> > Site-specific UA stuff is coming, although it needs to be used sparingly.
> > 
> > I think we should follow Chrome's lead and have the Metro Firefox UA, by
> > default, be the same as the desktop one. 

Have we spoken to the Chrome team about whether they've encountered this issue and, if so, what they are recommending to sites?

> ;) 
> 
> bug 787786

Hey, I thought I would have been involved - I just didn't know the bug number :-)

Gerv

Comment 25

[Jim Mathies [:jimm]]

> Have we spoken to the Chrome team about whether they've encountered this
> issue and, if so, what they are recommending to sites?

They slap their desktop browser on top of the metro ui and load plugins that support pepper. So I don't think it's an major issue for them. AFAICT they use the same ua string as well as I can't find any posts about differences.

http://blog.chromium.org/2012/07/npapi-plug-ins-in-windows-8-metro-mode.html

Comment 26

[Gervase Markham [:gerv]]

Hmm. Why do we not, in Metro mode, claim to support whatever plugins are installed, and simply put an appropriate "actually, you need to switch" message in the plugin window - in the same way that we do the "click to play" UI? Is it because of hidden plugins? Do people really prompt for installation for those types of uses which use hidden plugins?

bsmedberg is right that many people offering plugins will need to know the OS, and the defined way to find that out is UA sniffing. (Except on Firefox OS, of course.) Some won't, and will make assumptions and just direct to the plugin download page - but then, they are perhaps unlikely to check some other flag either.

I think that we'd get 80% of the win here if we could get the standard Flash download page to detect whatever signal we send and warn people they need to switch modes. I think we'd have an uphill struggle getting all the sites to do it.

Gerv

Comment 27

[Jim Mathies [:jimm]]

(In reply to Gervase Markham [:gerv] from comment #26)
> Hmm. Why do we not, in Metro mode, claim to support whatever plugins are
> installed, and simply put an appropriate "actually, you need to switch"
> message in the plugin window - in the same way that we do the "click to
> play" UI? Is it because of hidden plugins? Do people really prompt for
> installation for those types of uses which use hidden plugins?

IMHO, from a ux perspective, this isn't great. Every site you visit would be littered with "actually, you need to switch" frames. The problem is made worse announcing we do support them when we don't. You can get a feel for this by enabling ctp on desktop and visiting sites like cnn.com.

I think we would prefer to keep page layout clean.

cc'ing yuan for her feedback, she's in charge of ux for metrofx.

Comment 28

[Jim Mathies [:jimm]]

Attachment: Add mozBrowserRuntime navigator prop

Going to avoid the plugin stuff and go with bsmedberg's rec on this. If we decide to do something more robust about plugins we can depreciate this.

Comment 29

[Benjamin Smedberg]

Comment on attachment 8348129 [details] [diff] [review]
Add mozBrowserRuntime navigator prop

I'm not a DOM peer.

Comment 30

[Peter Van der Beken [:peterv]]

Comment on attachment 8348129 [details] [diff] [review]
Add mozBrowserRuntime navigator prop

Review of attachment 8348129 [details] [diff] [review]:
-----------------------------------------------------------------

Why would we need to support detection of metro if even IE doesn't? If we want to do this we should at least talk to other browser vendors (eg in the WhatWG).
Aside from that it seems very wrong to put this behind a |#ifdef MOZ_METRO|.

Comment 31

[Jim Mathies [:jimm]]

(In reply to Peter Van der Beken [:peterv] from comment #30)
> Comment on attachment 8348129 [details] [diff] [review]
> Add mozBrowserRuntime navigator prop
> 
> Review of attachment 8348129 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Why would we need to support detection of metro if even IE doesn't?

They flip it around and ask that site authors to communicate active-x needs through headers - 
http://blogs.msdn.com/b/ie/archive/2012/01/31/web-sites-and-a-plug-in-free-web.aspx

We're trying to go the other way, providing the information up front. 

> If we
> want to do this we should at least talk to other browser vendors (eg in the
> WhatWG).

Any suggestions on who we can cc in here to help make that happen, or can anyone post representing mozilla?

Comment 32

[Gervase Markham [:gerv]]

Can we define the semantics here exactly? What does "immersive" mean? If it solely means "Metro" and we are never going to use this value for any other circumstances, we should call it that - and anyway, "immersive" sounds very marketing-y. If it means "get them to change mode so they can use plugins", we should call it something more like that.

If we are going to do this, we need to do _capability_ detection, because it's much less likely to break than some heuristic, implemented per site, based on UA or some other platform-like identifier. 

Are there any use cases for this other than the plugins one? If not, we should do a mozPluginsNotAvailableInThisMode or something.

Gerv

Comment 33

[Jim Mathies [:jimm]]

(In reply to Gervase Markham [:gerv] from comment #32)
> Can we define the semantics here exactly? What does "immersive" mean? If it
> solely means "Metro" and we are never going to use this value for any other
> circumstances, we should call it that - and anyway, "immersive" sounds very
> marketing-y. If it means "get them to change mode so they can use plugins",
> we should call it something more like that.
> 
> If we are going to do this, we need to do _capability_ detection, because
> it's much less likely to break than some heuristic, implemented per site,
> based on UA or some other platform-like identifier. 
> 
> Are there any use cases for this other than the plugins one? If not, we
> should do a mozPluginsNotAvailableInThisMode or something.

I believe so. Other feature differences between the two browsers can be independently detected. For example w3c touch support. 

I like 'mozPluginsNotAvailableInThisMode', or maybe just 'mozPluginsNotAvailable'?

Comment 34

[Gervase Markham [:gerv]]

My name was half in jest - it's a horrible name! :-) But if we are going that way, we should implement my proposal in comment 12, and have a call called mozGetPluginAvailability() or similar, returning:

"available" - plugin support is available; you may suggest installing missing plugins
"unavailable" - plugin support is not available; do not suggest installing missing plugins 
"switch" - plugin support is available in another configuration of the same browser; you may suggest a mode switch

And we should have the API on all platforms.

Gerv

Comment 35

[Jim Mathies [:jimm]]

(In reply to Gervase Markham [:gerv] from comment #34)
> My name was half in jest - it's a horrible name! :-) But if we are going
> that way, we should implement my proposal in comment 12, and have a call
> called mozGetPluginAvailability() or similar, returning:
> 
> "available" - plugin support is available; you may suggest installing
> missing plugins
> "unavailable" - plugin support is not available; do not suggest installing
> missing plugins 
> "switch" - plugin support is available in another configuration of the same
> browser; you may suggest a mode switch
> 
> And we should have the API on all platforms.
> 
> Gerv

Ok sounds good. I'll put this together.

Comment 36

[Benjamin Smedberg]

My strong objections to the .getPluginAvailability API remain. I think we'd be better off doing nothing than adding an API of that sort.

Comment 37

[Sam Foster [:sfoster] (he/him)]

Intuitively as a web developer I would expect to check if(navigator.plugins). I know that's going to throw for 1000s of sites that are assume plugins is an object, but to me that's what would make most sense, we don't need new API. 

We could/should show a one-time notification when we see <object>s on the page to explain that no matter how many times users install Flash etc, its still not going to work in the Firefox Touch for Windows 8 browser. That's the real problem I think. Existing detection scripts that follow best practices will correctly determine that Flash isn't installed, but assume this is something the user can fix. We can't do nothing, we do need to intervene *somehow* to reset these expectations.

It would be nice if we could know if the requested plugin is installed all desktop before prompting people to switch, I don't know if that's even possible though.

Comment 38

[Firefox Bug Husbandry Bot]

Mass close of bugs in obsolete product https://bugzilla.mozilla.org/show_bug.cgi?id=1350354