Extension-origin XMLHttpRequest Fails After Publishing

Add-ons Development
#1

I recently (as in, this past week) ported a Chrome extension over to Firefox’s WebExtension API, and all said, it’s been a lot less painful than I had expected. Everything seemed to work, and I was looking forward to getting a beta version out to users. I uploaded the add-on to AMO, installed it from there, and… it doesn’t work.

After some digging, it looks like I’m having a really strange issue with XMLHttpRequests from background & content scripts. Essentially, I have a few configuration JSON files stored locally in my add-on which I’m trying to retrieve via a GET Ajax request - almost exactly like what’s described here, though of course in Firefox: https://developer.chrome.com/apps/xhr#extension-origin

This works exactly as expected when I load my add-on as a temporary WebExtension, and it works in Chrome, but fails with an XHR status 0 once the add-on is packaged and signed through AMO. Unfortunately, status 0 and status text “error” are all the information I get from the XHR object, and there’s no error logged to the console, and the other information fields on the object are empty.

Again, the code in both cases is exactly the same; I can download the packaged extension from AMO, unzip it, and load it as a temporary extension, and it works. Firefox must be doing something different - possibly regarding the extension origin, hence status 0 - between temporary and packaged extensions. Any thoughts on how I can work around this, or get it submitted as a bug if it is one?

Thanks!

#2

It is definitely possible to do what you describe in published extensions. What is your exact code for the XHRs?

#3

Just needed a weekend break, I guess - I figured out the problem in about five minutes this morning. Turns out my filename is capitalized (“Config.json”) whereas I was requesting a lowercase name in the code (“config.json”). It’s still strange that it works lowercase when unsigned but has to match exactly once signed… but at least I’ve got it working now. Thanks!

#4

Are you developing on Windows?
In Windows, filenames are case-insensitive. All / most other operating systems handle them case sensitive, and so do browsers with URLs.
I’d always use lowercased names for all files and folders.

#5

I am indeed developing on Windows. Naturally I make sure the case matches, but this one slipped through, mostly because it did work fine when sideloaded. I’ve created a very simple unlisted extension to demonstrate the point, but obviously I can’t attach it here… in short, at least on Windows, it’s case-insensitive when unsigned but case-sensitive once signed.