Java plugin phase out timeline

17869 views
Skip to first unread message

Java Dev

unread,
Feb 23, 2016, 1:03:41 PM2/23/16
to
Hello,

Hope all is well. The company I work for uses Java applets for our web products and we are currently planning our release schedules to replace Java applet tech, as it will affect many users in our product community and several products. As such, our dev team would like to better understand the "drop dead date" of when the Java plugin will stop working in Firefox.

We are aware that the announcement was for end of 2016, but wanted to confirm if there is a more specific date other than 12/31/2016. Also, we would like to know if Firefox will follow a similar path as Chrome to provide a way to still manually enable the Java plugin for some time (disabled by default), perhaps even past end of 2016.

We want our users to use Firefox instead of other browsers, especially since we have had to run through some hoops to get our corporate clients to switch from IE to Firefox for our web applications. For some reason, some corporations are resistant to running browsers other than IE and it took some convincing on our part.

Your response is greatly appreciated. We would prefer our user community still use Firefox and not switch to IE, while we are working through converting our web products to web based technology and away from the Java plugin. We are concerned that if they switch to IE again, while we work to replace Java applets, their IT departments might not approve going back again to Firefox.

Best Regards,
Alexandra

P.S. If you are interested, more information about our company and products is available at www.7thonline.com.

Chris Peterson

unread,
Feb 23, 2016, 1:35:46 PM2/23/16
to
On 2/23/16 10:03 AM, Java Dev wrote:
> Hope all is well. The company I work for uses Java applets for our web products and we are currently planning our release schedules to replace Java applet tech, as it will affect many users in our product community and several products. As such, our dev team would like to better understand the "drop dead date" of when the Java plugin will stop working in Firefox.
>
> We are aware that the announcement was for end of 2016, but wanted to confirm if there is a more specific date other than 12/31/2016. Also, we would like to know if Firefox will follow a similar path as Chrome to provide a way to still manually enable the Java plugin for some time (disabled by default), perhaps even past end of 2016.


hi Alexandra, our tentative schedule is to remove NPAPI support in
Firefox 53 (which will be in the Firefox Nightly channel in November
2016 and released in April 2017). These versions or dates are not
official or set in stone. They could conceivably be postponed if we need
to continue supporting NPAPI for some reason.

The next Firefox ESR (Extended Support Release) version is 52 and will
receive security updates for a year. By removing NPAPI in Firefox 53,
the release *after* the ESR, users that need NPAPI support can continue
to switch to Firefox ESR 52 and keep using NPAPI plugins until May 2018.


chris

bna...@gmail.com

unread,
Feb 24, 2016, 8:30:21 AM2/24/16
to
Hello, I have some use cases, which currently are "solved" with Java Applets:

1 - Control a Twain scanner. (kodak scanner i2800)
2 - Control a fingerprint reader (Nitgen Fingkey Hamster I DX).
3 - Control a barcode reader.

All of these involve access dll's (or .so ) via JNI.


What technology Firefox provides so I can migrate and continue to access/control hardware as i can now via dll's + JNI + Java Applets?




--
Fábio C. Barrionuevo da Luz
Palmas - Tocantins - Brasil - América do Sul

Mikael Haltali

unread,
Feb 24, 2016, 12:25:58 PM2/24/16
to bna...@gmail.com, dev-tech...@lists.mozilla.org
Hi,
the best solution currently is js-ctypes which enables you to build an
extension that calls a custom dll written in C
That's what my team is currently doing to migrate a NPAPI plugin.
Documentation is good but the only drawback currently is the lack of end to
end examples.
Here is a link to official documentation
https://developer.mozilla.org/en-US/docs/Mozilla/js-ctypes

Hope this helps
> _______________________________________________
> dev-tech-plugins mailing list
> dev-tech...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-plugins
>

Chris Peterson

unread,
Feb 24, 2016, 1:43:08 PM2/24/16
to
hi Fábio, an alternative to js-ctypes is to create a Firefox extension
that communicates with a child process written in native code that calls
your DLL. The Addon SDK's system/child_process API allows pipe-based
communication with an external binary:

