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?
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).
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?
I am not a Mac user 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.
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.
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.