Open Bug 702045 Opened 13 years ago Updated 1 year ago

Tracking bug: make Firefox able to survive a Windows System Restore

Categories

(Toolkit :: Application Update, defect, P3)

All
Windows 7
defect

Tracking

()

People

(Reporter: blizzard, Unassigned)

References

(Depends on 3 open bugs)

Details

Attachments

(1 file)

Right now Firefox does not survive a Windows system restore.  This is because during a system snapshot only certain files are saved.  We need to make sure that all of the files in our windows install have extensions that will be backed up when a system snapshot is made.

We know that this affects hundreds of thousands of people during every release we do.

Hang issues off this bug.
No longer depends on: 701944
(In reply to Robert Strong [:rstrong] from bug 691847 comment 39)
> Specifically iirc, unless there has been a complete restore point created
> which is often not the case and we don't definitely create one at this time
> because that could add several minutes to the update process. We are
> evaluating creating the restore point with the service in the future after
> we have the service. It is important to note that this has always been the
> case regarding system restore and Firefox.

1. Under what conditions does creating a restore point take a long time?
2. How frequently does that happen?
3. Do we know if this is better or worse for particular versions of Windows or particular configurations that we can detect at runtime?

Note that the document that blizzard links to says that those file extensions are monitored in VISTA or later--not necessarily XP. If we are going to continue along the "rename files" path, we need to find documentation that indicates that it will work on XP too.

Basically, this is me asking if/why we really need to avoid having our installer do things the transactional(-ish?) way that Microsoft recommends and/or Windows requires to prevent these kinds of problems.
Whuck. How is it that JAR isn't on that list? Java's been big in enterprise, so can't help but wonder how this manages to not bite such Java apps. Or maybe it does?

Also, is there no API to allow apps to control how system restore impacts them (not seeing it from a brief search)?

