There is a report on the Mozilla bug database (https://bugzilla.mozilla.org/show_bug.cgi?id=421812) that the Windows OEM builds of Java crash Firefox if FF is the first browser used to launch an applet on such systems.

The best guess is that this is somehow related to the EULA dialog.

We need to investigate this immediately and see whether a rapid fix is necessary. If it turns out that the issue does not affect a large percentage of users the priority can be adjusted as necessary.
Posted Date : 2008-03-12 23:45:50.0

N/A

The following message had been left on BMO for submitter:

Romain: I don't have access to any OEM JRE. So sure, I'll take a look at the
zipped copy of JRE1.6.0_02 OEM if you can provide it.

zip copy of registry contents is not a good idea. You probably want to
regedit->export to a .reg file instead.
I'm not sure where Sony, Dell and other OEMs put their OEM JRE in the registry.
But it's probably good to try at this location:
HKLM->SOFTWARE->JavaSoft

Or if you know where OEM JRE is in your registry, please export just that hive.

But please understand that I may not be able to do any debug without a full
installer but only some zipped contents.

I'll check with someone inside Sun too to see if we can contact the OEM and ask
for a copy of their JRE installer.

Meanwhile, if possible, could you install latest JRE from Sun on the affected
machines. JRE downloaded directly from Sun are tested to work with FF2 and FF3.
Just go to java.com and follow the few clicks to install latest Java. JRE
1.6.0_05 is the latest currently at java.com.

Also, could you please confirm: is this problem only happened on Vista or on any
Windows?
Posted Date : 2008-03-18 19:00:19.0

There are 2 issues involved here:

1)  Key root cause was because the eula.dll was not populated in <jre_home>/bin/ when JRE is installed with only /v"EULA=1" option as instructed by info on java-partner side.
The result is, both IE and FF will hang on user's first attempt to use JPI or JWS.
The instruction should have advise OEM to use /v"ADDLOCAL=all EULA=1" instead.

Basically, the EULA's information/instruction in java-partner side is incorrect. We must update this information and contact all OEMs to follow the new instruction.
Bill will review and make suggestion on how the EULA's instruction on java-partner should be changed to, as he's the installer expert.

Here is a few comments from me about current instruction:
- stated "3 ways that a user can see and agree to the End User Licensing Agreement" but listed 4. It's important to describe the correct ways user could see the EULA popup, because to engineering, that's test specs!
- Do we need to mention (1)?  In fact, I don't think (1) is an option. When OEMs installing the bundle at their manufacturing floor, they will always see the EULA during installation, and there should be no option to turn that off. We should only mention about the EULA popup for first time Java plugin usage, that is, the behavior associated with "ADDLOCAL=all EULA=1" installer's argument.
- Looks like (2) and (3) should be combined.
- (3) mentioned "This option should be used when the software is installed with silent installation" but later example showed option used during non-silent installation.
- I don't understand (4). How to incorporate Sun's license terms with distributor's end user license? There's no instruction whatsoever.
- Is it MANDATORY for OEMs to install the bundle at their manufacturing floors with "ADDLOCAL=all EULA=1"? If yes, it must be stated so. Currently, problem is reportedly seen with Dell, Acer, and Sony. Unsure, if other OEMs also exhibit same problem because we don't know if all OEM follow the same instruction.
- "Registry Keys" section mentioned 2 keys, but listed only 1 under HKLM. Should also list the key under HKCU.
- "ADDLOCAL=all" is only needed for update release prior to 6u10 (to how far back? Bill will know the answer). For 6u10, this option is no longer required to install all packages. So please make clear that the new instruction won't confuse OEMs.

2)  The Eula code path was written since 1.4.2 and was specifically for COM/ATL objects (IE env). Therefore, when the eula.dll is populated to the right place, it will work well with IE.
However, this code path becomes very broken when it comes to share with Mozilla browser. Problem includes eula.dll won't get loaded and various MS libraries are missing for exported functions from eula.dll to operate.

Due to the impact this problem has on OEMs, it's considered serious. Will raise the priority and try to get fix in to 6u7.
Posted Date : 2008-03-27 18:01:26.0

The existing EULA code path for Mozilla/FF causes eula.dll not loaded. 
Further, it spawns a thread to launch the DialogBox.
This code path might have worked at one point long ago with Mozilla/FF (Perhaps prior to FF0.9 when the browser still preloaded JPI libraries). But as of current, with latest FF and most recent Mozilla browsers, it suffers from synchronization problem during initialization of DialogBox, and in turn, causes the browser to hang.

The extra thread to launch the dialog box proves no necessity for Mozilla/FF browsers.

Fix is to use the same code path as IE which launch the DialogBox directly. Plus load extra riched20.dll which is needed to handle edit controls for DialogBox.  This dll is preloaded with IE but not for FF.

Webrev and approval request had been sent for 6u7 b01
Posted Date : 2008-03-31 23:12:39.0

Hi ! I am the guy which reported the bug on mozilla bugzilla.
We use applets for our business and we have some raw statistics about the percentage of people it affects, and it's affecting an increasing percentage of people.
From our raw estimates from our website, it is around 5% of global visitors. The problem is this percentage is way higher for people buying new computers, where it's around 15%.