Thanks a lot for the extensive answer, it's rather enlightening!
Boris Zbarsky wrote: > > Right. You can't link to chrome:// in general. This was always the > case. There were some cases where chrome:// resources could be used in > and the like; the change here was to only allow this if > contentaccessible=yes. > > It sounds like you're using <iframe src="chrome://bar.xul"> or some > such? That wasn't allowed in Gecko 1.7, as I recall... > Well... there is a .xul document which is calling a function when loaded. This function calls a custom service, which is fetching the data from the remote server. It is given the current frame as a parameter (which is a custom implementation of nsITreeViewClone). I still have to understand all details myself, to be honest. Boris Zbarsky wrote: > > Yes. You can change things so that you're not loading chrome:// from > web-accessible content, or so that the content you're loading chrome:// > from is not accessible to everyone... I can't speak to what this means > in terms of the design of your protocol setup (maybe you need two > different protocols?) > What does it means in practice: "the content you're loading chrome:// from is not accessible to everyone"? Two different protocols are probably not feasible at this stage because it will mean that the server-side part will also have to be changed, so the things will be made more complex, not less. -- View this message in context: http://www.nabble.com/nsScriptSecurityManager-and-a-custom-protocol-tp22227469p22243524.html Sent from the Mozilla - Embedding mailing list archive at Nabble.com. _______________________________________________ dev-embedding mailing list [email protected] https://lists.mozilla.org/listinfo/dev-embedding