https://developer.mozilla.org/en-US/Add-ons/SDK/Low-Level_APIs/system_child_process



chris

Benjamin Smedberg

unread,
Feb 25, 2016, 10:09:36 AM2/25/16
to Mikael Haltali, bna...@gmail.com, dev-tech...@lists.mozilla.org


On 2/24/2016 12:25 PM, Mikael Haltali wrote:
> Hi,
> the best solution currently is js-ctypes which enables you to build an
> extension that calls a custom dll written in C
To repeat what Chris Peterson wrote, we strongly discourage use of
JS-ctypes is new code: it is very difficult to write code which is
memory-safe. We strongly encourage everyone to use a separate process
and communicate with pipes using system/child_process or the future
WebExtensions.

--BDS

Mikael Haltali

unread,
Feb 25, 2016, 10:23:55 AM2/25/16
to Benjamin Smedberg, dev-tech...@lists.mozilla.org, Fabio Caritas Barrionuevo da Luz
Ok my bad for pointing people in the wrong direction
How come js-ctypes is not recommended but child_process is although it's
marked as "Experimental" in the documentation. What does that even mean? A
next update could break the API or could it be removed in a new build?

Anyways thanks for the information

On Thu, Feb 25, 2016 at 4:09 PM, Benjamin Smedberg <benj...@smedbergs.us>
wrote:

Benjamin Smedberg

unread,
Feb 25, 2016, 11:30:02 AM2/25/16
to Mikael Haltali, dev-tech...@lists.mozilla.org, Fabio Caritas Barrionuevo da Luz


On 2/25/2016 10:23 AM, Mikael Haltali wrote:
>
> How come js-ctypes is not recommended but child_process is although
> it's marked as "Experimental" in the documentation.

I can't explain the "experimental" except that development of the addon
SDK never finished it. But it's been around and pretty stable for a
while, and it is technically the least dangerous choice and has some
nice properties of API and crash isolation.

--BDS

Mikael Haltali

unread,
Feb 25, 2016, 11:32:13 AM2/25/16
to Benjamin Smedberg, dev-tech...@lists.mozilla.org, Fabio Caritas Barrionuevo da Luz
Ok thanks for the info
Our development is still at a proof of concept stage thankfully so I guess
i'm going to be doing another proof of concept using child_process :)

On Thu, Feb 25, 2016 at 5:29 PM, Benjamin Smedberg <benj...@smedbergs.us>
wrote:

>
>

Java Dev

unread,
Apr 6, 2016, 12:49:05 PM4/6/16
to
On Tuesday, February 23, 2016 at 1:35:46 PM UTC-5, Chris Peterson wrote:
>
> The next Firefox ESR (Extended Support Release) version is 52 and will
> receive security updates for a year. By removing NPAPI in Firefox 53,
> the release *after* the ESR, users that need NPAPI support can continue
> to switch to Firefox ESR 52 and keep using NPAPI plugins until May 2018.
>
>

Chris,

Thank you so much for your speedy reply! Greatly appreciate it! Sorry it took me a while to get back in here. Honestly, I was a little afraid to check back and find out the answer.

It is such excellent news that our user community could continue to use Firefox by going to the Firefox ESR version 52 and can use it for about a year more. Is there a specific announcement page where I can check the status/progress for this version and how to use it/switch to it or should I check-in back here later in the year? We want to make our corporate clients aware of their options, the timeline and make sure they stay on Firefox!

Thanks again!

Best Regards,
Alexandra

Chris Peterson

unread,
Apr 6, 2016, 4:14:28 PM4/6/16
to
On 4/6/16 9:49 AM, Java Dev wrote:
> It is such excellent news that our user community could continue to use Firefox by going to the Firefox ESR version 52 and can use it for about a year more. Is there a specific announcement page where I can check the status/progress for this version and how to use it/switch to it or should I check-in back here later in the year? We want to make our corporate clients aware of their options, the timeline and make sure they stay on Firefox!

