1051238 - frame scripts are cached forever & thus can't be updated restartless

Status: RESOLVED WONTFIX

(Core :: DOM: Content Processes, defect, P5)

Description

[Dave Garrett]

Attachment: test extensions.zip

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.

Comment 1

[Dave Townsend [:mossop]]

Blake, do you know anything about this?

Comment 2

[Dave Garrett]

Not entirely sure what the best product/component for this is.

Comment 3

[Blake Kaplan (:mrbkap) (inactive)]

This is definitely a bug. Nominating for tracking/triage.

Comment 4

[Dave Garrett]

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.

Comment 5

[Chris Peterson [:cpeterson]]

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!

Comment 6

[Peter J. Sloetjes]

Taking bug 968541 into account as well leads to the conclusion that Mozilla has never taken bootstrapped add-on development for Firefox desktop very seriously. There must be some developers around who still know the initiate-propagate-terminate-pattern, given its ubiquity in all of physics and computing?

Comment 7

[Peter J. Sloetjes]

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.

Comment 8

[TheRave]

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.

Comment 9

[Peter J. Sloetjes]

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.

Comment 11

[Dave Garrett]

(In reply to Peter J. Sloetjes from comment #10)
I've read comment 10 a couple times and can't figure out what you're even saying. Don't post junk like this here.

Comment 12

[TheRave]

Maybe a hacked account?

I couldnt find this bug in milestone list?

Comment 13

[CoolCmd]

ff 46 x86: bug present (frame scripts cached)
ff 48 de x64 e10s=on: bug fixed
ff 48 de x64 e10s=off: bug fixed

Comment 14

[:shell escalante]

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

Comment 15

[Michelle Funches - QA]

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"

Comment 16

[:shell escalante]

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.

Comment 17

[Blake Kaplan (:mrbkap) (inactive)]

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?

Comment 18

[Andy McKay]

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

Comment 19

[Dave Garrett]

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

Comment 20

[Olli Pettay [:smaug][[e-mail]]]

Frame scripts are going away and are exposed to FF internal code only.