Closed
Bug 1154591
Opened 9 years ago
Closed 9 years ago
getCanStageUpdates has incorrect checks for Windows and B2G
Categories
(Toolkit :: Application Update, defect)
Tracking
()
People
(Reporter: robert.strong.bugs, Assigned: robert.strong.bugs)
References
Details
Attachments
(4 files)
1.91 KB,
patch
|
spohl
:
review+
bbondy
:
review+
|
Details | Diff | Splinter Review |
2.20 KB,
patch
|
robert.strong.bugs
:
review+
Sylvestre
:
approval-mozilla-aurora+
Sylvestre
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
1.11 KB,
patch
|
spohl
:
review+
|
Details | Diff | Splinter Review |
2.28 KB,
patch
|
Details | Diff | Splinter Review |
When B2G added staging in bug 764684 the code that was added used the Windows path where it checks if the maintenance service pref is set to true when all it should check for is whether staging is enabled. For Windows it checks if the maintenance service pref is enabled but it doesn't check if the maintenance service is installed.
Assignee | ||
Comment 1•9 years ago
|
||
I suspect this is the cause of the large number of staging errors I am seeing in telemetry.
Attachment #8592619 -
Flags: review?(netzen)
Assignee | ||
Updated•9 years ago
|
Attachment #8592619 -
Flags: review?(netzen) → review?(spohl.mozilla.bugs)
Assignee | ||
Updated•9 years ago
|
status-firefox37:
--- → wontfix
status-firefox38:
--- → affected
status-firefox39:
--- → affected
status-firefox-esr31:
--- → wontfix
status-firefox-esr38:
--- → affected
Assignee | ||
Comment 2•9 years ago
|
||
Comment on attachment 8592619 [details] [diff] [review] patch rev1 Brian, I'd also like your input on this.
Attachment #8592619 -
Flags: review?(netzen)
Assignee | ||
Comment 3•9 years ago
|
||
Tests passed locally Pushed to try https://treeherder.mozilla.org/#/jobs?repo=try&revision=337f4fd12d2b
Assignee | ||
Comment 4•9 years ago
|
||
Thought I screwed up the patch when I hadn't... new try push https://treeherder.mozilla.org/#/jobs?repo=try&revision=9f33e0170b93
Updated•9 years ago
|
Attachment #8592619 -
Flags: review?(spohl.mozilla.bugs) → review+
Comment 5•9 years ago
|
||
Comment on attachment 8592619 [details] [diff] [review] patch rev1 Review of attachment 8592619 [details] [diff] [review]: ----------------------------------------------------------------- ::: toolkit/mozapps/update/nsUpdateService.js @@ -651,5 @@ > // For Gonk, the updater will remount the /system partition to move staged > - // files into place and it uses the app.update.service.enabled preference for > - // this purpose. > - if (AppConstants.platform == "win" || AppConstants.platform == "gonk") { > - if (getPref("getBoolPref", PREF_APP_UPDATE_SERVICE_ENABLED, false)) { whoa strange
Attachment #8592619 -
Flags: review?(netzen) → review+
Assignee | ||
Comment 6•9 years ago
|
||
Pushed to fx-team https://hg.mozilla.org/integration/fx-team/rev/3cb6adf9dc71
Target Milestone: --- → mozilla40
Comment 7•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/3cb6adf9dc71
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 8•9 years ago
|
||
[Tracking Requested - why for this release]: This is in support of the update orphaning project. This bug will cause Windows users without the maintenance service installed and don't have write access to the install directory to try to stage updates when they can't. There is also a large number of staging failures in telemetry that this bug is likely at the least partially if not entirely responsible for.
tracking-firefox38:
--- → ?
tracking-firefox39:
--- → ?
Comment 9•9 years ago
|
||
Robert, is it possible to have an uplift request to aurora & beta? Thanks
Assignee | ||
Comment 10•9 years ago
|
||
Approval Request Comment [Feature/regressing bug #]: bug 764684 and bug 757965 [User impact if declined]: the users that don't have the maintenance service installed and don't have write access to the install directory will have update staging errors. [Describe test coverage new/current, TreeHerder]: Landed on m-c and tested via try and locally. [Risks and why]: Minimal. This makes it so the code takes the original update process path prior to staging being implemented. [String/UUID change made/needed]: None
Flags: needinfo?(robert.strong.bugs)
Attachment #8593972 -
Flags: review+
Attachment #8593972 -
Flags: approval-mozilla-beta?
Attachment #8593972 -
Flags: approval-mozilla-aurora?
Comment 11•9 years ago
|
||
Comment on attachment 8593972 [details] [diff] [review] aurora and beta patch Should be in 38 beta 6.
Attachment #8593972 -
Flags: approval-mozilla-beta?
Attachment #8593972 -
Flags: approval-mozilla-beta+
Attachment #8593972 -
Flags: approval-mozilla-aurora?
Attachment #8593972 -
Flags: approval-mozilla-aurora+
Assignee | ||
Comment 12•9 years ago
|
||
This reverts the behavior for gonk back to the way it was before due to bug 1155704
Attachment #8594134 -
Flags: review?(spohl.mozilla.bugs)
Updated•9 years ago
|
Attachment #8594134 -
Flags: review?(spohl.mozilla.bugs) → review+
Assignee | ||
Comment 13•9 years ago
|
||
Assignee | ||
Comment 14•9 years ago
|
||
Pushed the followup to mozilla-central https://hg.mozilla.org/mozilla-central/rev/fff4d44e1f41 Pushed to mozilla-aurora https://hg.mozilla.org/releases/mozilla-aurora/rev/a143dc9dc92f I'll push to beta soon
Assignee | ||
Comment 16•9 years ago
|
||
Relanded followup on mozilla-central due to incorrect bug id backout https://hg.mozilla.org/mozilla-central/rev/a009b998edb7 reland https://hg.mozilla.org/mozilla-central/rev/8af644c9b616
Assignee | ||
Comment 17•9 years ago
|
||
Pushed to mozilla-beta https://hg.mozilla.org/releases/mozilla-beta/rev/86d3b1103197
Assignee | ||
Comment 18•9 years ago
|
||
It looks like this might have fixed the vast majority of staging STATE_FAILED though STATE_PENDING doesn't seem to have decreased. I'll look at it again in a few more days.
Assignee | ||
Comment 19•9 years ago
|
||
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #18) > It looks like this might have fixed the vast majority of staging > STATE_FAILED though STATE_PENDING doesn't seem to have decreased. I'll look > at it again in a few more days. Scratch that, the reduction in failures has to do with bug 1157233 popping up on days when there are multiple nightlys built and then going away on days when there is only one nightly built. :(
Comment 20•9 years ago
|
||
Robert, could you please provide some detailed steps to verify this on ESR 38? It would really help us save precious time.
Flags: needinfo?(robert.strong.bugs)
Assignee | ||
Comment 21•9 years ago
|
||
On Win 7 with UAC turned on install under Program Files. Uninstall the Mozilla Maintenance Service Verify that the app.update.service.enabled preference is true Set the app.update.log preference to true Set the devtools.errorconsole.enabled preference to true Install an update using the about dialog Without this patch it should fail the staging of the update (possibly a UAC dialog will be displayed) and with the patch staging should not be attempted. There should be messages in the error console (tools -> web devloper -> error console) that staging failed without the patch and with the patch there should be messages that staging was not attempted.
Flags: needinfo?(robert.strong.bugs)
Comment 22•9 years ago
|
||
I've tested with Firefox 38 Beta 2 (buildID: 20150406174117) and I have the following message in Error Console: "Notifying observers that the update was staged". I've tested with Firefox 38.0 ESR (buildID: 20150505103531) and I have the following message in Error Console: "Unable to stage updates". It is expected?
Flags: needinfo?(robert.strong.bugs)
Assignee | ||
Comment 23•9 years ago
|
||
That is the expected logging. Thanks!
Flags: needinfo?(robert.strong.bugs)
Comment 24•9 years ago
|
||
Verified fixed on Firefox 38 (buildID: 20150503173159).
You need to log in
before you can comment on or make changes to this bug.
Description
•