WebExt Update Can Prompt Restart [solved: 56.0.2 + non e10s + legacy+webext mix + a pref we have never mentioned]

[GuardianMajor]

Hello everyone, I was wondering if anyone knew what setting has caused all addon updates to now require a restart, that wasn't the case before.

Let me elaborate slightly, when I updated an addon, say uBlock0 it would update in place and that's that, no need to restart. Now, everyone, including those that never required it are forcing a restart before they update.

I did some digging and anecdotal observation seems to suggest potentially this item:

/* 0304: disable background update staging ***/ user_pref("app.update.staging.enabled", false);

but the description of that seems to not imply it would affect the addons, so I am not entirely sure. The only reason I suspect it, is that now when the addon is requiring a restart, it is holding it in a folder called "staged" so I figured maybe relating to this.

Anyone else experience this and can shed some light? TIA.

[GuardianMajor]

@Thorin-Oakenpants My apologies, that was a boneheaded thing to leave out. I am on Firefox 56.02 x64 on Windows 10 Pro x64.

I'd be happy to provide you all that, give me a few to get to it and I will dump it for you and let you know. Thank you again, I have been at it for a while, another pair of eyes would be greatly appreciated before that dent on the wall becomes a complete hole engulfing my entire head 😁

EDIT: Here you go, I have dumped everything here. Let me know if I can provide anything else, thank you.

[GuardianMajor]

I am not on 52, I am on 56.0.2 not the ESR. I think you didn't read it right.

Yes, there are several legacy, I am not worried about them asking to restart, that's the nature of the beast. And since they are not updated to webext yet, there has not been any updates for them anyway.

I am speaking of the WebExt items, as stated, specifically an example of uBlock0 that never required a restart to update, but now does, behaving like legacy.

[earthlng]

now require a restart, that wasn't the case before.

what does "now" mean? what has changed?

Maybe some of your addons aren't multi-process compatible or the latest version of uBlock Origin uses some features/permissions that your old and outdated Firefox doesn't support and that somehow triggers a restart prompt.

Using a mix of legacy + webextension addons in an outdated Firefox but with new-ish features like e10s and whatnot enabled, I'd say having to restart for addon updates seems like a minor inconvenience and probably the least of your problems.

[GuardianMajor]

@Thorin-Oakenpants No worries, I figures as much, I actually thought on reading your reply that I perhaps typed it wrong, and then I checked it again to make sure I had written it right.

Despite 56's status in the chain of release, it is fully webext capable and in fact has to be forced to accept legacy, although it does it without too much interference. It is not so deprecated in terms of parity with more recent releases to be obsolete or prone to wild issues.

Not really the case with the addons, as stated the legacy always require restart, they are not being updated anymore so no issue and webext don't require restart by their very architecture. And simply removing the user.js restores functionality to them, so I am 100% certain it is a change in the user.js just that I can't figure out which one (or ones combined) are the reason for it. As you can see, going through it ONE BY ONE would be an enormous undertaking and I was hoping that since you guys work with these settings that you would have insight as to which ones might be involved in introducing this behavior.

I don't need anyone to fix it, it is NOT a Firefox issue, as I stated, it has to do with a setting change, I just need to know which one. Proven by removing the user.js and everything works fine, so not something that needs fixing or requiring Mozilla to do anything about it, I think you are entirely focused on the wrong part of the issue as the cause. It is NOT a software issue and as a professional developer, I can guarantee it. I just need to figure out which setting being flipped is triggering the behavior, that's all.

@earthlng Please see my response above, that's not the case and the issue has nothing to do with the addons and are strictly related to some changed setting. I appreciate your other observations and thoughts but not related to the issue at hand and the setup is perfectly secure and functional (albeit with this inconvenience) which is minor at best and can be lived with, just would be nice to know so it can be noted for anyone else who might encounter it. Being able to say in the notes, btw this setting might cause this to happen would just make the list better and serves the userbase, unless that's not our goal here.