CCing some platform integration folks who should really be involved with this.
(In reply to Christopher Blizzard (:blizzard) from comment #1)
> File names that are monitored for a system restore:
> 
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa378870%28v=vs.
> 85%29.aspx

I verified that "ja" is in the filelist.xml on an XP machine in the office.
(In reply to Brian Smith (:bsmith) from comment #2)
> Note that the document that blizzard links to says that those file
> extensions are monitored in VISTA or later--not necessarily XP. If we are
> going to continue along the "rename files" path, we need to find
> documentation that indicates that it will work on XP too.

From the link in comment 1, XP stores files in %windir%\WINDOWS\system32\Restore\filelist.xml

In my XP virtual machine, this is what that xml file looks like.
Bug 701875 appears to be enough for firefox to mostly survive a system restore. I installed firefox, made a system restore point, and then deleted everything in the firefox directory. After restoring, we lose:

- Dictionaries
- Search plugins
- The update channel prefs file .. or maybe not. I expected this one to go away but I see it's back again.
- update.locale - This may be a problem since it appears that the updater throws a fit if it can't find this. However, it wouldn't be a problem in the normal system restore scenario if nobody deleted it.
- blocklist.xml
- NSS's .chk files
- precomplete
- removed-files
- The default theme (so users wouldn't be able to switch back to the default theme)
This wasn't implied in Comment 6, but just to be clear I wanted to add that from any system restore, it won't remove the file types that aren't included in that system restore point.  

So comment 6 mentioned a directory that had no dictionaries, search plugins, ... 
That test was useful to see what was included, but that exact scenario would only happen if the user uninstalled or deleted Firefox before running the system restore.

So let's say a user restores to 3 weeks ago, they will still have the dictionaries, search plugins, ..., but they will be the current ones, and not the ones from 3 weeks ago. 

But having files that are consistent with each other is obviously important if they are not backwards compatible.
> 3. Do we know if this is better or worse for particular versions of 
> Windows or particular configurations that we can detect at runtime?

Windows Vista and Windows 7 rely on volume shadow copy so they create restore points much faster.  For me it only takes about 15 secons on my development machine. XP works by file copy and compression so is slower.  Also people cusotmize filelist.xml so it gets slower and slower as you get more stuff on your computer.

The server operating systems don't have system restore installed by default, but you can install it.

Other than providing our own rollbacks for updates, I'm not sure what benefit creating our own system restore points would give us. Creating system restore points ourselves would be nice to have but not related to this bug.

omni.jar was obviously important, but I'm not sure which of the list of Comment 6 are the important non backwards compatible files.  If it wasn't for omni.jar I don't think this bug would have been noticed.  But its' definitely something to look out for.

For the files that will always be backwards compatible, if any, if a user decides to uninstall or delete all of our files, I'm not sure that system restore should be a supported way for us to be re-installed.
(In reply to Brian R. Bondy [:bbondy] from comment #8)
> > 3. Do we know if this is better or worse for particular versions of 
> > Windows or particular configurations that we can detect at runtime?
> 
> Windows Vista and Windows 7 rely on volume shadow copy so they create
> restore points much faster.

of note here is the volume shadow copy service backs up all files on the volume, so this bug should be limited to xp users only (http://blog.szynalski.com/2009/11/23/volume-shadow-copy-system-restore/ and http://technet.microsoft.com/en-us/library/ee923636%28WS.10%29.aspx).

> For the files that will always be backwards compatible, if any, if a user
> decides to uninstall or delete all of our files, I'm not sure that system
> restore should be a supported way for us to be re-installed.

we should at least detect it, and provide the means for the user to get firefox back to a working state.

an option may be to keep a copy of the setup executable and offer to launch this after firefox is partially restored by system-restore.
> so this bug should be limited to xp users only

It still only protects a filtered file list on Vista and Win7.
(In reply to Brian Smith (:bsmith) from comment #2)
> (In reply to Robert Strong [:rstrong] from bug 691847 comment 39)
> > Specifically iirc, unless there has been a complete restore point created
> > which is often not the case and we don't definitely create one at this time
> > because that could add several minutes to the update process. We are
> > evaluating creating the restore point with the service in the future after
> > we have the service. It is important to note that this has always been the
> > case regarding system restore and Firefox.
> 
> 1. Under what conditions does creating a restore point take a long time?
As I understand it this is dependent on how many changes since the last restore point was created and as bbondy points out it is slower on XP and below.

> 2. How frequently does that happen?
In my experience often which is entirely anecdotal

> 3. Do we know if this is better or worse for particular versions of Windows
> or particular configurations that we can detect at runtime?
XP

> Note that the document that blizzard links to says that those file
> extensions are monitored in VISTA or later--not necessarily XP. If we are
> going to continue along the "rename files" path, we need to find
> documentation that indicates that it will work on XP too.
> 
> Basically, this is me asking if/why we really need to avoid having our
> installer do things the transactional(-ish?) way that Microsoft recommends
> and/or Windows requires to prevent these kinds of problems.
I think you think I don't want to create restore point which is not the case at all. Restore points need to be created prior to changing files / registry and iirc requires admin privileges. So, without going into the specific details based on the previous sentence, using the maintenance service to create a restore point is viable from a technical and a UX point of view where as without the maintenance service... not so much.
The following is not applicable to the case where someone manually deletes the installation directory and then performs a system restore and IMO this is a case that we shouldn't try to fix.

First off, updates still work per Juan's investigation and I have also verified this

- blocklist.xml
Used on first run when we don't have a blocklist.xml in the profile.
A minor issue as I see it.

- NSS's .chk files
These being out of sync will disable FIPS mode
A serious issue for organizations that require FIPS mode. Users in these organizations should not be able to system restore since they would need admin privileges which would also allow them to disable FIPS themselves so I think this is less of an issue than initially thought.

- precomplete
Used to remove old application files prior to a complete update
Not a serious issue as I see it.

- removed-files
Not used by applications (I have plans to remove it though doing so is extremely low priority)
Not an issue

- install.log
Not used by applications
Not an issue

- The default theme
The default theme metadata will not be rolled back, the default theme will be reported as incompatible, and the newer default theme images will be left in place.
Medium issue - even though the default theme is displayed as incompatible the default theme can still be selected / enabled.

- dictionaries, hyphenation, and searchplugins
Newer files will be left behind
Not a serious issue to have the newer files as I see it though a format change could cause problems.

- channel-prefs.js
This file is not updated during an update
Not an issue

- dependentlibs.list
Tested with the file missing, with entries that don't exist, and with missing entries. Everything worked fine. Also took a look at the code and it appears to fallback gracefully.
Quite certain this is not an issue.
Reference: bug 298044

- uninstall.log
Doesn't affect Firefox use but could affect Firefox uninstall. If there are dll / exe files in the older build that don't exist in the newer build then uninstalling won't remove these files.
Minor issue

As I see it, renaming omni.jar to omni.ja is a good thing to do and we can address the remaining items above as time permits.
bug 577563 will make the uninstall.log participate in session restore
Depends on: 577563
Flags: in-litmus?
Depends on: 730285
(In reply to Robert Strong [:rstrong] (do not email) from comment #12)
> The following is not applicable to the case where someone manually deletes
> the installation directory and then performs a system restore and IMO this
> is a case that we shouldn't try to fix.
What about bookmarks & history, saved passwords, cookies ? Should they be restored ?
Depends on: 877168
Depends on: 877143
Depends on: 891862
(In reply to Paul Silaghi [QA] from comment #14)
> (In reply to Robert Strong [:rstrong] (do not email) from comment #12)
> > The following is not applicable to the case where someone manually deletes
> > the installation directory and then performs a system restore and IMO this
> > is a case that we shouldn't try to fix.
> What about bookmarks & history, saved passwords, cookies ? Should they be
> restored ?
Note: the point I was making with the above statement is that system restore is a first in first out system so deleting the files and then performing a restore can cause files that haven't been backed up for a while to no longer be present when restoring the directory. As for files in the profile they will be restored as long as there is still a copy of the file in system restore.
QA Whiteboard: qa-not-actionable

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Severity: major → --
Component: General → Widget: Win32
Severity: -- → S3
Component: Widget: Win32 → Application Update
Priority: -- → P3
Product: Core → Toolkit
You need to log in before you can comment on or make changes to this bug.