Load local files (images and or CSS) in SDK add-on

Add-ons Development
#1

In my extension Bookmark Dial (https://addons.mozilla.org/en-US/firefox/addon/bookmark-dial/), I replace the homepage with a speed dial page(https://github.com/sblask/firefox-bookmark-dial/blob/master/data/dial.html#L7) using a PageMod(https://github.com/sblask/firefox-bookmark-dial/blob/master/index.js#L77). While developing, I was struggling to get a local CSS file loaded. The thing that worked was reading the file manually and send the string(https://github.com/sblask/firefox-bookmark-dial/blob/master/index.js#L73) and replace the content of the style tag(https://github.com/sblask/firefox-bookmark-dial/blob/master/data/dial.js#L109). Now I got a feature request of someone who wants to change the background image. I could obviously do the same thing, read the image manually and send a data URL(this is what I do with the thumbnail images that I currently store in simple storage, but I think itā€™s what makes it kind of slow).

The question being: is there really no better way? I tried setting the background in the inspector, but url(ā€˜file:////home/sebastian/Desktop/test.jpgā€™) doesnā€™t work. The tooltip says ā€œCould not load imageā€ but when I click to open ā€œfile:////home/sebastian/Desktop/test.jpgā€, Firefox loads it without a problem. Presumably itā€™s some kind of restriction, but when I can load the file using the file API, I should be able to load in other ways too?

#2

I had some funky issues with loading file uriā€™s as well. But only in latest e10s nightly and on Mac OS X - https://discourse.mozilla-community.org/t/loading-file-uri-as-img-src/6954/4 - I couldnā€™t resolve it, so I am forced to load the pages into the content process for it to work on OS X.

But I think your issue is different.

I think File URIā€™s are definitely the fastest as I donā€™t think they are even cached (it would be weird if it saved local files to another local file storage area).

Can it be a CSP issue? Do you see that warning?

#3

I saw that post but thought that it doesnā€™t sound like my problem.

I am indeed getting an error(I always forget checking the browser console):
Security Error: Content at resource://bookmarkdial-at-sblask/data/dial.html may not load or link to file:///home/sebastian/Desktop/test.jpg

I checked how the FastDial extension does it(not an SDK extension): it just copies over the background image to the profile folder and accesses it through chrome://fastdial-profile/content/themes/current/test.jpg That one it registered in chrome.manifest with ā€œcontent fastdial-profile ā€¦/ā€¦/fastdial/ā€ Is there any way to do something similar in an SDK addon?

#4

I figured it out. It took a while to get it working, but you can still use chrome.manifest. Itā€™s important to have a trailing slash here: https://github.com/sblask/firefox-bookmark-dial/commit/5dbdc9c0cc665ea620d35f4e733bc51fb74818c8#diff-864ea9bc478318c39c4589422d097255R1 and the add-on needs to be unpacked as otherwise the relative path does not work: https://github.com/sblask/firefox-bookmark-dial/commit/5dbdc9c0cc665ea620d35f4e733bc51fb74818c8#diff-b9cfc7f2cdf78a7f4b91a753d10865a2R109

1 Like
#5

Wow very interesting. How about on Mac OS X latestly nightly with e10s enabled?

Edit: ah but this method wonā€™t work on regular local files right? Like ones not contained within the addon?

#6

I am not a Mac user :wink: I also did not check with e10s. There are other things that break then, like creating thumbnails and setting the focus on the location barā€¦

This should work on any regular file. I copy the background image into the Firefox profile folder under my own sub directory. This could potentially be anywhere, you just have to give the right path in the chrome.manifest And again, the trailing slash is important, otherwise weird stuff happens. There is an add-on called Chrome List that letā€™s you check whether you did the right thing.

1 Like
#7

Oh thatā€™s an interesting technique! unpack true does have a reduced perf though no? :frowning:

#8

Actually, it might even cause a speed up. Sure, on installation the xpi has to be unpacked and written to disk, but then on every start the files are already there and donā€™t have to be unpacked anymore and normally they have to. The xpi is tiny though, so not recognizable I guess.

#9

Ah thatā€™s a good point, Iā€™m going to verify that, if itā€™s confirmed Iā€™m unpacking everything :slight_smile:

#10

Unpacking is not recommended for a number of reasons. Performance isnā€™t top of the list, but unpacking does slow things down, and not just the unpacking step. Remember the days of jars? Accessing lots of little (or not so little) files is much slower than accessing one great big file, even several compressed bits of one great big file.

The unpack flag still exists for legacy reasons but there really are very few reasons to ever need it now. Even the SDK can use a chrome manifest to define chrome URLs and access files from directly inside the xpi.

Sounds like youā€™re mis-using this feature to hack round another addressing problem. There are known issues with accessing local (non-chrome) files from the content process. Possibly some not-so-known issues also. There are certainly mac-specific issues, but also more general problems. On the whole the direction is towards more restrictions on accessing files from the content process. That might ultimately solve your problems by properly redirecting file access to the chrome process where it works properly. Or it might just break your addon completely.

It is probably better to raise these issues in Bugzilla than spend hours putting together hacks that are poor practice or will break with the next bug fix. If nothing else, someone might dupe it to an existing bug and youā€™ll know where to watch for news.

1 Like
#11

Fair enough, created a bug here: https://bugzilla.mozilla.org/show_bug.cgi?id=1249154