564244 - The SDK should be able to ship files on chrome:// URLs

Status: RESOLVED WONTFIX

(Add-on SDK Graveyard :: General, defect)

Description

[:Felipe Gomes (needinfo for replies!)]

I just saw bug 549319 but I think this one is a bit different and perhaps more specific.

The SDK itself (or, jetpack-core, I don't know.. but not necessarily addons that use the SDK) should be able to have some files to be used from chrome URLs (and ideally they would be unforgeable).  For example:

chrome://my-first-package-jetpack-core-files/content/file.xul

The file would have to exist both when running cfx test, cfx run, or when bundling the XPI.  I don't have much idea at the moment on how hard this would be.

The initial use case is as described here: http://groups.google.com/group/mozilla-labs-jetpack/t/1503a59d5c5f9a53

Comment 1

[Atul Varma [:atul]]

This would basically require platform work, because AFAIK chrome:// URIs can't be removed at runtime, which would need to be done when the addon was disabled/uninstalled.  This is the main reason the XPIs created by the SDK don't include any kind of chrome manifest or chrome URIs. :(

Comment 2

[:Felipe Gomes (needinfo for replies!)]

Hmmm :/  Ok..
does this mean that restartless addons can't have chrome:// URIs?

Comment 3

[Dietrich Ayala (:dietrich)]

doesn't seem like removal shouldn't be a problem really. register the content dir at add-on startup. while the addon is active, URIs using that content dir resolve. when it's not, they don't.

Comment 4

[Atul Varma [:atul]]

Yeah, until what Dietrich mentioned in comment 3 is added to the platform, I don't believe it's possible.

Aside from deregistering the chrome URIs, the platform may also need to reverse the effects of JS_FlagScriptFilenamePrefix() that it likely associated w/ the chrome dir when registering the chrome URI.

Comment 5

[Dietrich Ayala (:dietrich)]

Ah, I misunderstood then. In comment #1 you only mentioned that *removal* is not possible. I didn't realize that adding content dirs is also not possible.

Comment 6

[Dietrich Ayala (:dietrich)]

Felipe, it's sounding even more like we need to have someone on platform implement proper window hiding for this.

Comment 7

[Dietrich Ayala (:dietrich)]

felipe found a workaround, and filed a bug for proper platform support for what we need.

Comment 8

[Myk Melez [:myk] [@mykmelez]]

The Add-on SDK is no longer a Mozilla Labs experiment and has become a big enough project to warrant its own Bugzilla product, so the "Add-on SDK" product has been created for it, and I am moving its bugs to that product.

To filter bugmail related to this change, filter on the word "looptid".