Java plugin phase out timeline

[Java Dev]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

The Firefox release calendar can be found at
https://wiki.mozilla.org/RapidRelease/Calendar

--BDS

[Suril Patel]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[NdK ClanBO]

Il giorno mercoledì 21 dicembre 2016 23:19:52 UTC+1, Chris Peterson ha scritto:

> 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.

Not for Linux-only users :(

BYtE,
Diego.

[peter.w...@gmail.com]

Den onsdag den 7. september 2016 kl. 16.33.25 UTC+2 skrev Benjamin Smedberg:
> 52 *release* will only allow Flash.
>
> The 52 *ESR* series will continue to allow all current NPAPI plugins (Java,
> Silverlight, Unity etc)
>
> --BDS

How can I - based on browser user agent detection - tell the difference between a version 52 *release* and a version 52 *ESR* ?
I want to guide the end user depending on the browser capability to support the Java plug-in.
Thanks
Peter

[peter.w...@gmail.com]

I seem to have found the answer in https://bugzilla.mozilla.org/show_bug.cgi?id=1269807#c83 :
"Unfortunately, you can't detect ESR from the server side because both ESR and non-ESR releases have the same User-Agent string."

:-(

/Peter

[Chris Peterson]

On 1/2/2017 8:44 AM, peter.w...@gmail.com wrote:
>> > How can I - based on browser user agent detection - tell the difference between a version 52 *release* and a version 52 *ESR* ?
>> > I want to guide the end user depending on the browser capability to support the Java plug-in.
>> > Thanks
>> > Peter
> I seem to have found the answer in https://bugzilla.mozilla.org/show_bug.cgi?id=1269807#c83 :
> "Unfortunately, you can't detect ESR from the server side because both ESR and non-ESR releases have the same User-Agent string."

As noted, there is no officially supported method to differentiate
between the ESR and regular non-ESR versions of Firefox 52 using
User-Agent detection on the server side. However, non-ESR Firefox 52 is
dropping support for Windows XP and Vista, while ESR 52 will continue to
support XP and Vista. So if a User-Agent string says the user is running
Firefox 52 and XP or Vista, then they are running ESR 52.

On the client side, you can make a good guess. If navigator.plugins has
zero or exactly one entry and it is Flash, then there is a good chance
the user is running ESR 52, since many people have other plugins such as
Adobe Acrobat Reader that would show up in ESR 52.

[peter.w...@gmail.com]

> 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

Would you be able share information - here or in private communication - about how soon Release 52 will take effect in the end user experience?
- What time of the day will Release 52 be released in Central Europe Time zone (CET)?
- What will trigger the auto-update to v52 by end user (download/install/run) - Process in background? Launching Firefox? Opening new tab? Refresh?
- Is there any server side mechanism from you that will delay the update (by days/weeks) beyond the end user trigger to reduce the peak load on your server?

We are running a web service based on a Java applet, and we currently see some 10k unique users per day using Firefox v50 (90% Windows, 10% Mac) and a few v49, v48 and v47.
It is now clear that we will not be able to replace the Java applet in time before the release of Firefox v52 (March 7).
We have to prepare our support team for helping our Firefox users when Java stops working for them because of update to v52.
FYI: Our user agent statistics from December 2016 (total) shows v50.0 and practically no v50.1 though v50.1 was released in mid-December.

Thanks
Peter

[Chris Peterson]

On 1/12/2017 4:34 AM, peter.w...@gmail.com wrote:
> Would you be able share information - here or in private communication - about how soon Release 52 will take effect in the end user experience?
> - What time of the day will Release 52 be released in Central Europe Time zone (CET)?
> - What will trigger the auto-update to v52 by end user (download/install/run) - Process in background? Launching Firefox? Opening new tab? Refresh?
> - Is there any server side mechanism from you that will delay the update (by days/weeks) beyond the end user trigger to reduce the peak load on your server?

March 7 is the official release date for Firefox 52, but Mozilla uses
server-side throttling to slowly update only a few thousand users over
the first week or so. If we don't see any new bug reports from those
users, we unthrottle the update and all other users should automatically
receive the update within 24 hours of the next time they launch Firefox.
(Firefox pings the update server every 24 hours.)

> We are running a web service based on a Java applet, and we currently see some 10k unique users per day using Firefox v50 (90% Windows, 10% Mac) and a few v49, v48 and v47.
> It is now clear that we will not be able to replace the Java applet in time before the release of Firefox v52 (March 7).
> We have to prepare our support team for helping our Firefox users when Java stops working for them because of update to v52.
> FYI: Our user agent statistics from December 2016 (total) shows v50.0 and practically no v50.1 though v50.1 was released in mid-December.

New updates may get downloaded but not installed if users don't restart
their browser periodically. Also, there are some long-standing Firefox
bugs that cause some users to get "stuck" on older Firefox versions.
Anti-virus software can cause update problems, too.

Options for using Java after Firefox 52 release are switching to the
Firefox "ESR" version (Extended Support Release [1]) or using IE on
Windows and Safari on Mac.

[1] https://www.mozilla.org/en-US/firefox/organizations/

[peter.w...@gmail.com]

We appreciate your fast and detailed answer – it’s mission critical to us.
We have identified the same workaround options (IE and FF ESR) but in our experience, Safari is not a practical alternative for using Java. It requires an extra setting per web site – which is complicated to the average user – to allow write access to the file system for Java. Moreover it seems like Apple has now blocked that since Safari v 10.0.2 (released December 13, 2016), which is included in MAC OS updates.
So for our Mac (and Linux btw) users, Firefox ESR remains the only option for a browser with Java support.
/Peter

[peter.w...@gmail.com]

Is it a fair assumption that you will not 'unthrottle' Firefox 52 before business hours (PST) on Monday, March 13 ?
Thanks,
Peter

[Benjamin Smedberg]

No, that is not a fair assumption. We sometimes unthrottle as soon as
Thursday or Friday of release week, if there are no alerts from the
incoming data.

--BDS

[mansourd...@gmail.com]

در سه‌شنبه 23 فوریهٔ 2016، ساعت 21:33:41 (UTC+3:30)، Java Dev نوشته:

[mansourd...@gmail.com]

در سه‌شنبه 23 فوریهٔ 2016، ساعت 22:05:46 (UTC+3:30)، Chris Peterson نوشته:

> 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

[mansourd...@gmail.com]

در چهارشنبه 24 فوریهٔ 2016، ساعت 17:00:21 (UTC+3:30)، bna...@gmail.com نوشته:
> 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