I have just updated an extension of mine, tested it with web-ext and everything worked fine.
So I uploaded it to the beta channel on AMO and downloaded the signed file it into my main browser.
Aaaand – it didn’t work.
By setting breakpoints I figured out that the content scripts are not loaded in the order they are listed in the manifest.json.
The very strange thing is, if I sideload the very same file I uploaded to AMO (still unsigned) it works correctly.
I have reproduced this with a bunch on profiles with FF52 x64 on Win10.
With the signed file, the load order of the content scripts is messed up (and the manifest.json is ok).
Hmm, nevermind. I didn’t solve this problem but I now circumvent it by using executeScript from webNavigation handlers. That works. (not in fennec, there I’ll just have to wait for the tabs API)
We shouldn’t need this work around. I couldn’t find the bug topic but I remember it was fixed. I’ll post back, this issue will be in the back of my mind lol
I admit that I do weird stuff in the extension where this occurs. I basically load a require script first, which looks at the stack trace of a second script to dynamically load relatively referenced scripts via tab.executeScript().
Unfortunately the stacktraces vary depending not only on the method used to load the script (content_script vs executeScript) but also on the way the extension is loaded ( “normal” vs sideloaded via about:debugging). Therefore it is probably better to always use executeScript in the first place).
I think the stack traces changed in FF52. For non-sideloaded extensions they seem to include the entire path to the packed extension in the profile folder (*).
Anyway. Even if I am loading scripts twice that way, it still doesn’t explain how the “second script” can hit it’s first breakpoint before the “require script” does.
(*) If that is actually true it would also leak some sensitive user info that WebExtensions should not be able to access. I should probably check this again.