This was originally reported to me by Kenneth Russell at Sun, he noticed that navigating the documentation at the above URL works fine in Firefox as long as you do it on the website, but if you download the same docs (http://java.sun.com/javase/downloads/index.jsp, Java SE 6 Documentation) to to your disk and load it from there, clicking on the links causes new windows to open up all the time. This appears to be a side effect of the file:// origin changes we've made, and setting "security.fileuri.origin_policy" to 4 reverts those changes back to what they used to be, and that fixes the problem with the docs loaded from file:// URIs as well. Dan, please add other dependencies etc as you see fit, marking this blocking per our discussion earlier.

What makes you think this is unintended? It could be that the named frame isn't same-origin with the page that's trying to load it, and therefore shouldn't be targeted.

(In reply to comment #1) Unintended, unwanted or unacceptable -- it's just a matter of terminology. The fact is that this behavior severely breaks the downloaded documentation bundles for the Java Development Kit and given that it does not happen with either Internet Explorer or Firefox 2 it is an unacceptable regression that requires rethinking the new security policies to admit this use case.

marking as regression from bug 230606. Removing dependency on bug 402983, making the checks symmetric aren't going to help here, we're going to have to special-case file: (or maybe add a protocol handler flag to make it generic) in the frame targetting code.

This is a narrow "fix" for this bug, or at least part of it. The downloaded Java docs work and stay within their frameset with this patch, but because it doesn't actually change the definition of same-origin each new page fails to update the title (setting parent.document.title from the iframe throws). For Java docs that's kinda livable, for a web-app that does anything even slightly more complex (see example in bug 404822) this doesn't help at all. I think I've come around to bz's suggestion in bug 402983 comment 12 as the only thing that will work. This patch might still be useful for framesets that are not hierarchical but can still be kept sort of running.

Comment on attachment 310037 [details] [diff] [review] special-case file: frame targetting sr=bzbarsky if you get the innermost URIs before getting schemes.

Comment on attachment 310037 [details] [diff] [review] special-case file: frame targetting Though I suppose that could be arguable. If you feel it's better not to, I'm OK with that too.

Fix checked in with the addition of drilling into the innermost URI as requested by bz

this causes crashes for chrome applications - bug 428288.