Closed Bug 730285 Opened 12 years ago Closed 9 years ago

No update channel is found after restoring the OS to a previous point.

Categories

(Firefox :: General, defect)

11 Branch
x86
All
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 351216
Tracking Status
firefox11 - ---
firefox12 - ---
firefox13 - ---

People

(Reporter: vlad.ghetiu, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

Attachments

(1 file)

Attached image screenshot
The update channel isn't found (releasetest channel) after the OS (Win 7 and XP) is restored to a previous point.

OSes: Windows 7 x86 , Windows XP

Steps to reproduce:
1.Install Firefox 10 beta 6 (or any other Fx 10 beta)
2.Change the update channel to releasetest. Do not check for update afterwards.
3.Create a restore point.
4.Browse around and create a big profile.
5.Perform an update to Firefox 11 beta 4 on releasetest channel.
6.Restore the OS to the restore point from step 3.

Actual results:
After step 6, the OS reverts to Firefox 10 beta 6 that had been previously installed and all the history/bookmarks/addons are present.
If however you try to update again to Firefox 11 beta 4, no channel is found even though  the releasetest channel is listed in about:config - see screenshot

Expected results:
Firefox should recognize the releasetest channel and perform the update.

Note: If I don't change the channel and perform the same steps from above from Fx 11b1 to Fx11b3 on beta channel, everything is performed as expected. the update after reverting to the previous point is made without problems.
What is in the %firefox%/defaults/prefs/channel-prefs.js file?
This is what is in the file:

"//@line 2 "e:\builds\moz2_slave\rel-m-beta-w32-bld\build\browser\app\profile\channel-prefs.js"
pref("app.update.channel", "releasetest");
"

(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #1)
> What is in the %firefox%/defaults/prefs/channel-prefs.js file?
Yeah, that should definitely find updates. Can you see if you get the same result with the current Beta? (ie. if you don't change the channel?)
I've repeated the steps from the description without changing the channel.
After restoring the OS to a previous point the update channel isn't found even though it's the default channel: "beta"

So this issue it's not related to channel changing.
Can you turn on app.update.log in about:config and see if anything is reported to error console when you check for updates after restore?
This is the error that I'm getting:

Error: uncaught exception: [Exception... "update.locale file doesn't exist in either the XCurProcD or GreD directories"  nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)"  location: "JS frame :: resource:///components/nsUpdateService.js :: getLocale :: line 592"  data: no]

(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #5)
> Can you turn on app.update.log in about:config and see if anything is
> reported to error console when you check for updates after restore?
Blocks: 702045
Asking for tracking given that this *could* result in a user not being able to get updates (at least not without reinstalling Firefox).
(In reply to Vlad [QA] from comment #4)
> So this issue it's not related to channel changing.

When this was first reported, it wasn't clear that channel changing was involved. Given this new info, we'll track for FF11. Sending over to Rob Strong since he did much of the work in bug 702045. This isn't a strict blocker for release considering we're already mitigating Patch Tuesday OS restore risk by throttling, however.
Assignee: nobody → robert.bugzilla
This is just one of the many cases we have had during update where a system restore would break if files were removed or changed. At best we should mitigate this as we do now by avoiding patch Tuesday. The bug that will fix this is bug 351216.
Depends on: 351216
(In reply to Robert Strong [:rstrong] (do not email) from comment #9)
> This is just one of the many cases we have had during update where a system
> restore would break if files were removed or changed. At best we should
> mitigate this as we do now by avoiding patch Tuesday. The bug that will fix
> this is bug 351216.

Given that, untracking.
Keywords: relnote
Assignee: robert.strong.bugs → nobody
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.