350636 - "Never" decision by the user for a major update should not impact a minor update to the same version

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect)

Description

[(not reading, please use [e-mail] instead)]

Note, this isn't an issue with minor releases, unless of course we push version "x.y" as a major update, the user says "never" to version x.y, and then later we push "x.y" as a minor release.  I'm assuming we'd never do that, but I can also avoid accidentally applying a "never" decision to a minor release by doing this:

  var neverPrefName = PREF_UPDATE_NEVER_BRANCH + update.version;
  var never = getPref("getBoolPref", neverPrefName, false);
- if (never)
+ if (never && update.type == "major")
     return;

I think this (low risk, defensive) change might be worth taking on the branch (but drivers may feel otherwise).

Comment 1

[Jesse Ruderman]

I can imagine Firefox 2.0.0 changing from being a "major update" to being a "major + security update" when we drop support for Firefox 1.5.0.x.  Do we support something like that?

Comment 2

[Mike Schroepfer]

This would happen with a new releaese of 2.0.0.x (likely 2.0.0.3 or .4) - so as long as we can advertise that new version as a minor update the 1.5.0.x we should be fine even if someone clicked never.  Is that right Seth?  Either way this patch seems reasonable.


(In reply to comment #1)
> I can imagine Firefox 2.0.0 changing from being a "major update" to being a
> "major + security update" when we drop support for Firefox 1.5.0.x.  Do we
> support something like that?
> 

Comment 3

[Jesse Ruderman]

But 1.5.0.x to 2.0.0.3 is not "minor".  It's "major + security".  IMO the client side of the updater should know about both "minor vs. major" and "security vs. not security", at least if knowing about both is necessary for showing accurate and reasonably precise text to users.

Comment 4

[(not reading, please use [e-mail] instead)]

for the 1.5.0.x -> 2.0.0.y migration, I would think that would always be advertised from aus as a "major" update.  (For a 2.0.0.x users, 2.0.0.y would be advertised from aus as a "minor" update.)

your comments and discussion point out a real world scenario that validates why we want this one line fix.

I have both 1.5.0.x and 2.0.0.x on my machine, and I use both (with the same profile.)  We decide that 2.0.0.y is solid enough to advertise to 1.5.0.x users, so we advertise this major update, and the user declines, so we store "app.update.never.2.0.0.y" = true;

then, I switch back to 2.0.0.x, and 2.0.0.y is advertised as a minor update (but a critical one, for security reasons).

but we have stored a never decision for 2.0.0.y in this profile, so the current code, as is, will not get that minor update.

it's an edge case, but worth fixing.  But I'm sure we can think of other real world scenarios where similar things can happen.

I'll whip up the one liner (for trunk and branch, and test it of course.)

Comment 5

[(not reading, please use [e-mail] instead)]

Attachment: simple patch

Comment 6

[(not reading, please use [e-mail] instead)]

I've tested out this one liner, and now, even if the user has said "never" to a major update for version x.y, that decision will not affect a minor update for version x.y

I think we want this on the branch

Comment 7

[Robert Strong (they/them - no direct email)]

Comment on attachment 236500 [details] [diff] [review]
simple patch

r=me

Are there other cases that should be fixed besides this? Is so, please file bug(s) for them.

Comment 8

[(not reading, please use [e-mail] instead)]

fixed on trunk

Comment 9

[Mike Connor [:mconnor]]

Comment on attachment 236500 [details] [diff] [review]
simple patch

a=mconnor on behalf of drivers for 1.8 branch checkin

Comment 10

[(not reading, please use [e-mail] instead)]

landed on the MOZILLA_1_8_BRANCH as well.