581717 - Firefox does not read java cache correctly

Status: RESOLVED INCOMPLETE

(Firefox :: File Handling, defect)

Description

[Phil Bays]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_4; en-us) AppleWebKit/533.16 (KHTML, like Gecko) Version/5.0 Safari/533.16
Build Identifier: Java 6 update 20,  Firefox 3.6.7 and 3.6.8, Mac OS 10.6.4

Java cache cleared using Java Preferences options.   No files located in the cache.
Launch the above URL.   The applet loads, the first molecule is read and loaded.
Press the Chlorophyll button and the second molecule is correctly loaded.
Now in the Java cache there are three things: the applet and the two model files.

Quit Firefox.
Relaunch firefox and go to the same URL.
The first molecule loads, the second throws an access error.

The page works fine in all non-Moziulla browsers and in all PC browsers, including Firefox.  It does not run on the Mac in Firefox, Camino, or Seamonkey.

The model files are located in the same directory.
If I change the code so that it tries to load the first molecule a second time, I observe the same error in the second step.

If I turn off Java caching, the page works fine.

If I run the signed applet (same URL file NT2.html), and then run NT1 without shutting down Firefox,
NT1 runs fine, until I quit firefox.   Then I have to clear java cache.  

Actually the only thing that has to be removed from the java cache is the file for the second structure.


Reproducible: Always

Steps to Reproduce:
1.Launch Firefox afresh with a cleared java cache
2.load the above URL and run.  Two models will be loaded.
3.Quit Firefox.  Restart , relaunch and reload the page.. 
Actual Results:  
On the second and subsequent runs of browser to the above URL, the second molecule load throws a java access error

Expected Results:  
The file would run as it did the first time, loading two structure sequentially.

I think it is all covered

Comment 1

[Jo Hermans]

That is a problem in your version of Java, Firefox doesn't read that cache at all. That's why you see the problem on Mac, but not on Windows (different versions).

Comment 2

[Bob Hanson]

I disagree with this assessment. Perhaps the issue is slightly different than stated. This appears to be a liveConnect issue. Specifically, on second opening of the browser and then loading a data file by clicking on a link, the action is blocked by an inappropriate security check. 

It is not a case of clearing the cache or Java somehow not being able to read its cache.

It is an issue of the event thread produced by liveConnect not being able to access the cached file when that particular thread runs Java's URL.openConnection() method. 

Firefox 3.5.7/Mac did not have this issue. I suggest it is some sort of bug associated with changes to the Firefox security model in 3.6.8. 

Bob Hanson
principal developer, Jmol

Comment 3

[Jo Hermans]

If you think so - but it won't be the first time that problems are caused by different versions of Java. And the title of this bug doesn't really help (Firefox never reads the Java cache at all).

Comment 4

[Bob Hanson]

Thank you. I understand -- we're still tracking down what this could be. We have it working in some Firefox 3.6.8 versions but not others, but those are on different machines also with different Java versions. We're tracking that down now...

Comment 5

[Bob Hanson]

The bug has been associated and confirmed by four independent users with Firefox 3.6.7 and 3.6.8. 

If I have this correct:

July 20, 2010: Firefox 3.6.7 was a security and stability update that fixed several issues.[19]

July 23, 2010: Firefox 3.6.8 is a security and stability update that was released a mere 3 days after 3.6.7, to fix yet another security fault.[20]

then it seems to me the chances are very high that something in the Firefox 3.6.7/Mac update broke the way liveConnect can have access to local files in a remotely loaded applet even though those local files are being accessed from the Java cache. 

Do you want me to file a new bug report that is more to the point?

Comment 6

[Bob Hanson]

Here is the data we have collected to date:

Java 1.4  Firefox 3.6.8/Mac -- GOOD (1 user)
Java 1.5  Firefox 3.5.7/Mac  -- GOOD (1 user)
Java 1.5  Firefox 3.6.8/Mac  -- GOOD (1 user)
Java 1.6  Firefox 3.5.7/Mac  -- unknown
Java 1.6  Firefox 3.6.8/Mac  -- BAD (5 users)
Java 1.6  Firefox 4.0beta/Mac -- GOOD (1 user)

Comment 7

[Bob Hanson]

I think one last bit of information should convince all that it is a Firefox 3.6.7/8 issue. 

We have two ways to load a model into the Jmol applet -- either using a built-in console and the command "load ...." or via liveConnect and a page-based link or button. 

A user has confirmed that the problem is ONLY when the model is loaded using liveConnect, and that console-based loading is no problem.

Thus, succintly stated, the bug is this:

Specifically with Firefox 3.6.7/Mac or Firefox 3.6.8/Mac, the thread that liveConnect uses to communicate with a Java applet running Java 1.6 is throwing an inappropriate Java security exception: 

java.security.AccessControlException: access denied (java.util.PropertyPermission http.agent read)

when accessing a remote (http://...) file that was successfully loaded in a previous session and was saved in its local Java cache during that previous browser session. 

Five Jmol users have been able to confirm this problem. It seems to me this should not be very hard to replicate and track down. While it certainly might be a Java 1.6 bug, we would appreciate someone from the Mozilla group helping us pinpoint what in the liveConnect/Java connection is causing the problem. 

Thank you,

Bob Hanson
principal developer, Jmol

Comment 8

[Petruta Horea [:phorea], Desktop QA]

Closing this as Incomplete since its been a long time since the last update on this issue and there is no reachable test case to investigate this further; the Java and Firefox mentioned versions are now obsolete.