To eliminate your concerns with all the legacy, then just install uBlock0 and nothing else and see what happens. That way we can eliminate all the noise about other things.

[GuardianMajor]

Well damn. Why didn't you say so earlier. I just re-read your first couple of posts and found no mention of this, or am I missing something again (just got up, first coffee)?

While I didn't explicitly state that, it was fully implied as this is regarding a user.js and my observations on potential settings that might cause it, sorry I wasn't more explicit about it but did mention that it didn't happen before, now with user.js it happens, so it was implied, anyhow my apologies if I should have been more explicit about it. Sometimes when you are explicit like that it is taken as offensive to the intelligence of the professionals you are communicating with and I was approaching it a bit more matter of factly I thought, my apologies none the less.

You say you suspect app.update.staging.enabled - did you test it?

Yes, of course, it would be foolish to not have done that. But it didn't resolve the issue, so that's why I mentioned, it might be a "collective" if you will of settings that trigger the behavior, not a single flip. Hence why I reached out, which I never do without extensive effort on my part so I have some context to share, as I hoped your exposure and investigation history of these settings would have that insights that I am lacking which would help figure it out. Usually when there is a combination effect that causes an issue it becomes more difficult to diagnose without some insight or brute force (but as you can imagine, when you have multiple settings involved, that brute force becomes quite mutated and elaborate for the myriad of combinations). I can generally speaking eliminate a great number of the settings as an issue because they are just not related enough to be a cause but the remaining items are still quite extensive.

I actually assumed that it might have been something that changed with the addon itself, but I have confirmed with the developer that it is not the case and they are not seeing it and since removing the user.js restores the proper behavior, they would be absolutely correct that it is not the addon versions again that the issue, but the settings. I need to narrow down the settings that need to be reverted to restore functionality and that was the whole point of this endeavor. Testing this behavior as you offered to do initially is quite easy actually.

1. Install Firefox 56.0.2
2. Install uBlock stable (aka say .24)
3. Go to the latest release and click on a newer version (make sure you pick the webext one)
4. It updates in place, voila, done.
5. Close the browser and load the user.js
6. Go back and try with the next release, it will require restart
7. Now here is when we need to figure out which setting is breaking this in place updating and restoring it back to staging (aka requiring restart)

Step 7 is what I need assistance with and was hoping your existing knowledge would accelerate the debugging if you will. I provided a complete snapshot of that profile simply because you asked and I wanted to be fully forthcoming, not to create distraction in what actually needs debugging, their existence is irrelevant to the issue, this much I am confident based on the initial discussion on top of this reply.

If you cannot or don't wish to assist on that, I understand and that's that and I will venture forward on my own but it would be helpful to leverage your understanding of the settings to help if the motivation is present. Thanks.

[earthlng]

It works fine with the latest ghacks-user.js. Must be something you added/changed yourself.

I can generally speaking eliminate a great number of the settings as an issue because they are just not related enough to be a cause but the remaining items are still quite extensive

I ran our prefsCleaner with our user.js against your user.js and this is what remains:

http://pasted.co/2190caa4/fullscreen.php?hash=c2f555e7b01abcf1641594809251ed86&toolbar=true&linenum=false

take your best shot :) gl

[GuardianMajor]

I did not see a request for the prefs.js file, if you made the request, I would have provided it. Certainly if you had asked three times. I appreciate all the effort and thanks @earthlng but yes the settings are not a 100% parity with your user.js but contain a lot of overlap. @Thorin-Oakenpants I appreciate that you created the profile and yes I have been ignoring the GM updates until I can port properly all the existing scripts to the new structure before updating so that I can minimize the down time of debugging but will be finishing that by the end of the week.

