Closed Bug 628089 Opened 13 years ago Closed 10 years ago

Remote XUL blocked for resource: URIs


(Core :: XUL, defect)

Windows 7
Not set





(Reporter: KWierso, Unassigned)



Following the information at this URL, I tried to add an optionsURL entry for my Addon SDK-built extension's install.rdf:

That post shows how to generate resource URIs for files in your extension. Everything's working up to this point. The URIs are being generated, and seem to be used when called upon. But when I tried to add an XUL file for a preference window in the optionsURL spot, I get the "Remote XUL is disabled and really really unsafe" warning, instead of seeing the pref window.

Talking to mfinkle on IRC, this apparently works just fine on Fennec, because "we load the UI differently than Fx".

This isn't just an issue with the dynamic generation of the resource URIs in the SDK, as I then tried modifying an XUL-based extension to use a resource URI, and it too gives me the warning.

On this page ( ), I see this note about registering resource URIs: 
"Note that there are no security restrictions preventing web content from including content at resource: URIs, so take care what you make visible there."

Was disabling remote XUL from resource URIs intentional?

Using the Remote XUL Manager extension to modify the whitelist, I can whitelist file URIs, but I don't seem to be able to whitelist resource URIs.
Seems a bug in its own right, doesn't block chrome registration for bootstrapped add-ons at all.
No longer blocks: 564667, 582164
> Was disabling remote XUL from resource URIs intentional?

Fairly so, yes.  It was disabled for all non-system principals, and resource URIs don't have the system principal.
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.