Open Bug 1430257 Opened 2 years ago Updated Last year
[meta] Stop treating nested URIs as same-origin with their innermost URI
(largely copied from bug 1171853) It seems there's not that many nested URI schemes left. While some of those rely on being same-origin with their inner, that likely isn't the ideal behaviour. To change this, we need to get rid of the existing nested URIs that might rely on that in some way. In particular: - remove remote JAR support (bug 1427726) - stop nesting about: URIs (bug 1228118) - (maybe) stop having nested moz-icon URIs (they don't really need to be nested, and it's doubtful much will break if we unnest them - file: listings and so on already use the non-nested variants; equally, I don't think making them non-same-origin with the nested URI will break anything that we intend to work). - remove the IO Service's newNestedSimpleURI exposed method (bug 1430237) so no new surprise consumers will end up being created. - figure out what the story is with jar: URI usage on android. Nick, can you help with that? How is jar:jar used, and does gecko resolve it or does android java code do so, or something else? In particular, do we ever load jar:<anything> as a toplevel document in the browser content or as an image/resource that we then need access to (as opposed to e.g. a script file reference, or loading the same content via chrome:// or resource:// URIs)?
Would this effect the origin of view-source URLs? I'm curious how it would effect bug 1317036.
> Would this effect the origin of view-source URLs? Yes. That is one of the main goals, in fact. > I'm curious how it would effect bug 1317036 That's using URIs, not principals, right? It could still unnest the view-source URI if it wanted to...
Well, what will the origin of "view-source:http://example.com" be? Will it be exactly that vs "http://example.com"?
(In reply to Ben Kelly [:bkelly] from comment #3) > Well, what will the origin of "view-source:http://example.com" be? Will it > be exactly that vs "http://example.com"? Yes.
> - figure out what the story is with jar: URI usage on android. Nick, can you > help with that? I can try. We should get snorp and jchen to comment too; adding NIs. How is jar:jar used, and does gecko resolve it or does > android java code do so, or something else? jar:jar is used to load resources from out of the Android omnijar from Java, so we definitely resolve jar:jar in Java code; but it's all done with Java ZipReader instances, so it doesn't see these issues. I see very few clear jar:jar references that Gecko would resolve directly, but you can see where we've used jar:jar explicitly at https://searchfox.org/mozilla-central/source/mobile/android/components/BrowserCLH.js#22-36. More below. In particular, do we ever load > jar:<anything> as a toplevel document in the browser content or as an > image/resource that we then need access to (as opposed to e.g. a script file > reference, or loading the same content via chrome:// or resource:// URIs)? The explicit usage above is _always_ via resource://android/, so maybe that already solves your problem. And you can see that there just aren't that many uses in our tree: https://searchfox.org/mozilla-central/search?q=resource%3A%2F%2Fandroid&path= but that _most_ of them are images; and that none of them are toplevel anythings. Now, I expect resource://android to be much more important in GeckoView, since it allows to pull things out of the Android assets folder in the APK, and that's how GeckoView consumers will bundle HTML/CSS/JS. (That is, they definitely won't load assets from an omnijar since they won't be building an App-specific omnijar at all.) However, I can't find the code that does this in geckoview anymore! Perhaps the world has moved on and I'm unaware.
Yeah Nick is right. Looks like inside Gecko, we only load jar:jar: indirectly via resource: or chrome:, so it shouldn't be affected by this bug.
You need to log in before you can comment on or make changes to this bug.