User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5pre) Gecko/20100826 A XUL document referenced using the file protocol is not shown in an iframe anymore. Example code: <iframe src="file:///C:/Temp/test.xul" flex="1"/> This used to work in 20100824. Reproducible: Always

Yes, this was purposeful. XUL is not allowed from random protocols that aren't chrome anymore. See comments in bug 546857.

Wow, that was a fast answer :-) Is there a way to change that behaviour with a pref or in the manifest? We use this in our XULRunner application to load dynamically generated XUL files.

You should be able to set the relevant permission manager stuff to whitelist particular URIs, I think... see the patch in bug 546857, pending this being documented.

When I simply use another extension for my files - eg. "test.xml" instead of "test.xul" - it works again. Note: I've not changed the content which is still XUL and looks like this: <?xml version="1.0" encoding="ISO-8859-1"?> <?xml-stylesheet href="chrome://extensions/content/catalog/catalogWin.css" type="text/css"?> <idacatalogitems xmlns="http://www.birgin.de/ida/there.is.only.ida"><idacatalogitem lastModified="1282840043050" fileSize="26558" src="background.jpg" origWidth="1016" origHeight="662"/> </idacatalogitems> While simply changing the extension is a workaround for me it is very confusing. IMHO this is no real security improvement which was the intention of the referenced bug report.

Well, there's no actual XUL in that file, right? Changing the extension in this case does change the parser used to parse the document, the type of document object generated, and the way the xml-stylesheet PI is handled. So yes, there is security improvement in the sense that those codepaths, which are XUL-specific and not necessarily as robust as the corresponding XML ones, are avoided.

I understand. You are right, there is no original XUL element in there. Just tested it with a <button label="foo"/> included which is not visible but I can style it in my css document and use bindings. Nothing happens when I import some global css files like xul.css or global.css. So this hack will not work.

Are the directory shortcuts known from nsIDirectoryService like "DfltDwnld", "ProfD" etc. available in manifest files to make it possible to declare a chrome URL for the parent directory of the dynamically generated XUL files? This then would make it possible to address the dynamically generated XUL files via chrome URL.