1307563 - Reconcile System Add-ons and "Check for updates, but let me choose whether to install them" option

Status: RESOLVED INVALID

(Toolkit :: Add-ons Manager, defect, P3)

Description

[:Felipe Gomes (needinfo for replies!)]

There's a catch 22 problem with System Addon updates and the "Check for updates, but let me choose whether to install them" option.

If the "install updates automatically" option is not chosen, a system addon update check will not happen, because they are installed automatically and there's no UI to present to the user (by design?)

But that means that a user who opts out of automatic updates is still able to trigger a Firefox update, but not a system add-on update.


A solution is not straightforward, and it will probably require policy and code changes. But it's worth looking into.

Comment 1

[:shell escalante]

Hi Guys - Until at least November - the system add-on will be able to keep add-ons that we find have issues with e10s, in a non-e10s mode.  This is a great theory - since we can block add-ons causing issues as we find them without requiring an update... except for the issue Felipe pointed out.  

47% of users are not getting the system add-on updates.

Is this a complex technical thing to do?  Or is it simple technically, if we figure out the UX/Policy changes needed?

Comment 2

[Robert Helmer [:rhelmer]]

(In reply to :shell escalante from comment #1)
> Hi Guys - Until at least November - the system add-on will be able to keep
> add-ons that we find have issues with e10s, in a non-e10s mode.  This is a
> great theory - since we can block add-ons causing issues as we find them
> without requiring an update... except for the issue Felipe pointed out.  
> 
> 47% of users are not getting the system add-on updates.

I've started tracking this in a regularly-updated Telemetry dashboard, and we're going to verify this by pushing an update in bug 1307553.

Also - restartless system add-ons are riding the trains now, so it will be interesting to see if this increases uptake too.

> Is this a complex technical thing to do?  Or is it simple technically, if we
> figure out the UX/Policy changes needed?


I don't think the coding side should be too hard, if we're just honoring the pref and keeping the existing updat mechanism.

Comment 3

[Andrew Swan [:aswan]]

This bug has been open for a while, sorry for not looking at it sooner.  Has anybody manually test that this is an issue?  From inspecting the code, system add-on updates happen from here:
http://searchfox.org/mozilla-central/rev/c477aa8bd99278962998adba1c5e4b15a02c42c7/toolkit/mozapps/extensions/internal/XPIProvider.jsm#3061
But the code there doesn't appear to consult the autoUpdate preferenes.  That happens for background addon updates here:
http://searchfox.org/mozilla-central/rev/c477aa8bd99278962998adba1c5e4b15a02c42c7/toolkit/mozapps/extensions/internal/XPIProvider.jsm#3061
But system add-on updates don't (only?) go through that code path.

* - the only remark is due to the fact that we don't appear to filter system add-ons out of the regular background update check.  Ugh.

Comment 4

[Andrew Swan [:aswan]]

Whoops, self follow-up, we do filter system add-ons out of regular background update checks by not setting PERM_CAN_UPGRADE on system add-ons here:
http://searchfox.org/mozilla-central/rev/c477aa8bd99278962998adba1c5e4b15a02c42c7/toolkit/mozapps/extensions/internal/XPIProvider.jsm#7169-7172

But the main comment from above still applies, I don't think the system add-on update check references the preference that disables automatic application of updates, so I think this bug is invalid?

Comment 5

[:Felipe Gomes (needinfo for replies!)]

Not invalid, I believe. AIUI this is what triggers the update check, which is conditioned to both app.update.enabled and app.update.auto:

http://searchfox.org/mozilla-central/rev/790b2cb423ea1ecb5746722d51633caec9bab95a/toolkit/mozapps/extensions/AddonManager.jsm#1540

Comment 6

[Andrew Swan [:aswan]]

Ah, I thought you were referring to the preferences that govern whether add-on updates get applied, not the similar preferences that apply to the application itself.  Carry on...

Comment 7

[:shell escalante]

Is there something blocking doing this fix/ who would do it?  I know rob is measuring in bug 1307568 - but this Sounds like a known area that is stopping system add-on updates.   this is a blocker for expanding add-ons/e10s in Fx52 (high visibility). system add-on updates are our best failsafe to stop enabling e10s with an add-on, when stuff goes wrong in Release, but right now the reach is too limited.

Comment 8

[Robert Helmer [:rhelmer]]

This shouldn't be blocking system add-on updates - it's about giving users control over whether they happen or not via the "application update" pref.

Right now there isn't a user-visible way to disable system add-on updates.

Comment 9

[Andrew Swan [:aswan]]

I think that the only thing blocking here is agreeing on what the behavior should be.  This is like bug 1307553 without the "If app.update.auto is set to true" clause which changes the impact greatly.
I think the desired behavior is (bear with me here): If updates are enabled and the user opens About, and there is no app update available, then check for system add-on updates.  If there are system add-on updates, then indicate that in the About window and give the user the opportunity to apply them.
The biggest chunk of work to implement that would be introducing that "wait for the user to accept them" step into the system add-on update process.  If we wanted to relax that and just apply the updates right away without user intervention, it would be very easy, but that seems like inconsistent behavior that would be difficult to explain and rationalize.

Comment 10

[Robert Helmer [:rhelmer]]

Andrew and I just chatted in IRC - he's right this one actually would prevent updates, if users have this setting:

http://searchfox.org/mozilla-central/source/toolkit/mozapps/extensions/AddonManager.jsm#1570-1576

I don't know how prevalent this setting is, we should see if it gets sent in the telemetry environment data.

Comment 11

[:shell escalante]

dropping priority unless data analysis shows are root cause.  believe it's under 1% that have this pref set.

Comment 12

[David Durst [:ddurst]]

I'm confused by the course of some of these comments, so I wanted to clarify one thing:

If the user disables updates (so, sets their pref to anything but automatically update), they effectively block updates to Firefox and system add-ons (and hotfixes, etc). If a user disables updates for Firefox and does not manually check for them, they do not get updates.

AIUI, this is the original purpose of this bug. The problem presented is that when a user has disabled updates to Firefox, while we may be able to deliver updates to system add-ons that are *already* present, we cannot push *new* system add-ons to any users who have elected to not get updates to Firefox.

So to put this concern in a different light:

User X sets their browser to not automatically update. Mozilla is unable to push any kind of new patch to that user. This is not the end of the world, because the user has (arguably) opted out, but we are thusly prevented from two things:
1) changing (via system add-on) any prefs that would/could toggle newly-released features;
2) changing (via system add-on) anything that we deem a security necessity (i.e. not a feature, but a criticality prior to a point release, which the user would be unable to receive anyway because they're set to not get updates to Firefox).

Unless I'm misunderstanding, the concern here is that tying the ability to push system add-ons (not just update existing ones) to the same pref that the user sets to govern updates to Firefox makes it so that we are unable to deploy an emergency fix to some users.

It may be a small percentage, but when I think about immediately mitigating a zero day issue, it seems like we should be able to separate our prefs for system add-ons and updates into categories: A is for a new version of Firefox, B is for changes to features/settings/prefs, and C is something the user cannot control that we should be able to do (even if it is merely a flavor of B, where we toggle a pref).

Please tell me I'm overthinking this?

Comment 13

[Robert Helmer [:rhelmer]]

I agree with David's summary of the problem - solving this bug would be really great, but it's not a top priority for anybody at the moment. We're basing that priority on the fact that a very tiny fraction of users actually disables this pref (under 1% per comment 11)

Additionally - the original "hotfix" add-on system has always had the same behavior we're seeing here with system add-ons updates, so not being able to push a hotfix to these users is not new. I still think it's worth doing, it's just a matter of having someone to work on it.

Everyone is focused almost exclusively on the 57 release at the moment, once that lets up we should be able to bump up the priority on this. I'd be happy to help mentor/review someone wants to tackle it earlier.

Comment 14

[Andrew Swan [:aswan]]

What you propose is possible but I think it would ideally be covered by a different bug, this one covers the fact that users who have disabled automatic updates have a way to manually apply full application updates but do not have a way to manually apply system add-on changes (which could be adding a new system add-on or update one or more that are already present).

Your proposal doesn't sound unreasonable but note that (if/when we fix the bug just described) we're no worse off with system add-ons than we are with regular updates.  That is, if there's a major vulnerability that requires a chemspill since it can't be fixed from an add-on, we can't get the update out to users who have turned off automatic update checking.

Comment 15

[Robert Helmer [:rhelmer]]

If we're doing bug 1428459 then we don't really need this one.