More information about Firefox ESR installation and its release schedule
is available below, but feel free to check this list or email directly.

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

chris

Java Dev

unread,
Apr 27, 2016, 4:52:25 PM4/27/16
to
On Wednesday, April 6, 2016 at 4:14:28 PM UTC-4, Chris Peterson wrote:
> More information about Firefox ESR installation and its release schedule
> is available below, but feel free to check this list or email directly.
>
> https://www.mozilla.org/en-US/firefox/organizations/faq/

Thank you, it is very informative!


On Tuesday, February 23, 2016 at 1:35:46 PM UTC-5, Chris Peterson wrote:
>
> hi Alexandra, our tentative schedule is to remove NPAPI support in
> Firefox 53 (which will be in the Firefox Nightly channel in November
> 2016 and released in April 2017). These versions or dates are not
> official or set in stone. They could conceivably be postponed if we need
> to continue supporting NPAPI for some reason.
>

As it has been a few months, I just wanted to double check if the release schedule mentioned above for removal of NPAPI plugins such as the Java Runtime Environment is still the same - namely, the NPAPI support is removed with Firefox 53 which would be released to the public in April 2017.

Thank you in advance!

Best Regards,
Alexandra

Chris Peterson

unread,
Apr 27, 2016, 5:35:49 PM4/27/16
to
On 4/27/16 1:52 PM, Java Dev wrote:
> On Tuesday, February 23, 2016 at 1:35:46 PM UTC-5, Chris Peterson wrote:
>> >
>> > hi Alexandra, our tentative schedule is to remove NPAPI support in
>> > Firefox 53 (which will be in the Firefox Nightly channel in November
>> > 2016 and released in April 2017). These versions or dates are not
>> > official or set in stone. They could conceivably be postponed if we need
>> > to continue supporting NPAPI for some reason.
>> >
> As it has been a few months, I just wanted to double check if the release schedule mentioned above for removal of NPAPI plugins such as the Java Runtime Environment is still the same - namely, the NPAPI support is removed with Firefox 53 which would be released to the public in April 2017.

Yes. That's still the plan.

Java Dev

unread,
Apr 27, 2016, 7:04:10 PM4/27/16
to
On Wednesday, April 27, 2016 at 5:35:49 PM UTC-4, Chris Peterson wrote:
> > As it has been a few months, I just wanted to double check if the release schedule mentioned above for removal of NPAPI plugins such as the Java Runtime Environment is still the same - namely, the NPAPI support is removed with Firefox 53 which would be released to the public in April 2017.
>
> Yes. That's still the plan.

Sounds good, thank you for the quick reply!

Java Dev

unread,
Jun 24, 2016, 7:27:02 PM6/24/16
to
Just a reality check - the plan above for the Firefox 53 release still the same (as in April 2017)?

Also, I have been puzzled about something else recently. Even if the NPAPI plug-ins are allowed in Firefox ESR, how is the "plug-in black list" in Firefox ESR handled? Would Java be blocked somehow in it? In other words, is there a possibility that Java as a plug-in would be blocked in the Firefox ESR "plug-in black list", even though NPAPI plug-in's as a whole would still be allowed? And how likely is this to actually happen? Appreciate your help with these questions.

Benjamin Smedberg

unread,
Jun 27, 2016, 11:36:36 AM6/27/16
to Chris Peterson, dev-tech...@lists.mozilla.org
Actually Chris, my plan was to do this in Firefox 52, not wait for Firefox
53.

--BDS

On Wed, Apr 27, 2016 at 5:35 PM, Chris Peterson <cpet...@mozilla.com>
wrote:

Benjamin Smedberg

unread,
Jun 27, 2016, 11:39:41 AM6/27/16
to Java Dev, dev-tech...@lists.mozilla.org
On Fri, Jun 24, 2016 at 6:28 PM, Java Dev <wate...@gmail.com> wrote:

>
>
> Also, I have been puzzled about something else recently. Even if the NPAPI
> plug-ins are allowed in Firefox ESR, how is the "plug-in black list" in
> Firefox ESR handled? Would Java be blocked somehow in it? In other words,
> is there a possibility that Java as a plug-in would be blocked in the
> Firefox ESR "plug-in black list", even though NPAPI plug-in's as a whole
> would still be allowed? And how likely is this to actually happen?
> Appreciate your help with these questions.


The purpose of the plugin blocklist is to keep users secure from
known-vulnerable versions of various plugins. We regularly add old
versions of Flash and Java to the blocklist when security updates are
released. We also periodically may add the *current* version of plugins to
the blocklist if there are unpatched vulnerabilities which are being
actively exploited in the wild.

This is no different for ESR than normal release channels, and we will
continue to maintain this blocklist for Java versions through the end of
the supported ESR cycle.

--BDS

Christian Rottler

unread,
Jun 27, 2016, 11:45:16 AM6/27/16
to Benjamin Smedberg, Chris Peterson, dev-tech...@lists.mozilla.org
So, will the NPAPI support still be present in the ESR52 line of browsers or not? Now I'm a bit confused...

Regards,
Chris (some other Chris, that is)

Am 27. Juni 2016 17:35:57 MESZ, schrieb Benjamin Smedberg <benj...@smedbergs.us>:
>Actually Chris, my plan was to do this in Firefox 52, not wait for
>Firefox
>53.
>
>--BDS
>
>On Wed, Apr 27, 2016 at 5:35 PM, Chris Peterson <cpet...@mozilla.com>
>wrote:
>

Benjamin Smedberg

unread,
Jun 27, 2016, 11:47:12 AM6/27/16
to Christian Rottler, Chris Peterson, dev-tech...@lists.mozilla.org
Yes, we will support NPAPI in the ESR52 series. My intention is to stop
supporting it in the 52 release series.

--BDS

On Mon, Jun 27, 2016 at 11:44 AM, Christian Rottler <jot...@gmail.com>
wrote:

> So, will the NPAPI support still be present in the ESR52 line of browsers
> or not? Now I'm a bit confused...
>
> Regards,
> Chris (some other Chris, that is)
>
> Am 27. Juni 2016 17:35:57 MESZ, schrieb Benjamin Smedberg <
> benj...@smedbergs.us>:
>>
>> Actually Chris, my plan was to do this in Firefox 52, not wait for Firefox
>> 53.
>>
>> --BDS
>>
>> On Wed, Apr 27, 2016 at 5:35 PM, Chris Peterson <cpet...@mozilla.com>
>> wrote:
>>
>>> ------------------------------
>>>
>>> dev-tech-plugins mailing list
>>> dev-tech...@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-tech-plugins
>>
>>
>> ------------------------------

Christian Rottler

unread,
Jun 27, 2016, 11:49:21 AM6/27/16
to Benjamin Smedberg, Chris Peterson, dev-tech...@lists.mozilla.org
Okay, I see. Thanks for your quick reply!

Cheers,
Chris

Am 27. Juni 2016 17:46:34 MESZ, schrieb Benjamin Smedberg <benj...@smedbergs.us>:
>Yes, we will support NPAPI in the ESR52 series. My intention is to stop
>supporting it in the 52 release series.
>
>--BDS
>
>On Mon, Jun 27, 2016 at 11:44 AM, Christian Rottler <jot...@gmail.com>
>wrote:
>
>> So, will the NPAPI support still be present in the ESR52 line of
>browsers
>> or not? Now I'm a bit confused...
>>
>> Regards,
>> Chris (some other Chris, that is)
>>
>> Am 27. Juni 2016 17:35:57 MESZ, schrieb Benjamin Smedberg <
>> benj...@smedbergs.us>:
>>>
>>> Actually Chris, my plan was to do this in Firefox 52, not wait for
>Firefox
>>> 53.
>>>
>>> --BDS
>>>
>>> On Wed, Apr 27, 2016 at 5:35 PM, Chris Peterson
><cpet...@mozilla.com>
>>> wrote:
>>>

