Over the weekend, code landed to restrict the ability of web content to access “chrome://” resources (see bug 292789). This shouldn’t affect many extensions since the restrictions are focused on web content, not chrome content. However, if your extension injects content into the web content, you could be affected. An example can be found in bug 428848. Venkman can’t load venkman-source.css, a stylesheet that is injected into unprivileged, web content.
The solution to this problem is a new chrome manifest flag – contentaccessible. Using contentaccessible, an extension author can say “Yes, I’d like my extension’s chrome package to be accessible to web content.”
Note, in bug 292789, that chrome://global and chrome://browser packages are exposed to content by default. This is required to keep remote XUL (XUL loaded into web content) working.
See Wladimir Palant’s post on this topic too.
Forgive me because I’m cranky from lack of sleep. Why did this change wait until so late in development? Seems like big things like this (things that affect extensions a lot) should have been done long before there was a huge push for extension developers to get their extensions compatible with FF3.
Should I be able to load local chrome: from my remotely sourced chrome by marking the local chrome as “contentaccessible”? I’m getting an error “Security Error: Content at http://localhost:8080/Portal/faces/login.jspx may not load data from chrome://desktop/content/desktopNavigation.xul.” when I try this. I am loading my “remote” XUL in a whose type has been set to “chrome”. This is all being done in a XULRunner application whose audience is solely inside our Firewall. Login.jspx returns the proper content type marking this as a XUL page.