Since my last post I had already refactored my user.js sections so that I can easier brute force my way through it. I had to do 3 prefs.js deletes along the way (apparently some settings from user.js DO go into permanent prefs.js, didn't realize that could happen) and finally narrowed it down and figured out which SINGLE item was causing it. And it was NOT one of the ones on your user.js, so that's good news for you guys at least but rather the settings we had agreed on with Mozilla when working on e10s involving force disable of accessibility and force enable of e10s. All of them work fine but it seems due to a session regression (aka disabling sessionstore and such), the setting:

user_pref("browser.tabs.remote.force-enable", true);

forces this behavior and causes the problem. So I have since commented that out and all is fine now. Everything has returned back to normal and updating as usual. I just loaded the latest beta (25rc3) and it installed in place like a champ, no more restart. So thank you again, I guess I was only two days away from figuring it out when I reached out. It's hard to know sometimes, how long you keep banging your head before asking for help, I guess in this case, I know the answer.

[GuardianMajor]

browser.tabs.remote.force-enable may not be in our user.js, BUT... I applied it as true in my test profile, because I appended all your stuff to the end... and I could not replicate your issue

That's odd, as removing that fixes my problem, and putting it back, kills it. I did have to do an extra step, which is to physically remove it from the prefs.js but given what you said next, that would make sense as it would have been left over.

Every pref that is not commented out in the user.js goes into your prefs.js, even if it is the default value - they show as "modified" or "user_set" in about:config (they changed the wording several releases ago) is in prefs.js.

Did they change the behavior on this? According the documentation in the past, the user.js is combined with prefs.js and loaded into the browser and then the prefs.js is restored using the prefs-1.js, I guess my info is outdated, that would explain why some of them seem to persist in the actual prefs.js but that defeats the purpose of the user.js as it would mean that after the first load it becomes unnecessary as it would now be in the prefs.js, right? Or am I misreading this? I was under the impression over the years that user.js doesn't modify the prefs.js file for anything it contains simply overrides what is in prefs.js - good to know that's not the case, so anything I remove from the user.js, I need to sanitize out of the prefs.js now, great.

Oh I read the gist request as my user.js file, not the prefs.js file, that's why I provided that. I guess I missed the context of the reference to the prefs.js sorry about that. Also, I debugged NOT on my primary profile, I created one just to install the test addon in question (uBlock) and then ran the user.js modified in chunks until I hit the restart issue, then I knew which block it was in, then it was just a matter of chunking those I can see which one triggered it and that was the one that consistently triggered it. So then I put the modified user.js file in my primary and still encountered the issue, until I removed the same line from the prefs.js and then reloaded and it was fine now. Hence the reference to the realization that they were sticking behind.

[GuardianMajor]

@gorhill I tried updating that to reflect my findings but the new restrictions makes it impossible for me to comment on my own ticket, so I have been trying to find a way to reach outside the issue tracker. I guess this will make that moot now.

[overdodactyl]

Just an FYI, there is now this community maintained issue tracker for uBO:

https://github.com/uBlockOrigin/uBlock-issues

and similarly for uMatrix:

https://github.com/uBlockOrigin/uMatrix-issues

[GuardianMajor]

@overdodactyl I am fully aware of that but it is no help for updating an existing issue that was still open and needed and update. I am not going to open a fresh issue just to update an existing issue, that make sense?

[overdodactyl]

that make sense?

Sure. It was just an "FYI" that there are now new issue trackers for any future problems.

[gorhill]

My closing comment contains a link to the issue here.

[GuardianMajor]

@overdodactyl I know what you meant, I was just explaining why I felt stuck, since I didn't want to open a new issue for an existing one. Future issues/problems are their own merit.

@gorhill Yes, Raymond, thank you. Best of the worst options I guess, just wish I could have updated it directly without cross repository-jacking it 😞 I had told you that I will dig into it and figure out and when I reached out here and resolved it, came back to report it but alas couldn't. I was going to reach out to you via other channels but @Thorin-Oakenpants was kind enough to link them, so I guess that's as good as we can get. Not the cleanest resolve, but it is what it is and will make due.