372981 - Update history missing after update to 2.0.0.2

Status: RESOLVED WONTFIX

(Toolkit :: Application Update, defect)

Description

[the-edmeister]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.3pre) Gecko/20070305 BonEcho/2.0.0.3pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.3pre) Gecko/20070305 BonEcho/2.0.0.3pre

Also happened with a release verison.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2 ID:2007021917

updates.xml file from the ~\Program Files\~ folder was not merged with the newly created updates.xml in the new ~\Local Settings\~. 
2.0.0.2 Release version: The old file shows the update shows Status: Install Pending after replacing the new file with the old file, where the new file for 2.0.0.2 had the Update History window showing no updates - it was empty.

2.0.0.3pre version: ~\Program Files\~ updates.xml has all the updates thru 20070210 and what appears to be 20070211 as Pending (viewing the updates.xml file without replacing the new one), where the ~\Local Settings\~ updates.xml has all the updates from 20070212 to current date showing.
 

Reproducible: Always

Steps to Reproduce:
1.three different installations
2.same results with all three
3.normal updates installed thru mozilla servers
Actual Results:  
The old updates.xml file isn't merged when the update procedure creates the new file in the new location, plus one update is lost from both of the files, while showing as Install Pending in the older file.

Expected Results:  
The old updates should be merged into the newly created updates.xml file so the user would have a continuing record of the updates that were installed.

First mentioned in this thread at MozillaZine fora - http://forums.mozillazine.org/viewtopic.php?p=2781345 . Upon seeing that post I investigated what the OP was talking about and saw the problem for myself in 3 different installations - 2 Release versions and one Branch Nightly that is updated everyday.
Normal to Minor in nature, but I am classifying as Normal due the effort required to merge the files and the loss of the actual Update.

Comment 1

[night.0wl]

I was the OP in the Mozillazine forum thread mentioned above and can confirm the same problem with updates.xml on Windows XP SP2 after installing the release version of Firefox 2.0.0.2.

Four or five days after I manually upgraded, FF informed me that it had downloaded and was waiting to install the update (this also was odd as normally FF simply tells me a new version is available and asks whether I want it now, rather than going ahead and downloading it.) I suspect this was due to the loss of upgrade history in the ~\Local Settings\~ copy of updates.xml and may be why users have reported being offered the upgrade when it is already installed. 

Comment 2

[Nick Thomas [:nthomas] (UTC+12)]

To clarify, there are two issues here.

1, update history appears (to the user) to be lost after updating to 2.0.0.2
2, the update to 2.0.0.2 stays in the pending state, which might lead to repeated prompts to update to the current version

The steps to reproduce are 1 are:

1, Start with an install that is version < 2.0.0.2 and has an update history (I used 2.0.0.1 with 2.0rc3 & 2.0.0.1 in the history)
2, Go to Tools > Options > Advanced > Update > Show Update History to verify that history is present
3, Update to 2.0.0.2
4, Repeat 2 and observe that "No updates are installed yet".

At this point <firefox_install_dir>/updates.xml still contains the prior update history plus the 2.0.0.2 update in an "Install Pending" state; active-update.xml has the content for 2.0.0.2, in my case a partial update is pending.

In the new location
 C:\Documents and Settings\<username>\Local Settings\Mozilla\Firefox\Mozilla Firefox\
the files updates.xml and active-update.xml contain only the line 
 <updates xmlns="http://www.mozilla.org/2005/app-update"/>
It's the updates.xml from here that seems to be being used to populate the Update History dialog.

Per comment #0, the nightlies offer a bit more information:
 * <firefox_install_dir>/updates.xml has all the updates thru
20070210 and what appears to be 20070211 as Pending 
 * the Local Settings updates.xml has all the updates from 20070212 to current date showing.

I'm testing with Win XP rather than 2000, I don't think Linux has a problem as the update history is complete there.

Comment 3

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: update history to make testing easier

To test this bug starting from a clean install of 2.0.0.1
1, save this file as <firefox_install_dir>/updates.xml
2, make sure active-update.xml is empty except for 
  <updates xmlns="http://www.mozilla.org/2005/app-update"/>
3, move aside all files in 
 %APPDATA%\..\Local Settings\Application Data\Mozilla\Firefox\Mozilla Firefox

I can't reproduce the bug when manually unpacking the installer or using a zip, you must use the installer.

Comment 4

[Carsten Book [:Tomcat]]

Attachment: Update log screenshot

wfm on Windows 2000 SP4 Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.2) Gecko/2007021917 Firefox/2.0.0.2

I used the steps/testcase from comment#3 and the update history will stay also after aus update to 2002 (see screenshot).

Comment 5

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #2)
> 2, the update to 2.0.0.2 stays in the pending state, which might lead to
> repeated prompts to update to the current version

Could that be the cause of bug 371649?

Comment 6

[(not reading, please use [e-mail] instead)]

sorry for the delay in responding.

