Just noticed the misspelling and that the preference is being reset on successful elevation on Windows. Now that Windows behaves as Mac OS X where we prompt the user to download an update after X number of cancellations this is important.
That is actually a valid spelling so let's not bother rename it unless it is dirt simple.
Summary: Rename app.update.cancelations to app.update.cancellations and reset it on successful elevation → Reset app.update.cancelations on successful elevation
I *think* this only affects Windows
Can you clarify this a bit more? I'm not sure I understand. I see that we're incrementing the cancelations pref on every elevation failure, and only resetting it on non-elevation failures (i.e., not on elevation success), but this pref only seems to be used for telemetry. Am I missing something? We use the app.update.elevate.attempts pref to control the doorhanger (this pref should probably just merge with the cancelations pref - I'm not sure why I introduced it in the first place.)
This isn't directly due to your patch... it has to do with the new UI handling this pref the same way as OS X is handled. I'll take this bug since I'm familiar with the code paths and I might want to tweak it some.
Assignee: nobody → robert.strong.bugs
Status: NEW → ASSIGNED
Attachment #8874714 - Flags: review?(mhowell) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/9948661fdb33 Reset app.update.cancelations after a successful update. r=mhowell
You need to log in before you can comment on or make changes to this bug.