mattam...@gmail.com

unread,
Jul 3, 2016, 8:06:48 AM7/3/16
to
Hi,
I have an applet the communicates with client serial ports using https://github.com/scream3r/java-simple-serial-connector, if I sign the the jar and I use Java Web Start the applet has the permissions to communicate.
The favorite browser of our clients is Firefox so I would re write the app.
In Chrome I solved with chrome app end extension using https://developer.chrome.com/apps/serial and it runs very well but in firefox there'is nothing like this.

My questions are:
1) something like chrome.serial in the future of firefox?
2) now what's the better solution?
3) What's the better moments to re write my app, considering the roadmap of Web Extension?

Thanks
Marco




Benjamin Smedberg

unread,
Jul 5, 2016, 1:07:02 PM7/5/16
to mattam...@gmail.com, dev-tech...@lists.mozilla.org
At this point I don't think we have a plan to implement chrome.serial.
However, we are finishing up the implementation of native messaging (
https://developer.chrome.com/extensions/nativeMessaging) and it should be
relatively straightforward to build a serial-port bridge on top of native
messaging.

We'd also accept a webextensions implementation of chrome.serial if you
want to contribute it! I will happily introduce you to the webextensions
engineering team who can help with mentoring and reviews.

--BDS
> _______________________________________________

Java Dev

unread,
Jul 11, 2016, 5:38:37 PM7/11/16
to
On Monday, June 27, 2016 at 11:36:36 AM UTC-4, Benjamin Smedberg wrote:
> Actually Chris, my plan was to do this in Firefox 52, not wait for Firefox
> 53.
>
> --BDS
>


Thank you for the quick reply. Just to clarify, what is the scheduled release time frame/date for Firefox version 52 which would block all NPAPI plugins? Also, is it still the case that users who need NPAPI support can switch to Firefox ESR 52 and keep using NPAPI plugins until May 2018?


Best Regards,
Alexandra

Java Dev

unread,
Jul 11, 2016, 5:52:20 PM7/11/16
to
On Monday, June 27, 2016 at 11:39:41 AM UTC-4, Benjamin Smedberg wrote:
Thank you for addressing this topic as well. When the non-ESR version that blocks all NPAPI plugins is released, it would not need a blocklist anymore. Therefore, the blocklist would be used only by the ESR version while NPAPI plugins are still allowed for it. Is this correct? As such, is it possible to keep, at a minimum, the latest updates of Java available (not blocked) so that users can continue using Java with the ESR version while it still supports NPAPI plugins?

Best Regards,
Alexandra

Benjamin Smedberg

unread,
Jul 11, 2016, 6:00:21 PM7/11/16
to Java Dev, dev-tech...@lists.mozilla.org
On Mon, Jul 11, 2016 at 5:52 PM, Java Dev <wate...@gmail.com> wrote:

>
> Thank you for addressing this topic as well. When the non-ESR version that
> blocks all NPAPI plugins is released, it would not need a blocklist
> anymore. Therefore, the blocklist would be used only by the ESR version
> while NPAPI plugins are still allowed for it. Is this correct?


That is correct.

--BDS

Benjamin Smedberg

unread,
Jul 11, 2016, 6:01:01 PM7/11/16
to Java Dev, dev-tech...@lists.mozilla.org
The Firefox release calendar can be found at
https://wiki.mozilla.org/RapidRelease/Calendar

--BDS

Suril Patel

unread,
Jul 18, 2016, 5:06:23 PM7/18/16
to Benjamin Smedberg, Java Dev, dev-tech...@lists.mozilla.org
Hi Benjamin (or other associate),

I am trying to follow, but I think I am a little confused by the latest
exchange. We use an NPAPI plugin for Video conferencing, as part of very
large (millions) consumer facing organization.

Per what I understood previously, Version 52, will Beta Release on Jan 23
or Jan 24. The actual general release date - I don't see it, but I am
curious.

1) Will v52 - releasing in Q1 - by default blacklist all NPAPI plugins?
2) Thus, the user if he wishes to use an NPAPI plugin, he will have to
manually go somewhere to "enable" or "whitelist" plugins individually or is
it a setting for all? Any insights here are helpful.
3) What is general release date for v52?
4) I assume v53, which is April 2017 will completely disable NPAPI, with
no manual override.

