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
Created attachment 8874714 [details] [diff] [review] patch rev1
Attachment #8874714 - Flags: review?(mhowell)
Attachment #8874714 - Flags: review?(mhowell) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/9948661fdb33 Reset app.update.cancelations after a successful update. r=mhowell
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
status-firefox55: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
You need to log in before you can comment on or make changes to this bug.