Persona is no longer an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 794247 - Softblock Java 7 versions that were previously infobar-blocked
: Softblock Java 7 versions that were previously infobar-blocked
: qawanted
Product: Toolkit
Classification: Components
Component: Blocklisting (show other bugs)
: unspecified
: All All
: -- major with 1 vote (vote)
: ---
Assigned To: Jorge Villalobos [:jorgev]
: juan becerra [:juanb]
: Jorge Villalobos [:jorgev]
Depends on: CVE-2012-4681 787585
  Show dependency treegraph
Reported: 2012-09-25 14:38 PDT by Jorge Villalobos [:jorgev]
Modified: 2016-03-07 15:30 PST (History)
18 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description Jorge Villalobos [:jorgev] 2012-09-25 14:38:28 PDT
On bug 787585 and bug 785837, we blocked Java 7 with an infobar level. In order to better protect our users, we are now raising the block level to a softblock. Affected users can enable the plugin again if they choose to, but they are all strongly recommended to visit our plugin check page and update their plugins:
Comment 1 Jorge Villalobos [:jorgev] 2012-09-25 14:42:25 PDT
The blocks are now updated in prod. QA, please verify.
Comment 2 Joost Ringoot 2012-10-17 04:20:11 PDT
The latest stable version is also blocked:
How to get a stable working version?
Comment 3 Joost Ringoot 2012-10-17 04:34:26 PDT
Correction: How to get a "safe" stable working version.
Comment 4 Jorge Villalobos [:jorgev] 2012-10-17 08:41:05 PDT
What kind of block do you see? If you click on the More Information option, which page does it take you to?
Comment 5 Andre Weissflog 2012-11-26 04:05:02 PST
I noticed that this block only blocks the main Java plugin, and not the Java Deployment Toolkit addon. This will confuse web pages which check whether Java is available or not using Oracles recommended method through the deployJava.js script (they think it's available, since the deployment plugin says all is ok, while the actual Java plugin cannot be started since it's blocked by FF).

This actually even confuses the Java updater webpages, e.g.:

1) make sure you have the latest Java runtime installed
2) go to
3) notice how there's a show-stopper displaying the FF blocking message
4) now, also disable the Java Deployment Toolkit plugin, and try again, this time the web page correctly recommends downloading the latest Java version.

Uh, I see that this ticket has been set to resolved, I'll create a new one describing the issue.
Comment 6 TREMBLAY,Bernard 2013-01-19 09:48:30 PST

It seems that the last version of java 1.7.0_11 is locked as previous of 1.7.0_2

note : The reported version number (set by Sun 1.7.0_11) appears as numeric when sun uses alpha ??? to manage numbers > 9

As user of FF 18.0.1 with last Java version 1.7.0_11 I see incoherent behavior, more FF crashes for each url loaded using Java Applets since the Java installation.
The plugin is SE 7 U5 systematically unactivated.
For me it is dead lock in using FF.
Comment 7 Jorge Villalobos [:jorgev] 2013-01-21 06:18:52 PST
Java 7u11 is blocked due to bug 831914. Are you saying that Firefox crashes on Java pages where the plugin is blocked? Does it crash when you try to load the plugin, or before that?
Comment 8 TREMBLAY,Bernard 2013-01-21 09:06:11 PST

I have continuous crashes of FF since I upgrade java to 1.7.0_11 when loading new pages (generally it seems - to check repeatedly - at first load of a domain -, auto ident, check cookies ?) this without any message. 

I detail further some important facts and problems :

Probably in particular case which I could not get more details for now.
I use both versions 32 and 64 bits.

first point :
The javacpl of 1.7.0_11 is not clear because it is not able to treat both versions 32 and 64 and javacpl declarations related with plugins.
If you declare in javacpl.exe (32) the 64bits version after registering and without any warning message it will disappear form the list. Then you must declare your versions in each javacpl and rename - it is a trick with icons - and we must be aware of coherency problems with registry

Second point
When the activated versions of java (with their user_parameters) are changed using javacpl the link with registry updates particularly for Plugins is wrong.
I have changed the keys to point npjp2.dll 32 bits in 1.7.0_11 32bits java installation in mozillaplugins keys (application and Wov6432node) and followed the informations update with about:plugins which shows for my FF 18.0.1 the right values for the plugin ( Java(TM) Platform SE 7 U11

    Fichier : npjp2.dll
    Version :
    Next Generation Java Plug-in 10.11.2 for Mozilla browsers
) as activated (not locked) 