at first glance, this appears to be fall out from a change to getDirInternal() for Vista (see bug #351949).

from http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/update/src/nsUpdateService.js.in#241

237 function getDirInternal(key, pathArray, shouldCreate, update) {
238   var fileLocator = Components.classes["@mozilla.org/file/directory_service;1"]
239                               .getService(Components.interfaces.nsIProperties);
240   var dir = fileLocator.get(key, Components.interfaces.nsILocalFile);
241 #ifdef XP_WIN
242   if (update) {
243     var programFilesDir = fileLocator.get(KEY_PROGRAMFILES,
244         Components.interfaces.nsILocalFile);
245     if (programFilesDir.contains(dir, true)) {
246       var relativePath = dir.getRelativeDescriptor(programFilesDir);
247       var userLocalDir = fileLocator.get(KEY_LOCALDATA,
248           Components.interfaces.nsILocalFile).parent;
249       dir.setRelativeDescriptor(userLocalDir, relativePath);
250     }
251   }
252 #endif

so on windows, if you've installed under "C:\Program Files" [1], we'll switch to using KEY_LOCALDATA, which I believe boils down to calling nsXREDirProvider::GetUserDataDirectory(), see http://lxr.mozilla.org/mozilla/source/toolkit/xre/nsXREDirProvider.cpp#833.  And, GetUserDataDirectory() can return different paths based on the version of windows you are running on.

[1] actually, I believe eventually we figure this out by calling SHGetSpecialFolderPathW() with CSIDL_PROGRAM_FILES (0x0026), to get the typical program files directory, which is C:\Program Files.

Comment 7

[(not reading, please use [e-mail] instead)]

>> 2, the update to 2.0.0.2 stays in the pending state, which might lead to
>> repeated prompts to update to the current version
>
>Could that be the cause of bug 371649?

good question.  I'm not 100% sure, I'm guessing no.

Off the top of my head (I haven't reproduced either bug yet), if we've switched locations (to where we find these files), the old one with the pending update should longer be read by 2.0.0.2 (and up), but it could be read if you were to fire up 2.0.0.1.

Comment 8

[the-edmeister]

To clarify [url=https://bugzilla.mozilla.org/show_bug.cgi?id=372981]comment #0[/url]the complete loss of data in the Show Update History window only happens on installations that started out as a ZIP-archive build - 1 that has been a Branch Nightly since initial installation and the other 1 that started out as a 2.0RC1 ZIP and was changed to Beta then the Release Channel. (Sorry for my not realizing that yesterday.)
Non-standard installation locations for all versions of Firefox due to dual-boot Win98/W2K - W2K-SP4 is on the E:\ logical drive and that is what I primarily use.

The Installer version that started out at 2.0b2 has two identical updates.xml files in the 2 different locations (right down to statusText="Install Pending" for 2.0.0.2). The complete update history appears - BUT the 2.0.0.2 Security Update shows as "Status Pending".

So I guess the real problem I am seeing is that the Update History is showing 2.0.0.2 as Install Pending on the Official Installer version. I am not all that concerned about the loss of data on the un-official ZIP-archive build installations now that I see the difference in the Official Installer Version.

Comment 9

[Masatoshi Kimura [:emk]]

> 245     if (programFilesDir.contains(dir, true)) {
If you launch Firefox via association, contains() will return false because dir is short name while programFilesDir is long name. Therefore %ProgramFiles%\Mozilla Firefox\updates will be refered even if you are using Fx 2.0.0.2.

Steps to reproduce:
1. Install Fx 2.0.0.1 to the default location (i.e. C:\Program Files\Mozilla Firefox)
2. Update to Fx 2.0.0.2 from Help - Check for Update.
3. Check for update again to make sure no update is available.
4. Exit Firefox and make sure no firefox.exe instance exist.
5. Start menu - Run - type "C:\PROGRA~1\MOZILL~1\firefox.exe".
6. Check for update once again.
Actual result:
You will be informed to update to 2.0.0.2 again.
If you type "C:\Program Files\Mozilla Firefox\firefox.exe", you will not be informed.

Why the executable path is shorten when setting associations?

Comment 11

[the-edmeister]

> The Installer version that started out at 2.0b2 has two identical updates.xml
> files in the 2 different locations (right down to statusText="Install Pending"
> for 2.0.0.2). The complete update history appears - BUT the 2.0.0.2 Security
> Update shows as "Status Pending".

The 2.0.0.3rc1 update caused the loss of Update History on that version a few days ago. The original Program Files\ updates.xml file had the old data, where the newer \Local Settings\ updates.xml file had only the 2.0.0.3 data.

Comment 12

[erikernst2]

I think the update history should be removed. It has no big advantage and it doesn't work correct with many many useres (at least in Germany...)

Comment 13

[(not reading, please use [e-mail] instead)]

earlier kimura-san asked:

"Why the executable path is shorten when setting associations?"

the answer is the registry.

for example, I have:  

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\FirefoxURL\shell\open\command

C:\PROGRA~1\MOZILL~1\FIREFOX.EXE -url "%1" -requestPending

In addition to getting into this scenario by starting up firefox by opening files, you can get into it by launching firefox by clicking urls in other applications.

Comment 17

[Robert Strong (they/them - no direct email)]

This problem is specific to updating from a version prior to 2.0.0.2 and isn't a problem with newer versions. We aren't going to fix this now that 2.0.0.x is end of life so resolving -> wontfix