Img tags can't reference chrome in the release candidate

[rjb]

My extension, aardvark, adds some stuff to the dom of the current
page, including a couple images, which have chrome urls (e.g.
chrome://aardvark/content/imagename.gif )

This has worked great, but the release candidate which I downloaded
last night broke this functionality.

It seems to be related to this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=292789
I do not know if there are workarounds, of if this is a new bug that
will be fixed, or what.

One thing I could do to solve the problem is to simply reference an
image served by my web host. This is how it works on the bookmarklet
version of the extension, which shares the same code and works on non-
firefox browsers. I don't mind the bandwidth (my host gives me ungodly
amounts of bandwidth, and these images are tiny), but I am concerned
that mozilla will not approve an extension that does this, because in
theory i can sort of "track" people (i will see logs entries of
everyone who uses the extension, including the referrer address which
would mean i can tell what page they are on when they use aardvark). I
have no interest in knowing this info, of course, but I wonder if
mozilla would reject the update to the extension for this reason. Any
thoughts?

(aardvark is at http://karmatics.com/aardvark/ , and you can see how
it uses images -- without actually installing it -- if you click "run
the demo")

Thanks for any advice....

[alta88[nntp]]

i didn't edit the forum comment fast enough ; )

look at comment #97 in the bug, there's a solution with a new keyword in
your chrome.manifest file..

[rjb]

Sweet! Thanks so much.....

[arc]

On May 17, 4:26 pm, "alta88[nntp]" <alt...@gmail.com> wrote:
> i didn't edit the forum comment fast enough ; )
>
> look at comment #97 in the bug, there's a solution with a new keyword in
> your chrome.manifest file..
>

Many thanks for this pointer. Here's some gotchas I ran into to make
that hint work:

- For the existing 'content' area in the manifest, just appending the
'contentaccessible=yes' to the line worked;
- for the 'skin' area, just appending *did not* work, presumably due
to the 'classic/1.0' extra field. Thus, I had to add an extra line.
The end result loked like this (ignoring the locale and overlay
lines):

content myextension jar:chrome/myextension.jar!/content/
myextension/ contentaccessible=yes

skin myextension classic/1.0 jar:chrome/myextension.jar!/
skin/classic/myextension/
skin myextension jar:chrome/myextension.jar!/skin/classic/
myextension/ contentaccessible=yes

[arc]

On May 18, 9:10 am, arc <tony.cassan...@gmail.com> wrote:

Correction on the previous notes: that scheme doesn't work in pre-3.0.
You need to have two seprate lines for both the content and skin
areas:

e.g.,

[Neil]

arc wrote:

> - For the existing 'content' area in the manifest, just appending the
>'contentaccessible=yes' to the line worked;
> - for the 'skin' area, just appending *did not* work
>

contentaccessible=yes applies to both content and skin, although you
only declare it on the content line.

--
Warning: May contain traces of nuts.