Third point FF crashes :
In this situation I get continuous crashes that I got after installing java 1.7.0_11.
So I cannot be sure of the reason, but I never get any message about plugin unactivation, This is particularly curious, I explain :
with <> I get the panel (in french "Ce plugin possède des failles de sécurité. Cliquez ici pour activer le plugin Java(TM) Platform SE7 U. This while about:support reports the plugin activated while it should not.
Then the plugin is activated (on request)  Java SE 7 Update11 Windows 7 6.1 Java Architecture 32-bit.

Crashes : 
Particularly each time there is a login panel called (automated or manual) on any site, and many others crashes anywhere (very difficult to find the common point(s), never I got any activation of java applets request.
So since three days I uses FF only to get url from bookmarks and uses other navigator (google chrome) to work slowly (I change priorities not to have to use too much a navigator.

I have no proof of the relation between the java plugin management problem and the crashes. As I do not develop for mozilla actually (even I participate) so I am not fully able to analyse my crashes reports.
Nevertheless the facts have been concurrent.

I just tried again a test : <> which is auto connect with LastPass (to memorize data of context) and by cookies. When there are concurrent previously, I just remarked during the load a loop in connection ended by a crash.
So I have suppressed the auto connect with LastPass and I could open the url without crash. This is a simple information, I am not able to make more than hypothesis and go on some test.

Sorry if I cannot be more precise I have no mean.
Comment 9 Jorge Villalobos [:jorgev] 2013-01-21 12:38:49 PST
(In reply to TREMBLAY,Bernard from comment #8)
> So I cannot be sure of the reason, but I never get any message about plugin
> unactivation, This is particularly curious, I explain :
> with <> I get the panel (in
> french "Ce plugin possède des failles de sécurité. Cliquez ici pour activer
> le plugin Java(TM) Platform SE7 U. This while about:support reports the
> plugin activated while it should not.
> Then the plugin is activated (on request)  Java SE 7 Update11 Windows 7 6.1
> Java Architecture 32-bit.

This is the expected behavior and what I was asking about. You should always see the panel telling you the plugin should only be activated if necessary, and give you the option to load it. The plugin won't appear as disabled in the Add-ons Manager; that's also normal.

The other problems you're experiencing could be related to the 32-bit, 64-bit switching you do, but I can't be sure. That's possibly something to discuss with Oracle, or in one this newsgroup:!forum/
Comment 10 TREMBLAY,Bernard 2013-01-21 16:55:25 PST
This day 01/22/13 - 00:33 (Paris)

The plugin fully registered is only jp2iexp.dll :
as sample of class (
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID\{CAFEEFAC-0017-0000-FFFF-ABCDEFFEDCBA}\InprocServer32 (Default=...Program Files (x86)\Java\<jre1.7.0_11-x86\bin\jp2iexp.dll)
HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{E19F9331-3110-11D4-991C-005004D3B3DB}\InprocServer32 (Default=..\Program Files (x86)\Java\jre7.0_11-x86\bin\jp2iexp.dll)

No registry entries  can be found for npjp2.dll components
The lonely entry is the reference into the MozillaPlugins :

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\MozillaPlugins\,version=10.5.1 (Path=C:\Program Files (x86)\Java\jre7.0_11-x86\bin\plugin2\npjp2.dll)
HKEY_LOCAL_MACHINE\SOFTWARE\MozillaPlugins\,version=10.11.2 (Path=C:\Program Files (x86)\Java\jre7.0_11-x86\bin\plugin2\npjp2.dll)

You can note that the versions are different for the two keys.

All this, may be, must be put in relation with the failure reported in :
during installer run :
java_sp.dll which fails (registering Firefox plugins)

Note : I am sure to have seen such a message but I could not get the screenshot and the referenced partial crash of installer was with 1.7.0_10.

I do not know how any plugin can be called with no one CLSID link assumed by the InprocServer32, but... 

This was some complementary informations about the Java plugin dll register.
Comment 11 TREMBLAY,Bernard 2013-01-21 17:39:05 PST

9 and 10 have been redacted at same time.
I answer to your answer 9.
I agree completely about the behavior of the security panel, I know it and I got it before and today I can display it with the url <> but I don't got it in other cases.

I have reported the registry informations in 10#.
The last most important that I found is the fact that the LastPass autoconnection or a launch a connection from LastPass directly creates always a crash. This never happens before 1.7.0_11. 
Can it be related to java applets, which one ? 
I don't know and I cannot test it.
I should need urls to check the various applets separately.

Many people are going on reporting on this subject but nobody seems to meet the heavy crashes that I get.

As I said previously I am going on test to get others crashes, if so, excluding now the LastPass connections. It is not so easy because I cannot change the autoconnection option for all sites on which I have to login (400).

About any switch between 32 and 64, it is not what I mean. Java says that if we have 32 and 64 bits applications, both the java versions and plugins must be installed.
The problem is that the 32 bit and 64 bits application must be linked to the right CLSID and have the good declared dll. 
This was the problem on my computer, for 1.7.0_11 I installed first the 64 bit to use with Eclipse (01/15/13 twice, I reinstall changing directory name) and after the 32 (01/19/13), trying to solve the crashes. 
When I began to check registry I found in MozillaPlugins the ref to the 64 bits first installation version...
You can note too that the url :  <> never finds the java version which is running.
Comment 12 TREMBLAY,Bernard 2013-01-23 11:02:41 PST

I could check various messages on Mozilla support and someones elsewhere.
So even there is a problem with version number displayed the problem is not there.
Note that I use the two versions, 32 and 64, of java 1.7.0_11.

I checked my registry and Firefox:about:support : 
I could notice several major errors.

note : I am quite sure that there are others opened id on the subject, but I do not know where are they (right keyword to find them...).

The anomalies which I am not sure that they will solved with java 1.7.0_12 are :

1- When update of java occur and changes of activated java versions with javacpl (new panel for plugins security management with 1.7.0_11), the plugin keys MozillaPlugin are not updated.
But they where set for the previous version (I reinstalled into special dir to avoid errors "jre-X86-170_11" and "jre-64-170_11") while the default jre7 for both x86 and 64b have been unactivated with javacpl)

As I have tested the Registry keys which are filled are wrong (not good file name for npjp2.dll and not good directory refers to 64bits version, see further)

2- I use the 32bits version of FireFox on Win7 nevertheless the java Plugin referenced by Firefox as activated is the 64bits version. I am not sure at all, quite absolutely sure versus, that FireFox 32 must use the Java 32. 

This can surely explain that I have crashed Firefox may be 90th time since I upgraded Java to 1.7.0_11.

note : The documents that I could collect from Mozilla support don't threat at all of the registry keys values depending of used version. So I am going to test update of keys.

Best regards
Comment 13 TREMBLAY,Bernard 2013-01-27 19:31:59 PST
It was not the reason of the crashes.
There is, till now, no reason known.
By the way, FF is for me unusable.
I get repeatedly crashes, may be on plugins but not java.
I crashes while loading a page with call to  (without the call the page is loaded, with the call it crashes always), but I can load it in mode without exception, modules unactivated...
Nevertheless, I do believe that it is important to know the curious thing that I found while seaking for a solution to the crashes.
Comment 14 TREMBLAY,Bernard 2013-01-29 16:13:02 PST
Finally I tried 19.0b3 and had the same problems.
I downgrade to 17.0.2esr.
I could after 10 day work normally without any crash with same add-ons and plugins.
May be an add-on or plugin creates the problem because in safe mode I don't got crash.
But which combination ? Which add-on I could not find.
Comment 15 browneyebuttafly 2013-10-23 09:34:57 PDT
I have the new version of firefox (24) and I also downloaded the newest version of Java (Java 7 update 45) It still has me blocked?!?!?!?! I've done everything and its not working. All I was trying to do is print coupons that I've always been able to print before?! What the hell! I'm so frustrated after working on this problem for over 2 hours!!! Can anybody help me please? Thanks in advance!
Comment 16 Jorge Villalobos [:jorgev] 2013-10-23 09:48:23 PDT
The latest version of Java was recently blocked, but the block was reverted. It will take a couple of days for the block to update and Java be unblocked again. See bug 914690 comment #80.
Comment 17 browneyebuttafly 2013-10-23 09:51:42 PDT
Oh ok, I thought this thread and the blocking issues were from Jan 2013 since that was the last comment in this thread. thanks

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