Wrong content_script load order

NilkasG · January 27, 2017, 6:48am

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).

Any ideas what that is? Should I file a bug?

noitidart · January 27, 2017, 7:59am

Not loading in the order of the array was a bug a while ago, but it was supposed to be fixed. I’ll try to dig up that bug.

NilkasG · January 31, 2017, 12:07am

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)

noitidart · January 31, 2017, 12:12am

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

NilkasG · January 31, 2017, 12:29am

Yeah, that’s true.

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.

NilkasG · October 24, 2019, 2:12pm

Yes, stack traces of files in extensions installed from AMO contain the full path to the user profile: