As a security precaution, we have turned on the setting "Require API key authentication for API requests" for everyone. If this has broken something, please contact bugzilla-admin@mozilla.org
Last Comment Bug 1269807 - (npapi-eol) Remove support for all NPAPI plugins (except Flash)
(npapi-eol)
: Remove support for all NPAPI plugins (except Flash)
Status: VERIFIED FIXED
: addon-compat, dev-doc-complete, site-compat
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: unspecified
: Unspecified All
: P2 normal with 3 votes (vote)
: mozilla52
Assigned To: Benjamin Smedberg [:bsmedberg]
:
: Benjamin Smedberg [:bsmedberg]
Mentors:
: 1317449 (view as bug list)
Depends on: 1332755 1263630 1306314 1307445 1307501 1308023 1310173 1311371 1311420 1330998
Blocks: support-win64 1092126 1279218 1296400 1308761 flash-click-to-play 1322402 1330529 846566 1171396 1183613 1270364 1270366 1295375 1317108 1317109 1317110 1317111 1318819 1318833 1320019 1320020
  Show dependency treegraph
 
Reported: 2016-05-03 10:38 PDT by Chris Peterson [:cpeterson]
Modified: 2017-01-20 15:22 PST (History)
63 users (show)
xidorn+moz: needinfo? (danialhorton)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
verified
52+

MozReview Requests
Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:
Show discarded requests

Attachments
Bug 1269807 - Remove support for all NPAPI plugins except for Flash, behind a pref. This will be disabled for ESR 52, but enabled for release 52. In the next cycle, the pref will be removed and this will be hardcoded. (58 bytes, text/x-review-board-request)
2016-09-27 10:55 PDT, Benjamin Smedberg [:bsmedberg]
jmathies: review+
Details | Review

Description User image Chris Peterson [:cpeterson] 2016-05-03 10:38:10 PDT
We're tentatively planning to remove NPAPI support (for plugins other than Flash) in Firefox 53 because Firefox 52 is the next ESR. We'd like an ESR with NPAPI support as a transition option for enterprise users that rely on Java.
Comment 1 User image Kohei Yoshino [:kohei] 2016-05-03 12:45:17 PDT
The current site compatibility doc is here: https://www.fxsitecompat.com/en-CA/docs/2015/plug-in-support-will-be-dropped-by-the-end-of-2016-except-flash/
Comment 2 User image David E. Ross 2016-05-04 16:29:50 PDT
I frequently visit a Web page that uses Java.  This page provides a very useful Java tool for designing new Web pages.  I strongly suspect that page is no longer being updated.  I also enjoy a one-person Web game that uses Java.  

I visit a number of Web sites that download PDF files for Adobe Reader fill-in.  

What recourse will I have to still have these capabilities?
Comment 3 User image Benjamin Smedberg [:bsmedberg] 2016-05-05 10:27:14 PDT
Beyond Firefox 51ESR we do not plan on any specific recourse. Oracle is stopping support for the Java NPAPI plugin at all, so there will be no secure way to do this. You can of course keep using an insecure browser/Java combo.

PDF will continue to render in-browser using the builtin mechanism (which we are improving) or you can choose to load in Acrobat reader as a standalone app.
Comment 4 User image Marty 2016-05-06 05:45:20 PDT
What about Google Chat/Hangouts, would this be affected? It uses two plugins: npgoogletalk.dll and npo1d.dll. That is very convenient when one doesn't have immediate access to a hardware interface like obitalk. AFAIK there is no desktop application similar to Skype so the plugin is the only way to make calls by way of gmail.
Comment 5 User image Masatoshi Kimura [:emk] 2016-05-06 07:30:04 PDT
Google Hangouts works without plugins only with Chrome, and Skype works without plugins only with Edge. What's a wonderful plugin-free world! :(
Comment 6 User image Marty 2016-05-06 11:52:52 PDT
(In reply to Masatoshi Kimura [:emk] from comment #5)
> Google Hangouts works without plugins only with Chrome, and Skype works
> without plugins only with Edge. What's a wonderful plugin-free world! :(

Millions of people every day use Google Hangouts to make calls. What better way to drive users to your competitors by denying them access as this bug will do?
Comment 7 User image Chris Peterson [:cpeterson] 2016-05-06 15:07:04 PDT
(In reply to Marty from comment #6)
> Millions of people every day use Google Hangouts to make calls. What better
> way to drive users to your competitors by denying them access as this bug
> will do?

Our telemetry [1] shows that, over the six-week release cycle of Firefox 45, the npgoogletalk plugin was activated a total of 268,100 times and googletalkbrowserplugin 91,190 times. Those are just plugin activations on a page, not necessarily actual Hangout calls. In contrast, Flash was activated over 40,000,000 times.

[1] http://mzl.la/1WODHLp
Comment 8 User image Marty 2016-05-06 18:59:41 PDT
The millions use it every day was not specific to Firefox but in total, although your telemetry figures are probably low considering that many disable that. The point is by removing what is a widely used service worldwide it means less potential for users of other browsers who depend on it crossing over to Firefox while losing those who do. Java I con understand but Google Hangouts is popular.
Comment 9 User image Ozzie 2016-06-08 16:01:01 PDT
51 is scheduled to be released on Jan 24 2017 according to the release calendar.  https://wiki.mozilla.org/RapidRelease/Calendar

52 is the next ESR to be released early March, if releasing every 6 weeks.
53 should be available mid-April, if releasing every 6 weeks.

I am kindly advocating to extend the stay of NPAPI plug-ins, specifically Silverlight, until August/September 2017 - probably release 56 or 57.  As a very large enterprise software vendor, we are doing everything we can to complete our UI migration and would be grateful to not disrupt the millions of users we have using payroll and benefits, HR, time and attendance, and scheduling.

Could you please entertain delaying the removal of NPAPI plug-ins until Sept 17 ?
Comment 10 User image Benjamin Smedberg [:bsmedberg] 2016-06-22 11:28:07 PDT
We are not going to extend NPAPI support on the release branch beyond the next ESR. If you need plugins in an enterprise environment, the 52 ESR may be an acceptable alternative for the rest of 2017.
Comment 11 User image Ozzie 2016-06-22 12:09:14 PDT
Thank you for confirming the timeline.
Comment 12 User image Kohei Yoshino [:kohei] 2016-07-01 10:43:34 PDT
My understanding is the NPAPI support will still be enabled in the 52 ESR channel but disabled in the 52 Release channel and beyond. Is this correct?
Comment 13 User image Chris Peterson [:cpeterson] 2016-07-01 11:28:14 PDT
(In reply to Kohei Yoshino [:kohei] from comment #12)
> My understanding is the NPAPI support will still be enabled in the 52 ESR
> channel but disabled in the 52 Release channel and beyond. Is this correct?

Yes. That is the current plan.
Comment 15 User image jbleasdale 2016-09-07 06:28:24 PDT
I have read conflicting information regarding NPAPI support in the ESR 52 release.
Will 52 ESR support all NPAPI plug-ins (including Silverlight) or just Java?
Really hoping that it is the former.
Comment 16 User image Chris Peterson [:cpeterson] 2016-09-07 10:00:11 PDT
(In reply to jbleasdale from comment #15)
> I have read conflicting information regarding NPAPI support in the ESR 52
> release.
> Will 52 ESR support all NPAPI plug-ins (including Silverlight) or just Java?
> Really hoping that it is the former.

ESR 52 will support all NPAPI plug-ins, including Silverlight and Java. The non-ESR release of Firefox 52 will only support Flash. Here is a recent blog post outlining the schedule:

https://blog.mozilla.org/futurereleases/2016/07/20/reducing-adobe-flash-usage-in-firefox/
Comment 17 User image rsx11m 2016-09-09 09:44:02 PDT
So, some builds will provide NPAPI support for all plugins (for a while at least) and others won't.

Can someone point to a more technical document or provide details on how this is intended to be implemented? Something like a build-time switch or a white list of "acceptable" plugins?
Comment 18 User image Chris Peterson [:cpeterson] 2016-09-09 12:12:32 PDT
(In reply to rsx11m from comment #17)
> Can someone point to a more technical document or provide details on how
> this is intended to be implemented? Something like a build-time switch or a
> white list of "acceptable" plugins?

The code to support other plugins will be removed, including removing hacks to work around known bugs in those plugins.
Comment 19 User image rsx11m 2016-09-09 14:07:20 PDT
Hmm, the Flash plugin is based on NPAPI - how can you remove the code for NPAPI while still maintaining support for the Flash plugin? Which part of your point am I missing?
Comment 20 User image Chris Peterson [:cpeterson] 2016-09-09 15:47:32 PDT
There will be a run-time check to block plugins other than Flash. Any NPAPI code that is not needed to support Flash will be removed over time.
Comment 21 User image rsx11m 2016-09-10 08:42:28 PDT
Ok, thanks. So, we are basically looking at a generalization of bug 1165981. I don't see much motivation though to explicitly spend time and effort to remove the "not needed to support Flash" code given that eventually the entire dom/plugins directory would go once Flash is phased out as well. Conversely, just changing platform checks to a build-time switch would be trivial and allow other Gecko applications or 3rd-party builds not on the ESR branch to continue supporting non-Flash plugins at the user's own risk, up to that point when Flash goes away for good and the code is entirely removed as a bulk.
Comment 22 User image Chris Peterson [:cpeterson] 2016-09-15 10:05:35 PDT
Once we drop support for NPAPI plugins other than Flash, we can then land bug 1270366 and bug 1270364 to make the named properties of navigator.plugins and navigator.mimeTypes unenumerable, as per spec.
Comment 23 User image Dan 2016-09-21 03:30:13 PDT
(In reply to Chris Peterson [:cpeterson] from comment #0)
> We're tentatively planning to remove NPAPI support (for plugins other than
> Flash) in Firefox 53 because Firefox 52 is the next ESR. We'd like an ESR
> with NPAPI support as a transition option for enterprise users that rely on
> Java.

Hey there, I'm just curious if the targeted rollout for the removal of NPAPI support is still Firefox 53? I've read various sources stating by the end of 2016, but I noticed that 53 is mooted to drop mid-April per the RapidRelease calendar, and just wanted to see if this timeline is mildly accurate?
Comment 24 User image rsx11m 2016-09-21 07:50:00 PDT
Dan, as you can see from the later comments, disabling NPAPI support for anything but Flash is scheduled for 52 "retail" releases (not 53, so this should be early 2017 if implemented as planned), but should be retained in the 52 ESR releases for about another year:

(Quoting Chris Peterson [:cpeterson] from comment #16)
> ESR 52 will support all NPAPI plug-ins, including Silverlight and Java. The
> non-ESR release of Firefox 52 will only support Flash. Here is a recent blog
> post outlining the schedule:
> 
> https://blog.mozilla.org/futurereleases/2016/07/20/reducing-adobe-flash-usage-in-firefox/
Comment 25 User image Benjamin Smedberg [:bsmedberg] 2016-09-27 10:55:21 PDT Comment hidden (mozreview-request)
Comment 26 User image Benjamin Smedberg [:bsmedberg] 2016-09-27 10:58:59 PDT
https://treeherder.mozilla.org/#/jobs?repo=try&revision=a1bdb92c7e36 will hopefully have results once infra issues are solved and I can retrigger.
Comment 27 User image Jim Mathies [:jimm] 2016-09-27 13:06:42 PDT
Comment on attachment 8795409 [details]
Bug 1269807 - Remove support for all NPAPI plugins except for Flash, behind a pref. This will be disabled for ESR 52, but enabled for release 52. In the next cycle, the pref will be removed and this will be hardcoded.

https://reviewboard.mozilla.org/r/81468/#review80066
Comment 28 User image Jim Mathies [:jimm] 2016-09-27 13:08:57 PDT
We are currently considering EOL'ing Windows XP on ESR 52. Chris mentioned we might want to add Silverlight to this list for netflix use since there's no widevine support on XP. Is this correct Chris?
Comment 29 User image Benjamin Smedberg [:bsmedberg] 2016-09-27 13:30:04 PDT
All plugins will still be available on ESR 52, so we're explicitly fine there.
Comment 30 User image Chris Peterson [:cpeterson] 2016-09-28 12:07:15 PDT
Comment on attachment 8795409 [details]
Bug 1269807 - Remove support for all NPAPI plugins except for Flash, behind a pref. This will be disabled for ESR 52, but enabled for release 52. In the next cycle, the pref will be removed and this will be hardcoded.

https://reviewboard.mozilla.org/r/81468/#review80384

::: dom/plugins/base/nsPluginHost.cpp:2100
(Diff revision 1)
>  
> +static bool
> +PluginInfoIsFlash(const nsPluginInfo& info)
> +{
> +  if (!strcmp(info.fDescription, "Shockwave Flash")) {
> +    return false;

Should this code path return true? fDescription is "Shockwave Flash" here.
Comment 31 User image Pulsebot 2016-10-03 13:49:42 PDT
Pushed by bsmedberg@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/fea530023849
Remove support for all NPAPI plugins except for Flash, behind a pref. Tests that use the testplugin for now set the pref to keep it working. This will be disabled for ESR 52, but enabled for release 52. In the next cycle, the pref will be removed and this will be hardcoded. r=jimm
Comment 32 User image Peja Stija 2016-10-03 16:40:49 PDT
What about MS Silverlight ?
My television provider uses it as an online streaming source to watch TV.
Comment 33 User image Chris Peterson [:cpeterson] 2016-10-03 17:24:19 PDT
(In reply to Peja Stija from comment #32)
> What about MS Silverlight ?
> My television provider uses it as an online streaming source to watch TV.

Peja, who is your television provider? What solution do they use to stream video in Chrome? If they use HTML5 video in Chrome (Widevine DRM), then we can ask them to use the same solution in Firefox.
Comment 34 User image Danial Horton 2016-10-03 20:20:44 PDT
maybe you guys should get your fullscreen html5 video player to not stutter fullscreen games on a different monitor (chrome doesn't do this) before removing access to the only way to watch netflix with silverlight (since it doesn't make things stutter)
Comment 35 User image Phil Ringnalda (:philor) 2016-10-03 20:21:35 PDT
https://hg.mozilla.org/mozilla-central/rev/fea530023849
Comment 36 User image Xidorn Quan [:xidorn] (UTC+10) 2016-10-03 20:38:25 PDT
(In reply to Danial Horton from comment #34)
> maybe you guys should get your fullscreen html5 video player to not stutter
> fullscreen games on a different monitor (chrome doesn't do this) before
> removing access to the only way to watch netflix with silverlight (since it
> doesn't make things stutter)

What do you mean by "stutter fullscreen games"? Could you file a bug with more detailed description and ideally the steps to reproduce?
Comment 37 User image Kohei Yoshino [:kohei] 2016-10-03 22:21:58 PDT
Updated the site compatibility doc: https://www.fxsitecompat.com/en-CA/docs/2016/plug-in-support-has-been-dropped-other-than-flash/
Comment 38 User image Jeff Muizelaar [:jrmuizel] 2016-10-06 13:16:20 PDT
I get "Skype for Business Web App Plug-in" when I visit http://people.mozilla.org/~jmuizelaar/implementation-tests/plugins.html on OS X with a Nightly from Oct 6. Is this expected?
Comment 39 User image Chris Peterson [:cpeterson] 2016-10-06 19:12:46 PDT
(In reply to Jeff Muizelaar [:jrmuizel] from comment #38)
> I get "Skype for Business Web App Plug-in" when I visit
> http://people.mozilla.org/~jmuizelaar/implementation-tests/plugins.html on
> OS X with a Nightly from Oct 6. Is this expected?

Benjamin, navigator.plugins shows more than just Flash in Nightly 52.0a1 build 2016-10-06 on macOS. Is that expected on Mac?

Adobe Acrobat NPAPI Plug-in, Version 11.0.17
AdobeAAMDetect
AdobeExManDetect
Google Earth Plug-in
Google Earth Plug-in
Google Talk Plugin
Google Talk Plugin Video Renderer
Java Applet Plug-in
Shockwave Flash
Silverlight Plug-In
Comment 40 User image Peja Stija 2016-10-07 11:11:51 PDT
(In reply to Chris Peterson [:cpeterson] from comment #33)
> (In reply to Peja Stija from comment #32)
> > What about MS Silverlight ?
> > My television provider uses it as an online streaming source to watch TV.
> 
> Peja, who is your television provider? What solution do they use to stream
> video in Chrome? If they use HTML5 video in Chrome (Widevine DRM), then we
> can ask them to use the same solution in Firefox.

Sorry for the late reply Chris.
My television provider is Telenet (Belgium).
In Chrome it tells me that "your browser does not support Silverlight", so I can't watch TV using any Chrome like browser, only Firefox & IE until now.
Seems like IE will be the only way to still watch online TV.
Comment 41 User image Chris Peterson [:cpeterson] 2016-10-07 11:19:15 PDT
(In reply to Peja Stija from comment #40)
> My television provider is Telenet (Belgium).
> In Chrome it tells me that "your browser does not support Silverlight", so I
> can't watch TV using any Chrome like browser, only Firefox & IE until now.
> Seems like IE will be the only way to still watch online TV.

Thanks. I'll add Telenet to our list of video services we should contact. That's unfortunate they don't have a solution for Chrome or Edge either.
Comment 42 User image Bartosz Piec 2016-10-07 11:40:56 PDT
On my Windows it also shows "Microsoft Office 2016" plugin. That is probably a helper to allow editing of Sharepoint documents in MS Office applications. Disabling NPAPI will also break this (which doesn't work in Chrome btw, now I know why…).
Comment 43 User image bsun0000 2016-10-07 23:04:23 PDT
Perfectly.. i removed Flash from my browser a long time ago, but now he is a LAST (and so **** useless) plugin, that i can use.. Can i get my NPAPI plugins back or the only solution - is to remove firefox?
Comment 44 User image Benjamin Smedberg [:bsmedberg] 2016-10-08 08:43:50 PDT
There was a bug with this where Flash sometimes wasn't activated for new users, and existing users who had plugins would keep seeing them. Those were both fixed in bug 1307501 for yesterday's nightly.
Comment 45 User image Vangelis 2016-10-08 12:10:09 PDT
(In reply to Benjamin Smedberg from comment #44)
> and existing users who had plugins would keep seeing them. 
> Those were both fixed in bug 1307501 for yesterday's nightly.

I am afraid bug 1307501 did not fix things properly at my end. 

I am writing this from a portable (PAF) installation of latest Nightly 52.0a1 32bit (build ID 20161008030200), OS is Windows Vista SP2 x86 fully patched; I have a plugins.dat file inside 
my profile which contains mentions of a variety of NPAPI stuff (Acrobat, JRE, Quicktime etc.) on my OS, those plugins (incl. Flash) are still being loaded correctly in Nightly, appear in my about:plugins page right now and function as expected when needed - is this the correct behaviour? 

Now, after a bit of experimentation, I have found that: 

1. Exit Nightly
2. Delete (or move elsewhere) "old" plugins.dat file from within profile folder.
3. Restart Nightly
4. Result: A new smaller plugins.dat file is recreated, about:plugins now only lists 
Flash from the previous NPAPI group (along with OpenH264, Primetime CDM, Widewine CDM).

And what if I want to temporarily override this new behaviour? 
As per this bug 1269807, I would have to create a new boolean pref named "plugin.load_flash_only", 
set its value to "false" and restart Nightly; again, I find this is not the case at my setup; 
only creating the pref followed by a browser restart does not "cut" it; manual deletion 
of previous plugins.dat profile file is again necessary for the new pref to function.

Since this is the first time I post on Bugzilla, I totally lack bugzilla skills 
and related etiquette; but deemed it necessary to communicate my findings... 
Maybe what I post is only related to the PAF installation but many of us 
nightly testes use it, since it's completely isolated from a normal default Fx installation...
Please use the info posted to further troubleshoot...
 
Link to "online installer" of portable nightly-52.0a1-32bit:  

http://downloads.sourceforge.net/portableapps/FirefoxPortableNightly_52.0_Alpha_1_Pre_English_online.paf.exe

(official J.T.Haller repo)
Comment 46 User image Vangelis 2016-10-08 12:31:23 PDT
From my comment #45
> plugins.dat

Many apologies! 
Replace all instances of "plugins.dat" in my previous comment with 

pluginreg.dat

which is what I intended to write...

Very sorry for the error...
Comment 47 User image Benjamin Smedberg [:bsmedberg] 2016-10-09 00:30:26 PDT
This "pref" is only intended for ESR deployment, not setting by individual users, so we don't regenerate the plugin cache when it changes.
Comment 48 User image Nikolay Martynov 2016-10-11 09:52:13 PDT
Dropping npapi without providing working alternatives for Google Hangouts (and to large extent netflix) seems like a perfect move to reduce FFs market share even more.

People may be able to get away without netflix (and it was hacky to use it before to begin with). But non working Hangouts will be last drop to move off FF because there is literally no alternative and people use Hangouts for work. It might be no a large fraction in telemetry (for some strange reason) - but these are most likely 'power users' that will take other people with them.

So for what I can do I urge mozilla to reconsider this decision and make sure users have a way to continue using hangouts and netflix with latest FF versions.
Comment 49 User image Chris Peterson [:cpeterson] 2016-10-11 11:31:46 PDT
(In reply to Nikolay Martynov from comment #48)
> Dropping npapi without providing working alternatives for Google Hangouts
> (and to large extent netflix) seems like a perfect move to reduce FFs market
> share even more.

We care about Hangouts and Netflix, too. NPAPI is no longer needed for Netflix because they now use HTML5 video (Widevine EME) on Windows and Mac. (Widevine is also available on Linux and Netflix plans to support Firefox on Linux for the first time.)

We are working with the Google Hangouts team. They are porting Hangouts to use WebRTC in Firefox so NPAPI plugins won't be necessary. Their port should be complete by the end of this year, before Firefox 52 drops NPAPI support in the Firefox Release channel.
Comment 50 User image Nikolay Martynov 2016-10-11 12:22:09 PDT
Thank you for prompt response.

Yeah, I've seen notes about Netflix being supported on Linux with EME but could not make it work in firefox-trunk yet - didn't spend much time figuring it out.

As far as Google Hangouts goes I hope that this gets resolved for all applicable platforms including Linux before disabling NPAPI lands in release. There is a history of Linux lagging behind (and Netflix is a good example of that) - so I hope that removing features on platforms would be matched with replacement for those.

Thanks again!
Comment 51 User image Bill Gianopoulos [:WG9s] 2016-10-14 05:56:22 PDT
My major issue with all of this is Linux support for the Gnome integration.  The lack of this support makes it far more difficult to install gnome shell extensions.  I realize this is listed as a Chrome parity bug, but that is the whole issue if chrome dropped support for this integration then our support for this is a differentiator in keeping our dominance in the preferred browser from may Linux Distributions.
Comment 52 User image Bill Gianopoulos [:WG9s] 2016-10-16 07:04:34 PDT
And one more criticism of this change?  please explain why this code was not added to the already existing nsPluginHost::ShouldAddPlugin rather than adding an entirely new function and codepath?
Comment 53 User image Bill Gianopoulos [:WG9s] 2016-10-16 07:15:05 PDT
Just so you know having this type of check in two places does not mean it is just 2 times a likely that a place a change needs to be made will be missed anyone finding one or the other of these will be 100% convinced that they have found the correct place for their change. Can we please combine this into the more generically named already existing function?
Comment 54 User image Bill Gianopoulos [:WG9s] 2016-10-16 07:17:53 PDT
Oh and we already decided we needed to include siverlight/moonlight in the permitted plug-ins.  please pay attention.
Comment 55 User image Marco Castelluccio [:marco] 2016-10-16 08:06:34 PDT
Please, don't reopen fixed bugs over minor criticism.

If you think we should have reused `ShouldAddPlugin`, and if you think
it is important, please open a new bug.

If you don't agree with the decision of NPAPI EOL, send a message to
one of the mailing lists and explain your reasons. Bugzilla is not
the right place for these discussions.
Comment 56 User image Bill Gianopoulos [:WG9s] 2016-10-16 08:09:17 PDT Comment hidden (spam)
Comment 57 User image Bill Gianopoulos [:WG9s] 2016-10-16 08:22:18 PDT Comment hidden (advocacy)
Comment 58 User image Bill Gianopoulos [:WG9s] 2016-10-16 08:24:26 PDT Comment hidden (advocacy)
Comment 59 User image Marco Castelluccio [:marco] 2016-10-16 08:47:16 PDT
(In reply to Bill Gianopoulos [:WG9s] from comment #57)
> Had this actually been advertised in a way it should have been I would have
> brought this up before this got approved.  I don't like the you were kept in
> the dark and now it is too late tyoe attitude.

This has been announced and discussed several times. A quick search returns:
https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/
https://blog.mozilla.org/futurereleases/2016/07/20/reducing-adobe-flash-usage-in-firefox/
https://www.fxsitecompat.com/en-CA/docs/2016/plug-in-support-has-been-dropped-other-than-flash/

(In reply to Bill Gianopoulos [:WG9s] from comment #58)
> I really do not think this is at all in the spirit of the Mozilla Manifesto.

Bill, as I already said in my comment, Bugzilla is a bug tracking system and not the place for this kinds of discussions. If you think NPAPI plugins are still important for the web, please start a discussion explaining your reasons in one of the Mozilla mailing lists.
Comment 60 User image rexyrexy2 2016-10-21 09:14:45 PDT Comment hidden (offtopic)
Comment 61 User image rexyrexy2 2016-10-21 09:24:58 PDT Comment hidden (offtopic)
Comment 62 User image Sylvestre Ledru [:sylvestre] 2016-10-24 07:25:04 PDT
Release Note Request (optional, but appreciated)
[Why is this notable]: Big change!
[Suggested wording]: NPAPI support removed (for plugins other than Flash) 
[Links (documentation, blog post, etc)]:
Comment 63 User image Tim Lynch 2016-10-24 12:22:06 PDT
I help design a web application that currently relies on NPAPI plug-ins, and we'd like to update it to support returning an appropriate explanatory error message to users of versions of Firefox that won't support NPAPI.  In similar situations in the past, we have checked the browser's user agent string for browser versions that we can't support.  However, as I understand the above thread, in March, 2017 Firefox will release:
- Firefox 52 without support for NPAPI
- Firefox 52 ESR with support for NPAPI
What can I use from the user-agent or otherwise to distinguish between these two versions?  Will both of these browser's user-agent strings say "Firefox/52.0"?  

Looking at Firefox 45.4 ESR for comparison's sake, I don't notice anything in the user-agent that denotes it as as an ESR release; it just says "Firefox/45.0".
Comment 64 User image Chris Peterson [:cpeterson] 2016-10-24 14:34:16 PDT
(In reply to Tim Lynch from comment #63)
> What can I use from the user-agent or otherwise to distinguish between these
> two versions?  Will both of these browser's user-agent strings say
> "Firefox/52.0"?  
> 
> Looking at Firefox 45.4 ESR for comparison's sake, I don't notice anything
> in the user-agent that denotes it as as an ESR release; it just says
> "Firefox/45.0".

That's a good question. Unfortunately, you can't detect ESR from the server side because both ESR and non-ESR releases have the same User-Agent string.

You may be able to detect ESR on the client side using JavaScript. Some ideas:

* Test for (unrelated) features that may have been disabled in ESR. For example, navigator.serviceWorker was disabled in ESR 45, but it is likely to be enabled in ESR 52. I don't know what new features might be disabled in ESR 52.

* navigator.buildID is a build timestamp string (e.g. "20161024030205") and might be different for ESR and non-ESR builds of 52.

* Check whether there are any NPAPI plugins other than Flash in navigator.plugins (e.g. if navigator.plugins.length > 1). Most Windows users will have some random plugins installed, such as Silverlight or Adobe Acrobat Reader. If a user has only "Shockwave Flash" in navigator.plugins, there is a reasonable chance they are on ESR.
Comment 65 User image moriel5 2016-10-27 13:17:59 PDT
We Gnome users also need the "Gnome Shell Integration" plugin to function (until a PPAPI plugin is developed, at least).
Can it also be added to the exception list for Linux users?
Comment 66 User image Aaron Klotz [:aklotz] 2016-10-27 13:28:29 PDT
(In reply to moriel5 from comment #65)
> (until a PPAPI plugin is developed, at least).

PPAPI is not going to be available for general use outside of Flash and PDF viewing.
Comment 67 User image Marco Castelluccio [:marco] 2016-10-27 13:42:07 PDT
(In reply to moriel5 from comment #65)
> We Gnome users also need the "Gnome Shell Integration" plugin to function
> (until a PPAPI plugin is developed, at least).
> Can it also be added to the exception list for Linux users?

They are working on a WebExtension for Firefox: https://wiki.gnome.org/Projects/GnomeShellIntegrationForChrome/RoadMap.
Comment 68 User image moriel5 2016-10-27 17:43:09 PDT
(In reply to Aaron Klotz from comment #66)
> PPAPI is not going to be available for general use outside of Flash and PDF viewing.

I understand that Chrome does not support other PPAPIs however, what do you meant by PPAPI not being available for other uses?

(In reply to Marco Castelluccio from comment #67)
>They are working on a WebExtension for Firefox:

Thanks, I did not know that.
However, as development has still not actually begun yet on the WebExtension (based upon the roadmap), we still need the "Gnome Shell Integration" NPAPI plugin to be on the exception list, at least for version 52 (why is the override switch not available for Nightly?).
Comment 69 User image Benjamin Smedberg [:bsmedberg] 2016-11-15 06:26:41 PST
*** Bug 1317449 has been marked as a duplicate of this bug. ***
Comment 70 User image Stephen Morris 2016-11-15 12:43:54 PST
I raised bug 1317449 which has been raised as a duplicate of this one. A number of the plugins I have that won't work with Firefox Nightly 53 also didn't work with Firefox Nightly 52 either, was this intended functionality? Also a number of plugins that Firefox won't use are supplied as a standard part of the Fedora Linux Distribution, does this change mean that they will have to rewrite their plugins to work with Firefox, and, if they do will that mean those plugins will not work with any other browser. The issue I can see with this approach is that distributons like Fedora will refuse to support Firefox, which would be unfortunate.
Comment 71 User image Chris Peterson [:cpeterson] 2016-11-15 13:03:34 PST
(In reply to Stephen Morris from comment #70)
> I raised bug 1317449 which has been raised as a duplicate of this one. A
> number of the plugins I have that won't work with Firefox Nightly 53 also
> didn't work with Firefox Nightly 52 either, was this intended functionality?
> Also a number of plugins that Firefox won't use are supplied as a standard
> part of the Fedora Linux Distribution, does this change mean that they will
> have to rewrite their plugins to work with Firefox, and, if they do will
> that mean those plugins will not work with any other browser. The issue I
> can see with this approach is that distributons like Fedora will refuse to
> support Firefox, which would be unfortunate.

This is by design. Firefox 52 and later no longer supports any NPAPI plugins other than Flash. The ESR channel of Firefox 52, however, will continue to support all NPAPI plugins, including Fedora's plugins, until 2018.

https://blog.mozilla.org/futurereleases/2016/07/20/reducing-adobe-flash-usage-in-firefox/
Comment 72 User image Benjamin Smedberg [:bsmedberg] 2016-11-15 13:31:53 PST
I seriously doubt that this change would drive Linux distributions to switch/stop distributing Firefox, since Chromium as the major competitor already doesn't support NPAPI plugins.
Comment 73 User image Michał Gołębiowski [:mgol] 2016-11-15 15:12:30 PST
Is it too late to delay this until Firefox 53? My main concern is that ESR is not very popular so sites ignore its existence and the VOD sites usually just UA-sniff for browsers/versions with Silverlight support, advising other users to switch browsers[1]. Those sites will notice Firefox 52 dropped support for Silverlight and will not even try to work there, automatically excluding people on Firefox 52 ESR.

[1] until they go HTML5 but I know at least one popular Polish VOD that hasn't done that yet
Comment 74 User image Bill Gianopoulos [:WG9s] 2016-11-15 15:35:46 PST
A bigger issue here is it is difficult to determine the difference between 52.0 and 52.0 ESR to determine which method to use it would be far simpler for all for version 52 and version 52 ESR to behave the same and have the new behavior be in versions > 52.
Comment 75 User image Daniel Cater 2016-11-16 14:23:33 PST
I do think having this difference between Firefox 52 and Firefox 52 ESR (without any difference in the User Agent string) is going to cause problems. Particularly as getting rid of / hardcoding the non-standard navigator.buildID is also a goal.

This then forces people to build more flaky detection logic around plugin enumeration, or accidentally block out people on ESR 52 with user agent checks.

I think a 6-week wait would make things a lot simpler.
Comment 76 User image Bill Gianopoulos [:WG9s] 2016-11-16 14:26:26 PST
I think that is what I said having 52.0 and 52.0 ESR with the same user agent string is just the lamest idea I have heard of this year.

Sorry to be so blunt.
Comment 77 User image Bill Gianopoulos [:WG9s] 2016-11-16 14:29:30 PST
Deferring the removal to 53 would make this all so much simpler than having lots of people generate really weird code to try to tell the difference between 53 and 53ESR to work differently.  This is really a really stupid.

Just my opinion. I could be wrong!
Comment 78 User image Bill Gianopoulos [:WG9s] 2016-11-16 14:30:29 PST
> between 53 and 53ESR to work differently.

Oops I meant between 52 and 53ESR.
Comment 79 User image Ritu Kothari (:ritu) 2016-11-18 13:19:03 PST
Added to Fx52 Aurora release notes
Comment 80 User image Cpuroast 2016-11-21 10:20:33 PST
I agree that making Firefox 52 and Firefox 52 ESR match as far as NPAPI behaviour and simply disabling everything except flash in Firefox 53 would make the most sense, since both instances share same version number, they should have the same features and behaviour.

Changing it in Firefox 53 would make a clear differentiation in the cut-off version for NPAPI plugins other than flash.

As in Firefox 53 ships, Firefox 52 is no longer supported. Regular releases are now restricted to Flash only support.
If plugins other than Flash are still required, use Firefox 52 ESR until the next ESR release ends it completely.
Comment 81 User image Srinivas 2016-11-21 22:46:20 PST
WE are using "Skype for Business web app plug-in" via NPAPI. It uses the plug-in: npGatewayNpapi.dll. So we would like to hear will it be affected after the Remove support for all NPAPI plugins? Do we need to do any changes from our side to make it work or it will work as it before?

Thanks in advance.
Srinivas.
Comment 82 User image Chris Peterson [:cpeterson] 2016-11-21 23:29:10 PST
(In reply to Srinivas from comment #81)
> WE are using "Skype for Business web app plug-in" via NPAPI. It uses the
> plug-in: npGatewayNpapi.dll. So we would like to hear will it be affected
> after the Remove support for all NPAPI plugins? Do we need to do any changes
> from our side to make it work or it will work as it before?

Firefox 52 will no longer support the "Skype for Business" NPAPI plugin. Microsoft is updating their "Skype for Web" product to use WebRTC that is compatible other browsers, but I don't know Microsoft's current schedule:

https://blogs.office.com/2015/09/18/enabling-seamless-communication-experiences-for-the-web-with-skype-skype-for-business-and-microsoft-edge/
Comment 83 User image Ozzie 2016-11-28 08:38:08 PST
(In reply to Chris Peterson [:cpeterson] from comment #64)
> (In reply to Tim Lynch from comment #63)
> > What can I use from the user-agent or otherwise to distinguish between these
> > two versions?  Will both of these browser's user-agent strings say
> > "Firefox/52.0"?  
> > 
> > Looking at Firefox 45.4 ESR for comparison's sake, I don't notice anything
> > in the user-agent that denotes it as as an ESR release; it just says
> > "Firefox/45.0".
> 
> That's a good question. Unfortunately, you can't detect ESR from the server
> side because both ESR and non-ESR releases have the same User-Agent string.
> 
> You may be able to detect ESR on the client side using JavaScript. Some
> ideas:
> 
> * Test for (unrelated) features that may have been disabled in ESR. For
> example, navigator.serviceWorker was disabled in ESR 45, but it is likely to
> be enabled in ESR 52. I don't know what new features might be disabled in
> ESR 52.
> 
> * navigator.buildID is a build timestamp string (e.g. "20161024030205") and
> might be different for ESR and non-ESR builds of 52.
> 
> * Check whether there are any NPAPI plugins other than Flash in
> navigator.plugins (e.g. if navigator.plugins.length > 1). Most Windows users
> will have some random plugins installed, such as Silverlight or Adobe
> Acrobat Reader. If a user has only "Shockwave Flash" in navigator.plugins,
> there is a reasonable chance they are on ESR.

Chris, thanks for the advice.  When will the 52 ESR dev build be available for testing so we can try to differentiate between 52 and 52 ESR ?  We are using the dev build of 52 but can't seem to locate the dev build of 52 ESR.  Along with many other vendors, we need to guide our users upgrading from 51 to 52, that they may need to switch to 52 ESR to continue to use their appropriate plug-in for a few more months.
Comment 84 User image Chris Peterson [:cpeterson] 2016-11-28 10:15:21 PST
(In reply to Ozzie from comment #83)
> Chris, thanks for the advice.  When will the 52 ESR dev build be available
> for testing so we can try to differentiate between 52 and 52 ESR ?  We are
> using the dev build of 52 but can't seem to locate the dev build of 52 ESR. 
> Along with many other vendors, we need to guide our users upgrading from 51
> to 52, that they may need to switch to 52 ESR to continue to use their
> appropriate plug-in for a few more months.

The ESR 52 builds won't be available until Beta 52 is preparing to merge to the Release channel (March 2017). The ESR builds will be posted on the Mozilla ftp server here:

http://ftp.mozilla.org/pub/firefox/releases/
Comment 85 User image Javier 2016-12-06 14:22:32 PST
Are you still on track to deprecate NPAPI for March 2017 (52)?
Comment 86 User image Anne 2016-12-06 14:44:47 PST
Is Mozilla52 release timeline March 2017 or is it December 2016? Is NPAPI (Silverlight Support) part of this release? Reason for my question is that I have seen 2 blogs from Firefox - one mentioned end of 2016 while the other one mentioned March 2017 so I just want to confirm. 
I'd greatly appreciate your help. Thank you
Comment 87 User image Michał Gołębiowski [:mgol] 2016-12-06 15:03:01 PST
(In reply to Anne from comment #86)
> Is Mozilla52 release timeline March 2017 or is it December 2016? Is NPAPI
> (Silverlight Support) part of this release? Reason for my question is that I
> have seen 2 blogs from Firefox - one mentioned end of 2016 while the other
> one mentioned March 2017 so I just want to confirm. 
> I'd greatly appreciate your help. Thank you

See https://wiki.mozilla.org/RapidRelease/Calendar. "Future branch dates", the "release" column. This info is getting updated if anything changes.
Comment 88 User image Chris Peterson [:cpeterson] 2016-12-06 15:48:01 PST
(In reply to Javier from comment #85)
> Are you still on track to deprecate NPAPI for March 2017 (52)?

Yep. All NPAPI plugins except Flash have been disabled in Firefox 52 (now in the Dev Edition channel), which should ship to the Release channel on March 7, 2017.
Comment 89 User image Marek 2016-12-16 06:52:17 PST
So what exactly will happen on March 7th? Firefox will update to 52, and all pages using Silverlight will stop working? 
Will there be any info that this version no longer support NPAPI plugins but it's still supported by ESR version?

Or will you handle this as Chrome did - just informing, that content need Silverlight plug-in, that you can install, even though it will not make any difference (as it's not supported anymore)? 

I want to know what would be practical impact for users runnning Silvelight web applications.
Comment 90 User image Benjamin Smedberg [:bsmedberg] 2016-12-16 06:54:52 PST
Yes, Firefox will update to 52 and pages that require silverlight will stop working. There will be no notification in the webpage: if the site provides fallback content we will display that instead. In the addon manager plugins pane there is a notification and a link to support.mozilla.org for more information.
Comment 91 User image Marek 2016-12-16 06:59:02 PST
(In reply to Benjamin Smedberg [:bsmedberg] from comment #90)
> Yes, Firefox will update to 52 and pages that require silverlight will stop
> working. There will be no notification in the webpage: if the site provides
> fallback content we will display that instead. In the addon manager plugins
> pane there is a notification and a link to support.mozilla.org for more
> information.

Thank you very  much for quick response :)
Comment 92 User image Bill Gianopoulos [:WG9s] 2016-12-25 10:50:27 PST
(In reply to moriel5 from comment #68)
> (In reply to Aaron Klotz from comment #66)
> > PPAPI is not going to be available for general use outside of Flash and PDF viewing.
> 
> I understand that Chrome does not support other PPAPIs however, what do you
> meant by PPAPI not being available for other uses?
> 
> (In reply to Marco Castelluccio from comment #67)
> >They are working on a WebExtension for Firefox:
> 
> Thanks, I did not know that.
> However, as development has still not actually begun yet on the WebExtension
> (based upon the roadmap), we still need the "Gnome Shell Integration" NPAPI
> plugin to be on the exception list, at least for version 52 (why is the
> override switch not available for Nightly?).

I filed bug 1325827 including a patch to permit this plugin.
Comment 93 User image Yuri Konotopov 2016-12-25 11:16:15 PST
(In reply to moriel5 from comment #68)
> However, as development has still not actually begun yet on the WebExtension
> (based upon the roadmap), we still need the "Gnome Shell Integration" NPAPI
> plugin to be on the exception list, at least for version 52 (why is the
> override switch not available for Nightly?).

Firefox support was added to GNOME Shell integration for Chrome.

WebExtension was approved by Mozilla team recently.
Version 8 of chrome-gnome-shell will be release on Jan 4, 2017 with Firefox support.

See also:
https://bugzilla.gnome.org/show_bug.cgi?id=754316
https://wiki.gnome.org/Projects/GnomeShellIntegrationForChrome/Installation
Comment 94 User image Nulled Pointer 2017-01-10 11:46:17 PST
FF 52 will have user preferences (about:config) which will allow user to user non-flash plugin?

As per http://www.ghacks.net/2016/10/06/firefox-52-nightly-plugin-support-except-flash-dropped/ 
> March 7, 2017 -- Firefox 52 and Firefox 52 ESR are released. All plugins but Flash are disabled by 
> default. Mozilla Firefox users may flip a preference switch to enable support for non-Flash NPAPI plugins 
> in Firefox 52. Firefox 52 ESR will support plugins throughout its lifecycle (until Firefox 60 ESR is 
> released). Firefox users may flip the preference plugin.load_flash_only to false to re-enable support for 
> other NPAPI plugins.

And FF 52 ESR will not require any such preference?
Comment 95 User image Nulled Pointer 2017-01-10 11:51:27 PST
Another question, I downloaded FF 52 today from dev channel and was able to get NPAPI plugin working on MAC, but based on comments above I was NOT expecting it to work.
Version 52.0a2 (2017-01-10) (64-bit).
Comment 96 User image Chris Peterson [:cpeterson] 2017-01-10 13:11:46 PST
(In reply to nishantkumar05 from comment #94)
> FF 52 will have user preferences (about:config) which will allow user to
> user non-flash plugin?

Yes. The plugin.load_flash_only pref is available in FF 52.

> And FF 52 ESR will not require any such preference?

Yes. The plugin.load_flash_only pref will default to true in FF 52 ESR.

(In reply to nishantkumar05 from comment #95)
> Another question, I downloaded FF 52 today from dev channel and was able to
> get NPAPI plugin working on MAC, but based on comments above I was NOT
> expecting it to work.

That is surprising. What NPAPI plugin were you able to load and on what web page?
Comment 97 User image Nulled Pointer 2017-01-10 14:32:05 PST
This is F5 Networks plugin with following MIME:
"application/x-f5-sam-inspectionhost  f5 sam inspection host plugin"
This is enterprise only plugin, we requested to whitelist it at one point, and its not published on the store. And this plugin is signed on addon mozilla website.
Comment 98 User image Chris Peterson [:cpeterson] 2017-01-10 14:57:52 PST
(In reply to nishantkumar05 from comment #97)
> This is F5 Networks plugin with following MIME:
> "application/x-f5-sam-inspectionhost  f5 sam inspection host plugin"
> This is enterprise only plugin, we requested to whitelist it at one point,
> and its not published on the store. And this plugin is signed on addon
> mozilla website.

I found bug 985640 where this F5 plugin was temporarily added to the click-to-play whitelist.

When you say "this plugin is signed on addon mozilla website", does that mean this F5 plugin is bundled inside a Firefox add-on on https://addons.mozilla.org/ ?
Comment 99 User image Nulled Pointer 2017-01-10 15:07:28 PST
No, what I meant was that we sign the plugin and distribute this signed plugin locally and not via addons.mozilla.org. It was just a FYI in case it helped.
Comment 100 User image Nulled Pointer 2017-01-10 15:21:08 PST
Also, does it mean that whitelisted plugins will still work (via click-to-play) on FF 52 without the plugin.load_flash_only?
Comment 101 User image Chris Peterson [:cpeterson] 2017-01-10 16:02:44 PST
(In reply to nishantkumar05 from comment #100)
> Also, does it mean that whitelisted plugins will still work (via
> click-to-play) on FF 52 without the plugin.load_flash_only?

No. That whitelist was only used to know which plugin to make click-to-play or not. That whitelist is unrelated to the plugin.load_flash_only pref in FF 52.
Comment 102 User image Paul Silaghi, QA [:pauly] 2017-01-12 01:40:06 PST
(In reply to Chris Peterson [:cpeterson] from comment #96)
> Yes. The plugin.load_flash_only pref is available in FF 52.
Setting plugin.load_flash_only=FALSE doesn't enable the other plugins on latest nightly 53, aurora 52.
Thoughts?
Comment 103 User image Chris Peterson [:cpeterson] 2017-01-12 10:51:19 PST
(In reply to Paul Silaghi, QA [:pauly] from comment #102)
> (In reply to Chris Peterson [:cpeterson] from comment #96)
> > Yes. The plugin.load_flash_only pref is available in FF 52.
> Setting plugin.load_flash_only=FALSE doesn't enable the other plugins on
> latest nightly 53, aurora 52.

Are you running 64-bit Firefox? The only NPAPI plugins it supports are 64-bit Flash and Silverlight.

This is strange. I see the opposite behavior: I see other NPAPI plugins in about:addons with Aurora 52, regardless of whether the plugin.load_flash_only pref is false, true, or unset (default true). I know the pref is getting read correctly because the value correctly toggles the "Missing something? Some plugins are no longer supported." message in about:addons. That message is hidden when plugin.load_flash_only is false (because all plugins should be loaded and nothing should be "missing").

Can you please file a bug? I tried bisecting this problem with mozregression, hoping to find a changeset that broke about:addons but I saw inconsistent results.
Comment 104 User image Bill Gianopoulos [:WG9s] 2017-01-12 11:00:07 PST
The issue here, I believe, is that flipping the pref does not make it reload pluginreg.dat, either immediately or upon browser restart.
Comment 105 User image Masatoshi Kimura [:emk] 2017-01-12 12:32:55 PST
Yes, and it is intentional. See comment #47.
Comment 106 User image Masatoshi Kimura [:emk] 2017-01-12 12:33:43 PST
We should consider to disable the pref from regular 52 release to reduce the confusion.
Comment 107 User image Nulled Pointer 2017-01-12 12:40:24 PST
That would mean that regular 52 release users will not be able to load non-flash NPAPI plugins at all, which sounds like its against the original plan.
Comment 108 User image Masatoshi Kimura [:emk] 2017-01-12 12:47:48 PST
What is the "original plan"? The plan is disabling NPAPI plug-ins except Flash since regular 52 while keep enabling them in ESR 52. The pref does not mean to keep support in regular 52.
Comment 109 User image Chris Peterson [:cpeterson] 2017-01-12 12:49:16 PST
(In reply to Masatoshi Kimura [:emk] from comment #106)
> We should consider to disable the pref from regular 52 release to reduce the
> confusion.

We probably shouldn't remove the plugin.load_flash_only pref until 53 or later. We need the pref in 52 code for ESR 52. There's no need to risk breaking ESR 52 just to remove support for this pref in Release 52.

(In reply to Nulled Pointer from comment #107)
> That would mean that regular 52 release users will not be able to load
> non-flash NPAPI plugins at all, which sounds like its against the original
> plan.

If the pref happens to work in Release 52, that's OK but not a supported configuration. We've already started removing code to support some non-Flash plugins in 53, so the pref will eventually stop working. Whether it's better to remove support for the pref in 53 (as emk suggested) or allow some plugins break and others to semi-work, I don't know.
Comment 110 User image Javier 2017-01-12 17:20:53 PST
Ive reviewed ERS overview - https://www.mozilla.org/en-US/firefox/organizations/faq/

Can you please confirm my understanding is valid?

1) 52 ERS NPAPI plugins will supports Flash and Silverlight.

2) 52 ERS NPAPI plugins will supports Flash and Silverlight for up to a year.

3) All user need to do is close current normal FireFox, download ESR from https://www.mozilla.org/en-US/firefox/organizations/all/ and install, I install with no issue but want to make 100% sure as I will be guiding many users to getting it setup.

4) 52 ERS will continue to get security updated but no added feature

Looking forward to your response and many thanks for your support. Jav
Comment 111 User image Javier 2017-01-12 17:51:15 PST Comment hidden (off-topic)
Comment 112 User image Vangelis 2017-01-12 19:40:30 PST
(In reply to Chris Peterson [:cpeterson] from comment #103)
> I know the pref is getting read correctly because the value correctly toggles the
> "Missing something? Some plugins are no longer supported." message in about:addons. 
> That message is hidden when plugin.load_flash_only is false
> (because all plugins should be loaded and nothing should be "missing").

I am afraid you got another bug in your hands :-(
The logic you described above for the about:addons page isn't uniformly applied to 
the about:plugins page, too...

STR: 

1. Run latest DevEd-52.0a2-win32, buildID=20170112004017
2. Visit about:plugins page and notice the "Missing something? Some plugins are no longer supported.   Learn More." notification just under "Installed plugins"
3. about:config => Create a new boolean pref named "plugin.load_flash_only" and set it to "false"
4. Menu bar => Help => Troubleshooting Information => Profile Folder => Open folder 
will open Aurora's profile folder in Windows Explorer.
5. Exit DevEd-52.0a2
6. Delete file "pluginreg.dat" from within Aurora's profile folder.
7. Start DevEd-52.0a2 anew. 
8. While about:addons => plugins, as you say, lacks the "Missing something?..." notification, 
re-visit about:plugins page, which is now populated with all NPAPI plugins on the system, 
to see the top "Missing something?..." notification still being there. 
Why isn't your argument 
> (because all plugins should be loaded and nothing should be "missing")
honoured in this case?
Comment 113 User image Chris Peterson [:cpeterson] 2017-01-13 00:22:59 PST
(In reply to Javier from comment #110)
> Ive reviewed ERS overview -
> https://www.mozilla.org/en-US/firefox/organizations/faq/
> 
> Can you please confirm my understanding is valid?
> 
> 1) 52 ERS NPAPI plugins will supports Flash and Silverlight.

Yes. ESR 52 will support all NPAPI plugins, such as Java.

(btw, the acronym is "ESR", Extended Support Release, not "ERS".)

> 2) 52 ERS NPAPI plugins will supports Flash and Silverlight for up to a year.

Yes. ESR 52 will support all NPAPI plugins until some time in 2018 Q2.

> 3) All user need to do is close current normal FireFox, download ESR from
> https://www.mozilla.org/en-US/firefox/organizations/all/ and install, I
> install with no issue but want to make 100% sure as I will be guiding many
> users to getting it setup.

Yes. When a user installs and runs ESR, it will use the same Firefox user profile directory as regular Firefox, so users will continue to access all their same Firefox bookmarks and browsing history. There should be no problem with users switching back and forth between regular Firefox and ESR (though you can't run them simultaneously).

> 4) 52 ERS will continue to get security updated but no added feature

Yes. ESR 52 will receive security updates every six weeks until 2018 Q2, but it will then be upgraded to a new ESR version (59) that contains all the features added Firefox 53-59 and stop supporting NPAPI plugins other than Flash.
Comment 114 User image Chris Peterson [:cpeterson] 2017-01-13 00:40:41 PST
(In reply to Vangelis from comment #112)
> Why isn't your argument 
> > (because all plugins should be loaded and nothing should be "missing")
> honoured in this case?

I can reproduce this problem, too. I recall now that this is a shortcut we took in about:plugins and don't plan to fix.

I believe accessing the plugins.load_flash_only pref from the about:plugins HTML required extra code that wasn't needed for the about:addons message. Since 1) the plugins.load_flash_only pref is a temporary, undocumented feature and 2) about:plugins is a power user feature not accessible from the GUI (like about:addons from the Tools => Add-ons menu), we decided it wasn't worth the time to hide the "Missing something?" message in about:plugins.
Comment 115 User image Vangelis 2017-01-13 07:29:52 PST
(In reply to Chris Peterson [:cpeterson] from comment #114)
> I recall now that this is a shortcut we
> took in about:plugins and don't plan to fix.

...Hmmm, IMHO, it looks like a half-baked solution; considering this WONTFIX inconsistency will be present for many months in the 52 ESR branch (to which, together with those wishing to prolong NPAPI usage, all XP/Vista users will be switched) will be a constant reminder of a sub-standard executive 
decision - but if your telemetry data attest to the fact only very few "power users" are aware of the 
about:plugins page, who am I to contest it?

> I believe accessing the plugins.load_flash_only pref
> (snip)
> Since 1) the plugins.load_flash_only pref

... to not confuse the many people reading this issue, the correct name of this "undocumented" (why?)
pref is "plugin.load_flash_only" :-)
Comment 116 User image Paul Silaghi, QA [:pauly] 2017-01-13 08:39:18 PST
(In reply to Chris Peterson [:cpeterson] from comment #103)
> This is strange. I see the opposite behavior: I see other NPAPI plugins in
> about:addons with Aurora 52, regardless of whether the
> plugin.load_flash_only pref is false, true, or unset (default true). I know
> the pref is getting read correctly because the value correctly toggles the
> "Missing something? Some plugins are no longer supported." message in
> about:addons. That message is hidden when plugin.load_flash_only is false
> (because all plugins should be loaded and nothing should be "missing").
> 
> Can you please file a bug? I tried bisecting this problem with
> mozregression, hoping to find a changeset that broke about:addons but I saw
> inconsistent results.
bug 1330998
Comment 117 User image Paul Silaghi, QA [:pauly] 2017-01-13 08:49:13 PST
(In reply to Paul Silaghi, QA [:pauly] from comment #102)
> (In reply to Chris Peterson [:cpeterson] from comment #96)
> > Yes. The plugin.load_flash_only pref is available in FF 52.
> Setting plugin.load_flash_only=FALSE doesn't enable the other plugins on
> latest nightly 53, aurora 52.
To be clear, is the pref expected to work only in ESR 52, but not on 52 release?
Comment 118 User image Chris Peterson [:cpeterson] 2017-01-13 10:02:36 PST
(In reply to Paul Silaghi, QA [:pauly] from comment #117)
> To be clear, is the pref expected to work only in ESR 52, but not on 52
> release?

No. The pref is expected to work in both ESR 52 and regular Firefox 52, but I believe you are seeing the pluginref.dat problem mentioned above. After setting the plugin.load_flash_only pref, you need to manually delete the %USERPROFILE%\AppData\Mozilla\Firefox\Profiles\YOUR-PROFILE-NAME-HERE\pluginreg.dat file because it is caching the old plugin list.


(In reply to Vangelis from comment #115)
> ...Hmmm, IMHO, it looks like a half-baked solution; considering this WONTFIX
> inconsistency will be present for many months in the 52 ESR branch (to
> which, together with those wishing to prolong NPAPI usage, all XP/Vista
> users will be switched) will be a constant reminder of a sub-standard
> executive decision

I see what you mean, but I don't think it is a big problem for ESR users who manually load the about:plugins page to see a "Missing something?" message. That's a very small number of users, plus the message just says *if* they are missing plugins (which they won't be), then there is a SUMO article with more information.
Comment 119 User image Paul Silaghi, QA [:pauly] 2017-01-16 02:00:34 PST
Based on bug 1330998#c4 I'm marking this bug as verified fixed on FX 52.0a2 (2017-01-15) Win 7, Ubuntu 14.04, OS X 10.11. Will re-check later on 52 beta to make sure everything is ok before release.
Comment 120 User image Yaroslav 2017-01-17 08:33:11 PST
When and in what releases (both non-ESR and ESR) disabling support of NPAPI Flash plugin is planned?
Comment 121 User image Yaroslav 2017-01-17 08:42:05 PST
And one more question: opening Options -> Advanced -> Update and choosing "Never check for updates (not recommended: security risk) item I faced the problem, that mozilla is uploading and installing updates anyway, how I could prevent this autoupdate and where I can get last ESR Firefox release?
Comment 122 User image Bill Gianopoulos [:WG9s] 2017-01-17 08:44:36 PST
(In reply to Yaroslav from comment #120)
> When and in what releases (both non-ESR and ESR) disabling support of NPAPI
> Flash plugin is planned?

Finally someone else agrees with me.  This all makes no sense as it is the Flash Plug-in that has always been the one that caused browser crashes and security issues, so Banning other plugins but refusing to ban flash seems to be anti any issue this bug was trying to solve.
Comment 123 User image Bill Gianopoulos [:WG9s] 2017-01-17 08:54:13 PST
(In reply to Bill Gianopoulos [:WG9s] from comment #122)
> (In reply to Yaroslav from comment #120)
> > When and in what releases (both non-ESR and ESR) disabling support of NPAPI
> > Flash plugin is planned?
> 
> Finally someone else agrees with me.  This all makes no sense as it is the
> Flash Plug-in that has always been the one that caused browser crashes and
> security issues, so Banning other plugins but refusing to ban flash seems to
> be anti any issue this bug was trying to solve.

Follow the instructions here http://ftp.mozilla.org/pub/firefox/releases/latest-esr/README.txt
Comment 124 User image Bill Gianopoulos [:WG9s] 2017-01-17 08:55:02 PST
(In reply to Yaroslav from comment #121)
> And one more question: opening Options -> Advanced -> Update and choosing
> "Never check for updates (not recommended: security risk) item I faced the
> problem, that mozilla is uploading and installing updates anyway, how I
> could prevent this autoupdate and where I can get last ESR Firefox release?

Follow the instructions here http://ftp.mozilla.org/pub/firefox/releases/latest-esr/README.txt
Comment 125 User image Chris Peterson [:cpeterson] 2017-01-17 10:27:18 PST
(In reply to Yaroslav from comment #120)
> When and in what releases (both non-ESR and ESR) disabling support of NPAPI
> Flash plugin is planned?

There is no ETA yet for disabling support for the Flash plugin.
Comment 126 User image Yaroslav 2017-01-17 10:40:21 PST
Bill and Chris, thank you for prompt reply, I really appreciate your support.
Comment 127 User image Yaroslav 2017-01-17 10:43:31 PST
One more thing remains, opening Options -> Advanced -> Update and choosing "Never check for updates (not recommended: security risk) item - would it disable updates for sure?
Comment 128 User image Vangelis 2017-01-18 01:31:58 PST
(In reply to Yaroslav from comment #127)
> opening Options -> Advanced -> Update and choosing "Never check for updates 
> (not recommended: security risk) item - would it disable updates for sure?

What version of Firefox are you currently on?

The default setting is the first option, i.e, "Automatically install updates (...)"
Firefox periodically checks for updates, when an update is found it automatically 
downloads partial (or complete) .mar files to a directory on your system (on Windows Vista+ it's 
"%LOCALAPPDATA%\Mozilla\Firefox\Mozilla Firefox\updates\0") and through a process called "update staging" (app.update.staging.enabled;true) it creates an "updated" folder within Firefox's installation directory. When Firefox is exited, old files within its installation dir are moved to a "tobedeleted" 
folder, the contents of the "updated" folder are put in their place. When Firefox is started anew, 
folders "update" (now empty) and "tobedeleted" are removed, leaving the updated installation. Opening the "About Firefox" window will start the same procedure at a time chosen by the user...

Selecting manually the third update option (Never check for updates (...)), as its name suggests, 
will stop Firefox checking for updates. Opening the "About Firefox" window now will prompt you to 
"Check for Updates" - if you do click the prompt, the check will be performed and another update 
prompt will show up (e.g. Update to 52.0a2), but no update will be downloaded (and installed) unless 
you click that second "Update" prompt. 

To recap, if you do not want Firefox to be updated, 
1. Select the third update option in 
Options => Advanced => Update => Firefox Updates
2. Exit Firefox
3. Make sure that no already downloaded .mar files exist on your system; if they are, manually delete them
4. Make sure that no "update" folder exists within your Fx installation directory; it it does, manually 
delete it. Also make sure that the files extant inside the main install dir are of your older firefox version - if not and a "tobedeleted" folder already exists with content, a background update has already 
taken place; either move its contents back in or re-install your older version...
5. Restart Firefox and remember not to manually initiate an update. 
6. Just a notice of caution: If, for whatever troubleshooting scenario, you have to create a fresh Firefox profile, then once you load that profile, Firefox will, by default, begin to check and download 
background updates, so you may again, inadvertently, end up with an updated Firefox when you restart it...
Hope I've helped...
Comment 129 User image Chris Mills (Mozilla, MDN editor) [:cmills] 2017-01-18 06:56:15 PST
I've added a note concerning this change on the main MDN plugins page, as well as a note to the Fx52 release notes:

https://developer.mozilla.org/en-US/Firefox/Releases/52#Plugins
https://developer.mozilla.org/en-US/Add-ons/Plugins

Let me know if that's OK. Thanks!

Note You need to log in before you can comment on or make changes to this bug.