I want to clarify - in our case, ESR versions are not part of the picture -
as our audience is millions of consumers, who will follow the general
release sequence of Firefox, with Auto-update (as an example, I am one of
them, who recently got upgraded to v47).


Thanks

Suril

On Mon, Jul 11, 2016 at 6:00 PM, Benjamin Smedberg <benj...@smedbergs.us>
wrote:

> The Firefox release calendar can be found at
> https://wiki.mozilla.org/RapidRelease/Calendar
>
> --BDS
>
> On Mon, Jul 11, 2016 at 5:38 PM, Java Dev <wate...@gmail.com> wrote:
>

Chris Peterson

unread,
Jul 18, 2016, 5:31:24 PM7/18/16
to
I believe Firefox 52 will completely disable NPAPI without any manual
pref override or whitelist (except for Flash).

The Firefox 52 release is planned for March 7, 2017. I updated the
release calendar wiki:

https://wiki.mozilla.org/RapidRelease/Calendar#Future_branch_dates

What is the NPAPI plugin that your organization uses for video
conferencing? Google Hangouts? Does your organization have a solution
for Chrome or Edge? They don't support NPAPI plugins.


chris

Suril Patel

unread,
Jul 18, 2016, 6:54:28 PM7/18/16
to Chris Peterson, dev-tech...@lists.mozilla.org
Hi Chris,

Thanks for your prompt response. We use Vidyo, Inc. plugin, called
VidyoWeb.

In Chrome, they have a browser extension. For Safari, IE, and FF, we
execute NPAPI code - based on browser detection. Edge - we detect and tell
the customer to switch browsers :) This is less than ideal, but WebRTC
does not meet some of our needs - and we see very good video quality at
lower bandwidths using this tech stack.

In any case, we really want to understand the plans and align ourselves.
This is a healthcare use case (I guess I could correspond officially from
my corporate email), with some of our population being the elderly - so we
want things to be easy.


So looking at what you shared - effective March 7th, the patients who's FF
automatically updates would not be able to sign in.

1) Is there a transitional version planned prior to that, where upon
update - all plugins default to a blacklist? In other words, is there
suppose a v51 - where upon update, VidyoWeb gets blacklisted and we need to
send out instructions to patients to unblock or whitelist VidyoWeb? (We
are investigating a long term solution that is not dependent on NPAPI - but
I just want to understand, in case management wants keep the NPAPI track
open until the end - how we can manage messaging to users on the site and
appropriately detect the browser to handle the various scenarios here)


Thanks

Suril

On Mon, Jul 18, 2016 at 5:31 PM, Chris Peterson <cpet...@mozilla.com>
wrote:

Chris Peterson

unread,
Jul 18, 2016, 7:24:56 PM7/18/16
to
hi Suril, Vidyo recently announced a plugin-free, WebRTC version of
VidyoWeb for Firefox and Chrome:

http://www.vidyo.com/company/news-and-events/press-releases/vidyo-delivers-webrtc/

http://www.vidyo.com/products/use/

Mozilla uses Vidyo internally. I have not personally tried the new
WebRTC client, but Mozilla's IT department is testing it and preparing
to deploy it within Mozilla. I usually use the VidyoDesktop standalone
client, but will switch to WebRTC when I have the chance.

chris

Chris Peterson

unread,
Jul 18, 2016, 7:35:31 PM7/18/16
to
Sorry, I forgot to answer your other question:

On 7/18/16 3:54 PM, Suril Patel wrote:
> So looking at what you shared - effective March 7th, the patients who's FF
> automatically updates would not be able to sign in.
>
> 1) Is there a transitional version planned prior to that, where upon
> update - all plugins default to a blacklist? In other words, is there
> suppose a v51 - where upon update, VidyoWeb gets blacklisted and we need to
> send out instructions to patients to unblock or whitelist VidyoWeb? (We
> are investigating a long term solution that is not dependent on NPAPI - but
> I just want to understand, in case management wants keep the NPAPI track
> open until the end - how we can manage messaging to users on the site and
> appropriately detect the browser to handle the various scenarios here)

As far as I understand, there will not be a transitional Firefox release
that blacklists plugins by default. The plan is to support all plugins
in 51 and then remove them in 52.

If Mozilla does remove NPAPI in Firefox 52 (and WebRTC VidyoWeb is not
an option), you could ask Firefox users to stick with Firefox 51, but
that workaround is probably no simpler than asking them to install
Firefox ESR. The simplest solution would probably be to recommend they
log into Chrome for video conferencing.

btw, if you find problems with VidyoWeb's WebRTC in Firefox that do not
affect Chrome, please let us/me know! We want to make sure that option
works seamlessly for everyone.

chris

mattam...@gmail.com

unread,
Aug 22, 2016, 6:35:55 AM8/22/16
to
Dear Benjamin,
we are very interested in the development of the serial API for firefox browser. Could you give us some suggestions on how to start to develop it? What are the requirements to contribute in this project?

Thank you very much
Marco Matta
Pegaso s.r.l

jblea...@gmail.com

unread,
Sep 7, 2016, 9:22:16 AM9/7/16
to
Please can you confirm the position regarding Silverlight support in 52 ESR?

I had understood from your 23rd Feb post that 52 ESR would support all NPAPI plugins though into 2018, including Silverlight.

If you are now planning to drop support for all but Flash, please can I ask you to reconsider for Silverlight too? Apple have included support for Silverlight in Safari 10 and we have a large userbase Silverlight application for which we would hate to lose Firefox support this early.

The 52 ESR release would be a great way to provide this extended transition time for organisations still dependent on Silverlight.

Thanks,
John

Benjamin Smedberg

unread,
Sep 7, 2016, 10:33:25 AM9/7/16
to jblea...@gmail.com, dev-tech...@lists.mozilla.org
52 *release* will only allow Flash.

The 52 *ESR* series will continue to allow all current NPAPI plugins (Java,
Silverlight, Unity etc)

--BDS

NdK ClanBO

unread,
Dec 21, 2016, 4:34:35 PM12/21/16
to
Il giorno mercoledì 7 settembre 2016 16:33:25 UTC+2, Benjamin Smedberg ha scritto:

> The 52 *ESR* series will continue to allow all current NPAPI plugins (Java,
> Silverlight, Unity etc)
Is there something planned for long-term support of legacy devices (network switches, IPMI web frontends, etc) that require JavaPlugin and for sure won't receive updates (manufacturers are not interested in letting users upgrade their existing devices... better if they're forced by someone else to buy the newer hw...)?

Tks,
Diego

Chris Peterson

unread,
Dec 21, 2016, 5:19:52 PM12/21/16
to
On 12/21/2016 1:34 PM, NdK ClanBO wrote:
>> > The 52 *ESR* series will continue to allow all current NPAPI plugins (Java,
>> > Silverlight, Unity etc)
> Is there something planned for long-term support of legacy devices (network switches, IPMI web frontends, etc) that require JavaPlugin and for sure won't receive updates (manufacturers are not interested in letting users upgrade their existing devices... better if they're forced by someone else to buy the newer hw...)?

Firefox 52 ESR version will support Java until 2018 Q1. IE on Windows
and Safari on macOS continue to support Java for now, too. I doubt
Microsoft will ever remove Java support from IE, so it will likely be a
long-term option.

chris