Closed Bug 1269807 (npapi-eol) Opened 8 years ago Closed 8 years ago

Remove support for all NPAPI plugins (except Flash)

Categories

(Core Graveyard :: Plug-ins, defect, P2)

Unspecified
All
defect

Tracking

(relnote-firefox 52+, firefox52 verified)

VERIFIED FIXED
mozilla52
Tracking Status
relnote-firefox --- 52+
firefox52 --- verified

People

(Reporter: cpeterson, Assigned: benjamin)

References

Details

(Keywords: addon-compat, dev-doc-complete, site-compat)

Attachments

(1 file)

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.
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?
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.
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.
Google Hangouts works without plugins only with Chrome, and Skype works without plugins only with Edge. What's a wonderful plugin-free world! :(
(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?
(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
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.
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 ?
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.
Thank you for confirming the timeline.
Blocks: 1279218
Priority: -- → P2
Target Milestone: --- → mozilla52
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?
(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.
No longer blocks: win64-migration
Alias: remove-npapi → npapi-eol
Blocks: 1183613
Whiteboard: [parity-chrome][parity-edge]
Blocks: 1295375
Blocks: 1171396
Blocks: 1296400
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.
Flags: needinfo?(cpeterson)
(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/
Flags: needinfo?(cpeterson)
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?
(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.
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?
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.
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.
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.
Blocks: 1270366, 1270364
(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?
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/
https://treeherder.mozilla.org/#/jobs?repo=try&revision=a1bdb92c7e36 will hopefully have results once infra issues are solved and I can retrigger.
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
Attachment #8795409 - Flags: review?(jmathies) → review+
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?
Flags: needinfo?(cpeterson)
All plugins will still be available on ESR 52, so we're explicitly fine there.
Flags: needinfo?(cpeterson)
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.
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
What about MS Silverlight ?
My television provider uses it as an online streaming source to watch TV.
(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.
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)
https://hg.mozilla.org/mozilla-central/rev/fea530023849
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
(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?
Flags: needinfo?(danialhorton)
Depends on: 1307445
Depends on: 1307501
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?
(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
Flags: needinfo?(benjamin)
(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.
(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.
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…).
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?
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.
Flags: needinfo?(benjamin)
(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)
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...
Blocks: 1308761
This "pref" is only intended for ESR deployment, not setting by individual users, so we don't regenerate the plugin cache when it changes.
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.
(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.
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!
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.
Depends on: 1310173
Whiteboard: [parity-chrome][parity-edge]
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?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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?
Oh and we already decided we needed to include siverlight/moonlight in the permitted plug-ins.  please pay attention.
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.
Status: REOPENED → RESOLVED
Closed: 8 years ago8 years ago
Resolution: --- → FIXED
(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.
Depends on: 1311420
Depends on: 1311371
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)]:
relnote-firefox: --- → ?
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".
(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.
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?
(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.
(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.
(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?).
Blocks: 1092126
Depends on: 1306314
Blocks: 1317108
Blocks: 1317109
Blocks: 1317110
Blocks: 1317111
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.
(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/
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.
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
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.
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.
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.
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!
> between 53 and 53ESR to work differently.

Oops I meant between 52 and 53ESR.
Blocks: 1318819
Blocks: 1318833
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.
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.
(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/
Blocks: 1320019
Blocks: 1320020
(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.
(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/
Are you still on track to deprecate NPAPI for March 2017 (52)?
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
(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.
(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.
Blocks: 1322402
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.
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.
(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 :)
(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.
(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
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?
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).
(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?
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.
(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/ ?
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.
Also, does it mean that whitelisted plugins will still work (via click-to-play) on FF 52 without the plugin.load_flash_only?
(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.
Depends on: 1330529
(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?
Flags: needinfo?(cpeterson)
Blocks: 1330529
No longer depends on: 1330529
(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.
Flags: needinfo?(cpeterson)
The issue here, I believe, is that flipping the pref does not make it reload pluginreg.dat, either immediately or upon browser restart.
Yes, and it is intentional. See comment #47.
We should consider to disable the pref from regular 52 release to reduce the confusion.
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.
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.
(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.
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
(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?
(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.
(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.
(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" :-)
Depends on: 1330998
(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
(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?
Flags: needinfo?(cpeterson)
(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.
Flags: needinfo?(cpeterson)
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.
Status: RESOLVED → VERIFIED
When and in what releases (both non-ESR and ESR) disabling support of NPAPI Flash plugin is planned?
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?
(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.
(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
(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
(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.
Bill and Chris, thank you for prompt reply, I really appreciate your support.
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?
(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...
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!
Depends on: 1332755
Good Morning,

I just wanted to confirm some things around Silverlight support, for my own sanity, as there is a lot to take in within this thread.

1. Article https://blog.mozilla.org/futurereleases/2016/07/20/reducing-adobe-flash-usage-in-firefox/ states that Silverlight will still be supported through ESR 52. Is that still the same? It's just that the article is a little old and wondered if that has changed.

2. Release 52 is scheduled for the 7th of March still. Does the ESR version come out on the same day or is there a delay?

3. I understand the ESR still receives security updates. However, hypothetically, if Silverlight was having many issues playing out through Firefox on my businesses website, would Mozilla investigate these and submit bug reports still? Or if things aren't working there is no support for it anymore?

4. When you download the ESR, does it create a second Firefox application? For example, can a user have two Firefox applications installed and visible? (One standard Firefox 52 and the other ESR 52) If so, how do you differentiate between the two?

Apologies for all the questions. Any help is appreciated.
Flags: needinfo?(cpeterson)
(In reply to Broady Thyme from comment #130)
> 1. Article
> https://blog.mozilla.org/futurereleases/2016/07/20/reducing-adobe-flash-
> usage-in-firefox/ states that Silverlight will still be supported through
> ESR 52. Is that still the same? It's just that the article is a little old
> and wondered if that has changed.

No change. Silverlight (and all other NPAPI plugins, such as Java or Google Hangouts) will continue to be supported in ESR 52.

> 2. Release 52 is scheduled for the 7th of March still. Does the ESR version
> come out on the same day or is there a delay?

The ESR 52 downloads should be available on March 7 or 8 on the download page:

https://www.mozilla.org/en-US/firefox/organizations/all/

> 3. I understand the ESR still receives security updates. However,
> hypothetically, if Silverlight was having many issues playing out through
> Firefox on my businesses website, would Mozilla investigate these and submit
> bug reports still? Or if things aren't working there is no support for it
> anymore?

If there are critical Silverlight bugs, we would investigate them, but I can't say for certain whether they would be fixed.

Note that Microsoft officially stopped supporting Silverlight in Firefox on December 2016. They will continue to support Silverlight in IE11 until 2021. See the Silverlight System Requirements on this page:

https://www.microsoft.com/getsilverlight/Get-Started/Install/Default.aspx

> 4. When you download the ESR, does it create a second Firefox application?
> For example, can a user have two Firefox applications installed and visible?
> (One standard Firefox 52 and the other ESR 52) If so, how do you
> differentiate between the two?

By default, the ESR installer will install into any existing Firefox Program Files directory. You can choose a different directory name in the installer's Custom option. The ESR and regular Firefox icons will look the same. You can test this yourself before ESR 52 is released by using the ESR 45 installer:

https://www.mozilla.org/en-US/firefox/organizations/all/
Flags: needinfo?(cpeterson)
This thread is very helpful, thanks much Chris, Benjamin and all the others for providing info.  I'm about the update the Java Platform Group blog "Moving to a Plugin Free Web", and want to be sure I'm conveying a few key facts accurately.  Apologies if any of these are redundant:

 * FF52 will only have NPAPI support on the ESR release, not the general release;
 * FF52 ESR is the final release that will support NPAPI;
 * ESR releases are intended for organizational use, but in a pinch anyone can get it here: https://www.mozilla.org/en-US/firefox/organizations/all/
 * FF52 ESR updates will likely continue until early 2018;
 * It's not possible to distinguish ESR versus non-ESR on the server side;
 * On the desktop, "Help Menu -> About Firefox" window will show clearly ESR if it's the ESR version;

Can someone scream if any of the above is incorrect?  What we'll probably do on java.com is detect FF52 or later and indicate it's no longer supported, and provide a link where to get FF52 ESR with a disclaimer it's intended more for organizations than consumers.
(In reply to Donald Smith from comment #132)
>  * FF52 will only have NPAPI support on the ESR release, not the general
> release;
>  * FF52 ESR is the final release that will support NPAPI;
>  * ESR releases are intended for organizational use, but in a pinch anyone
> can get it here: https://www.mozilla.org/en-US/firefox/organizations/all/
>  * FF52 ESR updates will likely continue until early 2018;
>  * It's not possible to distinguish ESR versus non-ESR on the server side;
>  * On the desktop, "Help Menu -> About Firefox" window will show clearly ESR
> if it's the ESR version;

You are correct on all points. :)
Hi

Please don't kill NPAPI just yet. Until GPU acceleration is integrated with HTML video, it still has some very interesting uses:

https://bugzilla.mozilla.org/show_bug.cgi?id=563206#c64
Is there a way on the new Firefox 52 (not the ESR version) for manually re-enabling the Java plugin or the plugin support will be completely removed?

Thanks
(In reply to mix from comment #135)
> Is there a way on the new Firefox 52 (not the ESR version) for manually
> re-enabling the Java plugin or the plugin support will be completely removed?

You can create a new "plugin.load_flash_only" = false pref in about:config to re-enable support for other NPAPI plugins. This will work in regular Firefox 52, might work for some plugins in 53, and will likely stop working in 54.
I'm running Nightly (FF 54) and Flash has been disabled, removed.  I thought that there was suppose to be an exception for Flash.  Why is it removed in Nightly?
gbcox please file a separate bug, that is not expected.
Flags: needinfo?(danialhorton)
(In reply to gbcox from comment #137)
> I'm running Nightly (FF 54) and Flash has been disabled, removed.  I thought
> that there was suppose to be an exception for Flash.  Why is it removed in
> Nightly?

I suspect you have an older version of flash installed which we purposely disable because it has known vulnerabilities being exploited by active malware in the wild.
(In reply to Paul Silaghi, QA [:pauly] from comment #119)
> 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.
Everything's fine on 52b8 Win 10, Ubuntu 14.04, OS X 10.12.
Hello there,

I have a question in regards to this page https://wiki.mozilla.org/RapidRelease/Calendar. Potentially this is not an official Mozilla website and therefore inaccurate, so please just let me know if that's the case.

However, on this page it states that on the 7th of March there will be two ESR updates (going up to 45.8 and the release of 52.0). Does this mean there is a choice as to which ESR version you can install? If so, how would a user choose to download and install the ESR 52.0 instead of the 45.8? Furthermore, for those users already using ESR 45.7 will they auto update to 45.8 or 52.0? How does that work?

Thanks in advance for any assistance.
(In reply to Broady Thyme from comment #142)
> Hello there,
> 
> I have a question in regards to this page
> https://wiki.mozilla.org/RapidRelease/Calendar. Potentially this is not an
> official Mozilla website and therefore inaccurate, so please just let me
> know if that's the case.
This is maintained by Mozilla 

> However, on this page it states that on the 7th of March there will be two
> ESR updates (going up to 45.8 and the release of 52.0). Does this mean there
> is a choice as to which ESR version you can install? If so, how would a user
> choose to download and install the ESR 52.0 instead of the 45.8?
The download page will propose the two ESR releases.

> Furthermore, for those users already using ESR 45.7 will they auto update to
> 45.8 or 52.0? How does that work?
We will update users to 52.2 once 45.9 is unmaintained (June 2017)
(In reply to Chris Peterson [:cpeterson] from comment #49)
> 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.
Note that Google Hangouts isn't working on Fx 52.0-build1 RC. Are we ok for now?
Flags: needinfo?(cpeterson)
(In reply to Chris Peterson [:cpeterson] from comment #136)
> (In reply to mix from comment #135)
> > Is there a way on the new Firefox 52 (not the ESR version) for manually
> > re-enabling the Java plugin or the plugin support will be completely removed?
> 
> You can create a new "plugin.load_flash_only" = false pref in about:config
> to re-enable support for other NPAPI plugins. This will work in regular
> Firefox 52, might work for some plugins in 53, and will likely stop working
> in 54.

Thanks, Chris. Do we need to add this new config with every update of Firefox?
(In reply to sudhi.a.rao from comment #145)
> (In reply to Chris Peterson [:cpeterson] from comment #136)
> > (In reply to mix from comment #135)
> > > Is there a way on the new Firefox 52 (not the ESR version) for manually
> > > re-enabling the Java plugin or the plugin support will be completely removed?
> > 
> > You can create a new "plugin.load_flash_only" = false pref in about:config
> > to re-enable support for other NPAPI plugins. This will work in regular
> > Firefox 52, might work for some plugins in 53, and will likely stop working
> > in 54.
> 
> Thanks, Chris. Do we need to add this new config with every update of
> Firefox?

No, this configuration option will persist across all version 52 updates.  However, it will cease to have any impact under Firefox 53 and later.
(In reply to Bill Gianopoulos [:WG9s] from comment #146)
> (In reply to sudhi.a.rao from comment #145)
> > (In reply to Chris Peterson [:cpeterson] from comment #136)
> > > (In reply to mix from comment #135)
> > > > Is there a way on the new Firefox 52 (not the ESR version) for manually
> > > > re-enabling the Java plugin or the plugin support will be completely removed?
> > > 
> > > You can create a new "plugin.load_flash_only" = false pref in about:config
> > > to re-enable support for other NPAPI plugins. This will work in regular
> > > Firefox 52, might work for some plugins in 53, and will likely stop working
> > > in 54.
> > 
> > Thanks, Chris. Do we need to add this new config with every update of
> > Firefox?
> 
> No, this configuration option will persist across all version 52 updates. 
> However, it will cease to have any impact under Firefox 53 and later.

Thanks, Bill. I tried this setting change with 52 beta but I am still not able to use my Silverlight application. From Chris's comment 136, it looked like all NPAPI plugins would work with this config change.
You might need to remove the pluginreg.dat file in your Firefox profile directory.  Exit Firefox delete that file then restart and see if that works better.
(In reply to Bill Gianopoulos [:WG9s] from comment #148)
> You might need to remove the pluginreg.dat file in your Firefox profile
> directory.  Exit Firefox delete that file then restart and see if that works
> better.

Did not work even after deleting the pluginreg.dat file
(In reply to Paul Silaghi, QA [:pauly] from comment #144)
> Note that Google Hangouts isn't working on Fx 52.0-build1 RC. Are we ok for
> now?

Yes. Hangouts not working is expected and OK. Here is Google's announcement about Hangouts not working in Firefox 52 until they launch the WebRTC version:

https://gsuiteupdates.googleblog.com/2017/02/google-hangouts-temporary-issues-with-firefox.html
Flags: needinfo?(cpeterson)
And why is that OK? Google recommends switching browser, sorry I don't see the logic here..
I just meant that Hangouts breaking is not a surprise and Google is actively working on the WebRTC replacement.
I have a web application which is built using Silverlight and I have huge customer base who use firefox as the browser..
I need to inform the user who are using  the version 52 of the firefox that there is an ESR version which will allow them to continue using my application. This can be done if I am able to detect the version of the Firefox they are in and also I don’t want to show them the message if they are on ESR version (52), since it will allow them to continue using my application. Is there a way, I can get tis information through the incoming request (in header or somewhere?)
I want to have this in place, meanwhile I am evaluating on other solutions.

Thanks,
Alpee
(In reply to alpee from comment #153)
> I have a web application which is built using Silverlight and I have huge
> customer base who use firefox as the browser..
> I need to inform the user who are using  the version 52 of the firefox that
> there is an ESR version which will allow them to continue using my
> application. This can be done if I am able to detect the version of the
> Firefox they are in and also I don’t want to show them the message if they
> are on ESR version (52), since it will allow them to continue using my
> application. Is there a way, I can get tis information through the incoming
> request (in header or somewhere?)

hi Alpee, unfortunately there is no official way to programmatically distinguish the regular and ESR versions of Firefox. However, if you detect a user is running Firefox 52 and navigator.plugins["Silverlight Plug-In"] returns undefined, then there is a very good chance that user is running the regular, non-ESR version of Firefox 52. If the user is still running Firefox 45, then they are probably on the previous ESR version and will be automatically updated to 52 ESR. They probably don't need a message. Users running Windows XP or Vista will be automatically switched to ESR and will continue to have access Silverlight, so they won't need a message.

I recommend you show a "Please switch to Firefox ESR" message to users running Firefox > 45 (the previous ESR) and Windows >= 7 or Mac OS X, even if they have Silverlight installed. These users will receive an automatic update for 52 very soon and they should think about switching to ESR now.

Additionally, you could suggest users open your web application in IE, which will continue to support NPAPI and Silverlight for many years. IE is probably the simplest option because every Windows user has it and won't need to download a new browser.
Cannot he just use <noscript/>?
Does the 64bit version of Firefox on 52.0 continue to support Silverlight?

This article seems to suggest it does: http://www.theinquirer.net/inquirer/news/2429763/mozilla-pledges-cull-of-npapi-and-silverlight-from-firefox-in-2016

However, this is an old article, so maybe things have changed?
(In reply to Broady Thyme from comment #156)
> Does the 64bit version of Firefox on 52.0 continue to support Silverlight?
> 
The flash only restrictions is a preference setting in version 52 so by default it does not support silverlight, but you can override that.
While you can temporarily re-enable Silverlight on Firefox 52, but it is not supported and Silverlight will probably not work correctly in Firefox 53 or later.
If you need Silverlight, you should switch to the Firefox ESR channel [1] or just open IE when you need to run a Silverlight application.

[1] https://www.mozilla.org/en-US/firefox/organizations/
(In reply to Chris Peterson [:cpeterson] from comment #159)
> If you need Silverlight, you should switch to the Firefox ESR channel [1] or
> just open IE when you need to run a Silverlight application.
> 
> [1] https://www.mozilla.org/en-US/firefox/organizations/

This explicitly warns users to stop using Firefox and instead use some other browser.
(In reply to David E. Ross from comment #160)
> (In reply to Chris Peterson [:cpeterson] from comment #159)
> > If you need Silverlight, you should switch to the Firefox ESR channel [1] or
> > just open IE when you need to run a Silverlight application.
> > 
> > [1] https://www.mozilla.org/en-US/firefox/organizations/
> 
> This explicitly warns users to stop using Firefox and instead use some other
> browser.

Firefox isn't unique here, though. Edge even automatically opens IE on sites requiring Silverlight or ask the user to do so. IE is now the only browser that supports Silverlight on Windows but it's essentially a dead browser so the risk that it gains market share is not high (it keeps losing it).
No longer depends on: 1313121
For some reason, got Java enabled in Linux only after:
ln -s /usr/lib64/IcedTeaPlugin.so ~/.mozilla/plugins/
`"plugin.load_flash_only" = false` was not enough (FF 52)
Worked before without that symlink. Distro maintaining issue maybe, writing here just in case.
(In reply to travneff from comment #163)
> For some reason, got Java enabled in Linux only after:
> ln -s /usr/lib64/IcedTeaPlugin.so ~/.mozilla/plugins/
> `"plugin.load_flash_only" = false` was not enough (FF 52)
> Worked before without that symlink. Distro maintaining issue maybe, writing
> here just in case.

This is how it has always worked if you are on a system that puts the symlinks in /usr/lib64/mozilla/plugins, that is NOT where the official Mozilla builds look for plugins for the 64-bit version they look in /usr/lib/mozilla/plugins.
(In reply to Chris Peterson [:cpeterson] from comment #49)
> (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.

It has been a few months and a few releases now since FF has dropped Hangouts support and Google doesn't seem to be any rush to address that. And that is relatively obvious why: less people using FF, more people using Chrome.

Any plans to reintroduce support of Hangouts to FF?

Thanks!
I have found another browser called Pale Moon and I recently downloaded it to use for the one site I visit which uses a plug-in.  Pale Moon says they still support NPAPI plug-ins and will continue to support them.  There is a site I visit for Christian music that is public domain, and they have the sheet music available for free.  The site uses the Schorch plug-in, which will play the song and will even transpose the sheet music to another key and allow you to print it in the key you need.  The plug-in had been opening in Internet Explorer until recently; I guess the latest updates to IE also no longer support a lot of the plug-ins.  (I am running Windows 7 and have IE, not Edge.)  It worked great with Pale Moon; hopefully we will be able to continue to use that browser for any sites with plug-ins.
PaleMoon branched off Firefox 24 and re-synchronized with some 38 features, I don't know about their efforts to sync up with 52 level. Thus, no surprise that plugins still work there.

No need to go to third-party builds, Firefox 52 ESR still supports NPAPI plugins and can be obtained from https://www.mozilla.org/en-US/firefox/organizations/ even if you are not an organization. This will change though once this ESR branch ends (around when Firefox 61.0 retail is introduced).

After SeaMonkey 2.48, it will switch to the 52 ESR branch with 2.49, thus NPAPI support will be maintained here as well for the time being.
(In reply to rsx11m from comment #167)
> After SeaMonkey 2.48, it will switch to the 52 ESR branch with 2.49, thus
> NPAPI support will be maintained here as well for the time being.

Where do you get this info from? current 2.53 SeaMonkey nightly builds are built off the mozilla-central trunk.
Has been on the table for quite a while now, for this and other reasons (like WinXP/Vista support) - https://wiki.mozilla.org/SeaMonkey/StatusMeetings/2017-06-25#Release_Train

Trunk and beta will keep working as usual. Basically, SeaMonkey as switching to the same release model as Thunderbird currently maintains.
(In reply to rsx11m from comment #169)
> Has been on the table for quite a while now, for this and other reasons
> (like WinXP/Vista support) -
> https://wiki.mozilla.org/SeaMonkey/StatusMeetings/2017-06-25#Release_Train
> 
> Trunk and beta will keep working as usual. Basically, SeaMonkey as switching
> to the same release model as Thunderbird currently maintains.

So you are saying that my work on SeaMonkey Nightly is useless because I am working on something that has zero path to release????
(In reply to Bill Gianopoulos [:WG9s] from comment #170)
> (In reply to rsx11m from comment #169)
> > Has been on the table for quite a while now, for this and other reasons
> > (like WinXP/Vista support) -
> > https://wiki.mozilla.org/SeaMonkey/StatusMeetings/2017-06-25#Release_Train
> > 
> > Trunk and beta will keep working as usual. Basically, SeaMonkey as switching
> > to the same release model as Thunderbird currently maintains.
> 
> So you are saying that my work on SeaMonkey Nightly is useless because I am
> working on something that has zero path to release????

SeaMonkey Nightly 56 will be the next SeaMonkey release, if I understand correctly.
(In reply to Bill Gianopoulos [:WG9s] from comment #170)
> So you are saying that my work on SeaMonkey Nightly is useless because I am
> working on something that has zero path to release????

No. This is off-topic in this specific bug report, but patches can always go on an ESR branch too as needed and considered useful. It's a different story with API/string changes, those may have to wait for 2.56 based on the 59 branch, unless there is an agreement with localizers to take it earlier.

(In reply to Masatoshi Kimura [:emk] from comment #171)
> SeaMonkey Nightly 56 will be the next SeaMonkey release, if I understand correctly.

Yes, after the 52 ESR cycle ends.
(In reply to rsx11m from comment #172)
> (In reply to Bill Gianopoulos [:WG9s] from comment #170)
> > So you are saying that my work on SeaMonkey Nightly is useless because I am
> > working on something that has zero path to release????
> 
> No. This is off-topic in this specific bug report, but patches can always go
> on an ESR branch too as needed and considered useful. It's a different story
> with API/string changes, those may have to wait for 2.56 based on the 59
> branch, unless there is an agreement with localizers to take it earlier.
> 
> (In reply to Masatoshi Kimura [:emk] from comment #171)
> > SeaMonkey Nightly 56 will be the next SeaMonkey release, if I understand correctly.
> 
> Yes, after the 52 ESR cycle ends.

I suspect this is actually until such time as we figure out how to get Chatzilla Dom Inspecor and email integrated into the mozilla.central trunk.
I realize this is completely off topic, but if my efforts are useless ,as you imply, i will no longer contribute towards what I thought was the wanted end result.
I neither implied nor said that, SeaMonkey development is certainly continuing. Before the rapid release train was introduced, there were major and minor releases as well, so it's kind-of back to that model (which Thunderbird has been running on for quite a while now).
OK you implied this had something to do with NPAPI support which is really tangential to the issue the real issue which I am working on is how to get the embedded Chatzilla Email and DOM inspector to work after XUL extensions are no longer supported.
Yeah, different topic - we'll have to see how to accommodate what we need with continuing Gecko changes.
I don't think this is the place to discuss about seamonkey.
Could you please move the discussion on a mailing list? Thanks
Sure, I figured it was off-topic, but it seems that we have wrapped up that discussion now anyway.
Sorry for the noise.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.