It appears that frame scripts loaded with nsIChromeFrameMessageManager.loadFrameScript(), like properties files (bug 719376), are cached until the end of time. However, in this case, I don't see a way to manually clear them. (if there is one, please tell me) This means that a restartless addon cannot fully update without a restart if it has any frame scripts. It looks like the same hack used with properties files (bug 719376 comment 0) works here too. But again, there's no way I see to clear this cache, so unlike in that instance, each version will be cached indefinitely. Can someone please just properly manage these two caches and evict all entries from chrome mappings that are torn down on restartless addon disable? It is insane that Mozilla wants addons to be restartless but doesn't implement the basics to make sure that actually works. It's really annoying to waste half an hour trying to debug an issue to eventually just discover another bug about bad caching is causing everything. Attached is my test extension to test what things are cached past an addon update. To use, drop the first XPI file into an open window, note the info in the popup, then drop the second XPI in and note its info popup. (or #2 then #1) Tested on Linux & WinXP. Tested in 17 ESR & nightly. Note that this is not strictly an e10s issue. The message manager and frame scripts are available without it and should work always. However, if it doesn't work reliably, then of course you wouldn't want to use e10s.
Blake, do you know anything about this?
Not entirely sure what the best product/component for this is.
Component: Add-ons Manager → DOM: Content Processes
Product: Toolkit → Core
This is definitely a bug. Nominating for tracking/triage.
tracking-e10s: --- → ?
I did release Flagfox 5.0.6 with a hack around this, by the way. Paths have "?" + addon start time appended to the end, so they're cached during that session but not after update. This is better than just using a random token as that would just cache loads of the same file on each use. (not an issue for properties files if you cache a ref yourself and only load once, but that's not doable with frame scripts) So for Flagfox, at least, there's only an extra cached file per update (if the relevant feature is used). Other addons that don't work around this will of course just break if the file is changed between restartless updates.
This bug is listed on MDN's list known e10s issues affecting add-ons: https://developer.mozilla.org/en-US/Add-ons/Working_with_multiprocess_Firefox When this bug is fixed, we should remember to update that page!
I created Bug 1061285, which is a related but more general issue with content scripts, the solution of which would probably also solve this caching issue.
Would this bug only cover the bootstrap addons due the not necessary restarts? If the frame script is not longer necessary, I would prefer a method for unloading unused frame scripts on demand. For example if the url does a change and the code is not responsible for the new page we hold still the frame scripts in memory. For global message messenger this is likely ok, but for browser message manager, where we attach the frame scripts to a tab this seems to be unnecessary.
For efficient and reliable use of frame scripts by non-SDK extensions, I guess one of the following needs to be implemented: 1) unloading of frame scripts, 2) prevention of loading frame scripts multiple times, or 3) persistence of properties or attributes on dragged tabs such that chrome-side flags can be used to keep track of script loading.
ff 46 x86: bug present (frame scripts cached) ff 48 de x64 e10s=on: bug fixed ff 48 de x64 e10s=off: bug fixed
Michelle - can your team test the attached test extension based on the "user story" - for successful restartless install. comment 13 sounds like it may have been fixed by platform in 48. so maybe test against aurora or dev edition (49 & 50) since it should work if it did in 48
QA Confirmation: We have tested Mac 10.11, Windows XP, 7 & 10 and Ubuntu 14.04 on the Nightly, Aurora & Beta Channels. We still see a mismatch in the Restartless Window when there is no restart in-between the install. "File versions are ALL GOOD" "File versions are NOT CONSISTENT" However if you install the one of the XPI and restart Firefox, then install the other XPI, the messages will match with "File Versions are ALL GOOD"
Hi Blake, based on the QA testing results (in comment 15) it sounds like this is still an issue for restartless add-ons across e10s and non-e10s.
Andy, how much work are we putting into bootstrapped add-ons these days? Should we be working on these bugs or should add-ons be moving to webextensions instead?
Flags: needinfo?(mrbkap) → needinfo?(amckay)
(In reply to Blake Kaplan (:mrbkap) from comment #17) > Andy, how much work are we putting into bootstrapped add-ons these days? > Should we be working on these bugs or should add-ons be moving to > webextensions instead? We hope everyone would move to webextensions. If a contributor wants to fix this, I'm pretty sure the module owner would welcome the patch though.
(In reply to Andy McKay [:andym] from comment #18) > We hope everyone would move to webextensions. Hope, but very unlikely to happen any time soon. Please don't contemplate abandoning bugs for a new API. Old addons and versions of Firefox don't magically go away when you get new stuff. (we wish they'd do so, but they very much don't) I should point out, however, this is never just about 3rd party addons. If Firefox were to deploy a hotfix addon that needed this, they'd hit the same problems. (not sure how that'd come up, though)
You need to log in before you can comment on or make changes to this bug.