Firefox update broke my application. Again!

[TakaIta]

I have had this problem several times now.

viewtopic.php?f=25&t=607422 (FF 2.00.10 - it was solved in 2.0.0.11)
viewtopic.php?f=23&t=660137 (FF 3.0)

And now again in FF 2.00.15.

The matter is that in my application there is a HTML with an iframe with src="jar:http://domain/site/js/privlib.jar!/privlib.html"
The jar-file holds a html-document with a script that browses the own network. This functionality requires a certificate. Which is fine. The certificate has been created and it all works.

Except with
FF 2.00.10
FF 2.00.15
FF 3.0


Below is the function that fails with error message: "Error: uncaught exception: Permission denied to get property HTMLDocument.privlib"

<script>
function GetPrivlib() {
var frame = document.getElementById("privlib"); //"privlib" is the id of the iframe with a src pointing to a jar-file
// the next line gives the error
if (frame && frame.contentDocument && frame.contentDocument.privlib) {
return frame.contentDocument.privlib;
}
return null;
}
</script>

I did some testing where it goes wrong:

var frame = document.getElementById("privlib");
// above line gives no problem

var oContentWindow = frame.contentWindow;
// above line creates an error: "Error: uncaught exception: Permission denied to get property Window.prototype"


I have made sure (and checked) that .jar files have the mimetype "application/java-archive", which is correct as far as I know.

Now please. Is this a bug in Firefox and/or is there something I can do to work around this problem.
When exactly the same happened with FF 2.0.0.10, it was quickly followed up with FF 2.0.0.11 in which the problem was solved.
Why is it back again?

[bzbarsky]

var frame = document.getElementById("privlib"); //"privlib" is the id of the iframe with a src pointing to a jar-file
// the next line gives the error
if (frame && frame.contentDocument && frame.contentDocument.privlib) {

So you have an unsigned page touching a signed page's DOM? That's a security violation. There was a bug in that this was allowed in some situations in the past, but that was a security hole, as you might expect, and got fixed.

You need to put all pages that need to talk to each other in the same trust domain (either all signed or all not signed)... On trunk you can use postMessage to communicate across trust domains, but on branch using a single trust domain is the way to go.

See also https://bugzilla.mozilla.org/show_bug.cgi?id=434544

[TakaIta]

So you have an unsigned page touching a signed page's DOM? That's a security violation. There was a bug in that this was allowed in some situations in the past, but that was a security hole, as you might expect, and got fixed.

You need to put all pages that need to talk to each other in the same trust domain (either all signed or all not signed)... On trunk you can use postMessage to communicate across trust domains, but on branch using a single trust domain is the way to go.

See also https://bugzilla.mozilla.org/show_bug.cgi?id=434544

Thanks. At least that explains what the problem is. And the given link gives me some clues to solving it - it describes the same problem as I have: a dynamically generated page (which - for all I know - is impossible to sign) which requires functionality that must be signed.