375710 - Firefox wants to downgrade to 2.0.0.2 from 2.0.0.3

Status: VERIFIED FIXED

(Toolkit :: Application Update, defect)

Description

[Dennis Kruyt]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

Firefox wanted to downgrade to 2.0.0.2 from 2.0.0.3, see screenshot at http://kruyt.org/upload/downgrade.jpg

I accepted the downgrade and after the restart the cersion wass 2.0.0.2, after that it wanted to upgrade back to 2.0.0.3 again.

This could be a security problem because the 2.0.0.2 has a flaw.

Reproducible: Couldn't Reproduce

Comment 1

[Carsten Book [:Tomcat]]

Attachment: screenshot from comment #0

Can you attach the updates.xml and active-update.xml from the firefox application directory (like c:\program files\firefox)

Comment 2

[Dennis Kruyt]

Attachment: updates.xml

Comment 3

[Dennis Kruyt]

Attachment: active-update.xml

Comment 4

[Dennis Kruyt]

Ok, I have added the req. files. The file are after the downgrade from 0.3 to 0.2 and backup upgrade to 0.3

Comment 5

[Jay Patel [:jay]]

Thanks Dennis for the files.  However, since you already applied the "downgrade" to 2.0.0.2 and then updated again to 2.0.0.3, those files look correct, except for maybe this part in updates.xml:

<patch type="complete" URL="http://download.mozilla.org/?product=firefox-2.0.0.2-complete&os=win&lang=en-US" hashFunction="SHA1" hashValue="0ec4c96dddbc8f18b3c1aca3d3acc42c7de55cba" size="7616371" selected="true" state="succeeded"/>
<patch type="partial" URL="http://download.mozilla.org/?product=firefox-2.0.0.2-partial-2.0.0.1&os=win&lang=en-US" hashFunction="SHA1" hashValue="87adb741882b335b494158fed1115a704c494320" size="762043" selected="false" state="pending"/>

Looks like the partial update is/was in a state="pending", which might explain why you were offered to downgrade before.  

The active-update.xml you have now is correct, it should be empty after a successful update.

Can you give us the exact steps you took to go through this downgrade and update path?  Did you install 2.0.0.3 with the installer?  Did you have an older version (perhaps 2.0.0.1) installed in the same location before you installed 2.0.0.3?

Comment 6

[Carsten Book [:Tomcat]]

same issue "reported" at http://www.flickr.com/photos/uberhax0r/431323902/

Comment 7

[Marcia Knous [:marcia]]

I have seen several other reports of this in Hendrix.  I have sent email to a few of the folks, we'll see if we get some data back.  Here is a brief summary of what two people said:

I just got a pop-up box saying Firefox will update to v 2.0.0.2 when  I
restart. I *have* v 2.0.0.3 already, and the other update is a month
old. *What* is going on here?

Browser Details: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

Comments: 
Hi,

I have version 2.0.0.3 installed. I just got a dialogue box telling me
that I have received 2.0.0.2 as an update. This obviously doesn't make
sense. What is going on here?

Browser Details: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

Comment 8

[Jay Patel [:jay]]

My guess is that people are installing 2.0.0.3 over an older 2.0.0.1 install and that the update files left behind from a failed/cancelled 2.0.0.2 update with 2.0.0.1 are triggering software update and serving up 2.0.0.2 to 2.0.0.3 users.  I hope that made sense.  A lot of 2.0.0.x's in there. :-) 

Comment 9

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

sorry for the delay.   there is enough here to confirm.  I'll start investigating.

carsten / jay / marcia:  if you figure out any more details or steps to reproduce, please let me know.

Comment 10

[Jay Patel [:jay]]

What we need from users that say they are being offered an "update/downgrade" to 2.0.0.2 (while running 2.0.0.3) are:
1. All previous version installed and how they got them (install or update)
2. The updates.xml and active-update.xml files
3. The updates dir also (specifically the last-update.log and update.status file if they exist)  

It's important that they do not apply the update to 2.0.0.2, since we want to find out what state they are in to get that offer.

Seth:  Any ideas on what might be causing this?  Is my theory in comment #8 possible?

Comment 11

[Marcia Knous [:marcia]]

For future reference, please point folks in forums at http://wiki.mozilla.org/Firefox:1.5.0.11-2.0.0.3#Post_Release_Reference_Page for a list of items they need to provide for this bug.

Comment 13

[Carsten Book [:Tomcat]]

comment from bug 376197 
"The only thing I can think of is that I tried installing Adblock Plus earlier
in the day, which then told me it wasn't compatible with 2.0.0.3... could it
have forced a downgrade?"

Eli Sheldon, can you also attach the updates.xml and active-update.xml (should be in the firefox application directory like c:\program files\firefox] to this bug (if exist also the last-update.log and update status -should be in the update directory of firefox like  c:\program files\firefox\updates )..would be great.

Comment 14

[Eli Sheldon]

Attachment: active-update.xml - Eli

Comment 15

[Eli Sheldon]

Attachment: updates.xml - Eli

Comment 16

[Eli Sheldon]

Attachment: last-update.log - Eli

Comment 17

[Eli Sheldon]

Not a problem... I unfortunately also already updated to 2.0.0.3 as well, but if I see this again I will upload the logs prior to updating.
The only addons that had changed in the last few days were me installing AdBlock Plus (only to see that it was incompatible with 2.0.0.3) and Searchbar Autosizer automatically updating from 1.3.4 to 1.3.6.

Comment 18

[Eli Sheldon]

I'm pretty sure my steps to get to 2.0.0.3 would have been auto-updating from 2.0.0.2, which in turn auto-updated from 2.0.0.1.

Comment 19

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

> Seth:  Any ideas on what might be causing this?

No idea yet.  I'm still investigating.

> Is my theory in comment #8 possible?

I'm investigating your theory now to see if that is one way this could happen.

Comment 20

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

>> Is my theory in comment #8 possible?
>I'm investigating your theory now to see if that is one way this could happen.

I've tested your theory, and I don't think that is what is going on.  The reason is, as of the 2002 installer, we remove updates/, active-update.xml and updates.xml on a pave over install.  (see bug #368661 for more details.)

i've confirmed this by:

1) installing 2.0.0.1
2) creating a custom updates.xml that will attempt to upgrade 2.0.0.1 -> 2.0.0.2 (which I'll attach to this bug for testing purposes)
3) point app.update.url.override to my custom updates.xml
4) getting the partial update, but quitting before applying
5) confirm that the partial is pending on disk by looking at active-updates.xml
6) running the 2003 installer to pave over 2001
7) verifying that updates/, active-update.xml and updates.xml are removed before fx 2003 starts up.

I'm continuing to investigate.

Comment 21

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

Attachment: update snippet for testing 2001 -> 2002 (since aus servers won't serve this anymore now that 2003 has shipped)

Comment 22

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

This might have something to do with the changes we made to nsUpdateService.js.in for Vista:

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=nsUpdateService.js.in&branch=1.77.2.46&root=/cvsroot&subdir=mozilla/toolkit/mozapps/update/src&command=DIFF_FRAMESET&rev1=1.77.2.43&rev2=1.77.2.44

Dennis and Eli, can you upload the updates.xml, active-updates.xml files from:

C:\Documents and Settings\<user>\Local Settings\Application Data\Mozilla\Firefox\Mozilla Firefox\

to this bug, if they exist on your machine?  That would be very helpful!

Comment 23

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

So far, the only way I have been able to reproduce what Eli and Dennis saw was by force feeding 2.0.0.3 the 2.0.0.2 update snippet, forcing the downgrade.

Details:

1) run 2.0.0.3
2) setting app.update.url.override to https://bugzilla.mozilla.org/attachment.cgi?id=260351 (which will incorrectly present 2003 with the upgrade snippet for 2001 -> 2002)
3) wait for the partial to be downloaded in the background.
4) get prompted in the exact same way as these screen shots:

http://www.flickr.com/photos/uberhax0r/431323902/
https://bugzilla.mozilla.org/attachment.cgi?id=259924

Note, to only way to get the "Firefox <version> Ready to Install" page of the wizard gets shown only after downloading the update in the background.

http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/update/src/nsUpdateService.js.in#2559
http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/update/src/nsUpdateService.js.in#2724
http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/update/content/updates.js#1587
http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/update/content/updates.js#379
http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/update/content/updates.xul#203

Having a previously successfully downloaded partial or complete 2002 mar on disk would not cause 2003 to show the ready to install UI.

There was a report of 2.0.0.2 wanting to upgrade to 2.0.0.2, which could be related.  See bug #375710. 

Comment 24

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

> There was a report of 2.0.0.2 wanting to upgrade to 2.0.0.2, which could be
> related.  See bug #375710. 

oops, I mean bug #371649

Comment 25

[Eli Sheldon]

Attachment: active-update.xml from App Data - Eli

Comment 26

[Eli Sheldon]

Attachment: updates.xml from App Data - Eli

Comment 27

[Eli Sheldon]

Attachment: last-update.log from App Data - Eli

Comment 28

[Eli Sheldon]

Alright, I uploaded the three update files from ...\Local Settings\Application
Data\Mozilla\Firefox\Mozilla Firefox\ .
Firefox is installed to C:\Program Files\Mozilla Firefox for me, and (if it
matters, I doubt they'd conflict but hey, who knows) SeaMonkey 1.5a is
installed to C:\Program Files\mozilla.org\SeaMonkey .

Comment 29

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

thanks for the files, Eli.

Your files indicate a successful 2002 -> 2003 update.

Comment 30

[Eli Sheldon]

But keep in mind that before I posted the bug, I reupdated to 2.0.0.3... is that maybe all it's showing? Or does it show two distinct 2.0.0.3 updates? I'm not sure what I'm looking for, but I can only see one.

Comment 31

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

eli, yes, your last updatess.xml (https://bugzilla.mozilla.org/attachment.cgi?id=260409) shows the the one successful partial update from 2002 to 2003

Comment 32

[Marcia Knous [:marcia]]

email data I received from the person noted in Comment 7:

Hi Marcia,

Thanks for your email. Yes I have a few extensions installed:

- Fast Video Download
- Free Download Manager
- SearchStatus
- SEO For Firefox

All are up to date.

The same thing has happened on both my computers, a couple of times on each.

I did not manually check for updates. This was an automated, "pushed" update that happened without any option to stop it.

Comment 33

[gene smith]

Did it to me on win2k today. However due to a forced reboot from IT (for unrelated reasons), I was unable to save the state it was in with 2.0.0.3 after the push before it came back up and auto installed 2.0.0.2 which I am now running. Been using the auto-update since it came out (ff1.0.7 I think) and it has never done anything like this! Let me know if there is any data I should send or if I should go back to 2.0.0.3 (and maybe it will do it again).

Comment 34

[Eli Sheldon]

If you're still on 2.0.0.2, then I think it's perfect, upload updates.xml and active-update.xml from the firefox application directory (like c:\program files\firefox) and from C:\Documents and Settings\<user>\Local Settings\Application
Data\Mozilla\Firefox\Mozilla Firefox\ .

Comment 35

[Jay Patel [:jay]]

Gene (and anyone else seeing this problem):
  Hopefully your active-update.xml and updates.xml file will shed some light on this issue, but I am also interested in the following pieces of info:

1. Are you running as an Admin user or "Limited" user?
2. Who installed Firefox originally?
3. A complete version history (including which versions were installed, which were updated, and where they are/were installed)
4. Exact locations of the active-update.xml and updates.xml files. Please note:
   - For updates up to 2.0.0.2, they were created in the "C:\Programs Files\Mozilla Firefox" directory.
   - Starting with updates from 2.0.0.2 -> 2.0.0.3, they are in the "C:\Documents and Settings\<user>\Local Settings\Application Data\Mozilla\Firefox\Mozilla Firefox\"

If folks can provide that information, that'll be great.

Comment 36

[Jay Patel [:jay]]

Also note that based on #4 in my last comment, some of you will have those .xml files in BOTH locations.  I am curious to know what all of those files look like, so if you have them, please attach them here.  Thanks!

Comment 37

[gene smith]

Attachment: active-update.xml and updates.xml from pgm files and app data

Comment 38

[gene smith]

1. Are you running as an Admin user or "Limited" user?
**full admin

2. Who installed Firefox originally?
**me

3. A complete version history (including which versions were installed, which
were updated, and where they are/were installed)
**Hard question. Had computer for 3 year approx. Installed mozilla then all versions of ff as they came out. Started using auto-update when it was introduced. Created new profile a few months ago due to flash not working.

4. Exact locations of the active-update.xml and updates.xml files. Please note:
   - For updates up to 2.0.0.2, they were created in the "C:\Programs
Files\Mozilla Firefox" directory.
   - Starting with updates from 2.0.0.2 -> 2.0.0.3, they are in the
"C:\Documents and Settings\<user>\Local Settings\Application
Data\Mozilla\Firefox\Mozilla Firefox\"
**Yes that is where the files are. I have included the files from both locations in the ff-upload.zip attachment.

P/S: Just got a auto-push of 2.0.0.3 which will reinstall on next ff restart!

Comment 39

[Steve England [:stevee]]

I just had a user ("realm") on irc.mozilla.org #firefox who was running Fx 2.0.0.3 and said an update dialog had appeared telling him that Firefox Update 2.0.0.2 was ready to install ( http://img73.imageshack.us/img73/7620/update040607td8.jpg )

Tomcat pointed me to http://wiki.mozilla.org/Firefox:1.5.0.11-2.0.0.3#Post_Release_Reference_Page and I've done my best to get the information required.

Whilst the update dialog was still on his screen (so he hadn't restarted his 2.0.0.3 to apply the 2.0.0.2 'update') I got his updates.xml, active-update.xml, last-update.log and update.status file (to be attached after this post).

His current UAS was Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

He had never done a windows rollback.

He had awoken to the update dialog (so it wasn't triggered from Help > Check For Updates)

He said he always updates from within firefox's auto-update system.

He had the following extensions installed:
adblock plus 		0.7.2.4
flashgot 		0.5.97.03
forecastfox|10n 	0.7.2006101001
kaboodle		0.2.0.5
talkback 		2.0.0.3

The 4 relevant files now follow as attachments

Comment 40

[Steve England [:stevee]]

Attachment: realm's updates.xml file

realm's updates.xml file

Comment 41

[Steve England [:stevee]]

Attachment: realm's active-update.xml file

Comment 42

[Steve England [:stevee]]

Attachment: realm's last-update.log file

Comment 43

[Steve England [:stevee]]

Attachment: realm's update.status file

Comment 44

[Steve England [:stevee]]

^^ The 4 above files are from realm's firefox installation dir (C:\Program Files\Mozilla Firefox) ^^ 


Some more information re: comment 35

1) Reporter ('Realm') is running as admin.
2) Reporter ('Realm') originally installed firefox himself.
3) Installaion dir C:\Program Files\Mozilla Firefox\
4) Profile dir is C:\Documents and Settings\<username>\Application Data\Mozilla\Firefox\

Reporter's <username> is a single word with no spaces or weird characters.

Now follows active-update.xml and updates.xml from reporter's %USERPROFILE%\Local Settings\Application Data\Mozilla\Firefox\Mozilla Firefox\ dir

Comment 45

[Steve England [:stevee]]

Attachment: realm's actice-update.xml file from %USERPROFILE%\Local Settings\Application Data\Mozilla\Firefox\Mozilla Firefox\

Comment 46

[Steve England [:stevee]]

Attachment: realm's updates.xml file from %USERPROFILE%\Local Settings\Application Data\Mozilla\Firefox\Mozilla Firefox\

Comment 47

[Steve England [:stevee]]

Attachment: realm's last-update.log file from %USERPROFILE%\Local Settings\Application

Comment 48

[Steve England [:stevee]]

Attachment: realm's last-update.log file from %USERPROFILE%\Local Settings\Application Data\Mozilla\Firefox\Mozilla Firefox\

Comment 49

[Steve England [:stevee]]

And if it helps:

- C:\Documents and Settings\<username>\Local Settings\Application Data\Mozilla\Firefox\Mozilla Firefox\active-update.xml  __(modified 3/22/2007)__
- C:\Documents and Settings\<username>\Local Settings\Application Data\Mozilla\Firefox\Mozilla Firefox\updates.xml  __(modified 3/22/2007)__
- C:\Documents and Settings\<username>\Local Settings\Application Data\Mozilla\Firefox\Mozilla Firefox\updates\last-update.log  __(modified 3/22/2007)__

- C:\Program Files\Mozilla Firefox\active-update.xml  __(modified 4/06/2007)__
- C:\Program Files\Mozilla Firefox\updates.xml  __(modified 2/24/2007)__
- C:\Program Files\Mozilla Firefox\last-update.log  __(modified 2/24/2007)__
- C:\Program Files\Mozilla Firefox\updates\0\update.status  __(modified 4/06/2007)__

Comment 50

[JConley]

I have this issue and captured it before downgrading. Per the questions listed at http://wiki.mozilla.org/Firefox:1.5.0.11-2.0.0.3#Post_Release_Reference_Page:

1) It hard to say my install history... but I've had all manner of updates, possibly automatic or manual, used to have nightlies of 2.0 but could have reinstalled. FF2.0 is in Program Files/Firefox 2.0 - I have a 3.0 alpha install in Program Files/Firefox 3.0 as well - but only tested a couple of times.

2/3) attached all in commentXX.zip

5) Extentions installed:
- adblock plus
- adblock plus: element hiding helper
- compact menu 1.7.4.5
- CustomizeGoogle
- Distrust 0.6.5 (disabled)
- DOM Inspector
- DownThemAll!
- Fasterfox
- Find in Frame Hack
- Firebug
- Greasemonkey
- IE Tab
- Live HTTP Headers
- NextPlease
- Nuke Anything Enhanced
- QuickRestart
- Redirect Remover
- Restart Firefox
- Slashdotter
- Tab Mix Plus
- Talkback
- Tamper Data
- User Agent Switcher
- VideoDownloader
- View Source Chart
- iFox (theme)

6) the updates dialog came up automatically

Comment 51

[JConley]

Attachment: Files related to comment 50

Comment 52

[Jeroen Boomgaardt]

Just experienced this issue. Haven't restarted FF yet, so hopefully the files contain the clues you need.

1) I believe I started with a fresh install of 2.0 on this WinXP SP2 computer (no previous 1.5) back in November. It has had regular updates since then to 2.0.0.1, 2.0.0.2 and 2.0.0.3.
2) and 3) Attached next.
5) None except for Talkback.
6) The dialog just come up.

Comment 53

[Jeroen Boomgaardt]

Attachment: zip with updates.xml, active-update.xml and updates dir

Attachment to comment 52. File updates/0/update.mar (7,616,371 bytes) removed from this zip because of maximum attachment size.

Comment 54

[Jeroen Boomgaardt]

Additional information related to comment #52: I forgot to mention I also have the nl-NL dictionary installed. Running as an Admin user and installed FF myself. The updates files I submitted are from the C:\Program Files\Mozilla Firefox and the are none of these in the C:\Documents and Settings\Jeroen\Application Data\Mozilla\Firefox location.

Comment 55

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

I'm able to reproduce this, following emk's suggested steps in bug #372981 comment #9.

using a custom snippet (http://www.sspitzer.org/2002-update.xml) I can go from 2001 -> 2002 -> 2003 and then back to 2002, if I launch 2003 via file associations.  (details steps coming soon.)

bsmedberg wants:

1)  a low risk solution to the fix the three usages of contains() in nsPostUpdateWin.js and nsUpdateService.js.in to use caller with code to use nsILocalFile's canonicalPath attribute, and then do a case insensitive string compare.

2) for trunk, a spin off bug to fix contains() to use canonicalPath.  (too risky for the branch, per bsmedberg.)

Comment 56

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

rstrong:

could the EM have a similar issue here:

mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in, line 398 -- if (baseDir && baseDir.contains(itemLocation, true)) {

Comment 57

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

There haven't been any reports so I highly doubt it especially since this has been in use for quite some time now. I'll check it out as time permits.

Comment 58

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

note to bsmedberg:  

for branch, canonicalPath is not part of nsILocalFileWin interface:

http://lxr.mozilla.org/mozilla1.8/source/xpcom/io/nsILocalFileWin.idl

so I'm trying a slightly different approach.  testing now...

Comment 59

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

Attachment: MOZILLA_1_8_BRANCH patch

Comment 60

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

as for what's going on, the answer is a combination of short paths in the registry and the changes made for vista.

in my registry, I have: HKEY_LOCAL_MACHINE\SOFTWARE\Classes\FirefoxURL\shell\open\command

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

So when I start up firefox by clicking on a url in thunderbird, I'll end up getting into this state where contains() will fail.  to ::Contains(), C:\PROGRA~1\MOZILL~1\FIREFOX.EXE is not a child of "C:\Program Files", because nsLocalFileWin::Contains() does not account for short path vs long path.

the result is we use C:\Program Files\Mozilla\Firefox as the update dir, and we see the old 2.0.0.2 active-update.xml

In addition to getting into this scenario by starting up firefox by opening HTML files from the desktop (for example), you can get into it by launching firefox by clicking urls in other applications.

Comment 61

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

schrep asked:

can you ping-pong between 2.0.0.2 -> 2.0.0.3 -> 2.0.0.3 -> 2.0.0.2 -> etc.

I believe the answer is no.  Here's why:

you can go from 2.0.0.2 -> 2.0.0.3 -> 2.0.0.2, as we know.

But to go from 2.0.0.3 back to 2.0.0.2, you had to "use" the 2.0.0.2 active-update.xml that was left behind in the c:\Program Files\Mozilla Firefox directory.  But using the active-update.xml that was left behind will cause it to be "cleaned up":

<updates xmlns="http://www.mozilla.org/2005/app-update"/>

So it will not be an issue.  But this bug, if not fixed, could cause 2004 to downgrade to 2003.  And 2005 to downgrade to 2004.  etc.

schrep asked:  "can we forget the 'contains()' check, and just always use a directory under Local Settings/Application Data?"  we could, but i don't think we should.

we'd have to adjust our code in order to prevent problems with side-by-side installs.  For example, if firefox is under:

c:\program files\mozilla firefox

we use "c:\Documents and Settings\<user>\Local Settings\Application Data\Mozilla\Firefox\Mozilla Firefox" for the update files (on windows xp)

we build this up by appending the relative path of application directory (the "Mozilla Firefox" of "C:\Program Files\Mozilla Firefox") to the parent of the profile temp dir (example: "C:\Documents and Settings\<user>\Local Settings\Application Data\Mozilla\Firefox\") to get:

"C:\Documents and Settings\<user>\Local Settings\Application Data\Mozilla\Firefox\Mozilla Firefox"

For side-by-side installs outside of C:\Program Files\ (and below), the update dir is in the application dir.  But under C:\Program Files, we use the relative path so that our path under "C:\Documents and Settings\<user>\Local Settings\Application Data" is unique.

we could always use a sub folder under the "Application Data", but it guarantee uniqueness, we would have to make things even more complicated.

Comment 62

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

more answers for questions schrep asked:

Note, a complete update will not remove these files.  if it did, we'd lose the update history on a complete update and we'd run into the bug where history whould show updates as "Install Pending" in history, even though they were not pending.  (see bug #368082)

Note, the installer has code to remove the update files in the app dir on install.

See also bug #376305, which tracks the issue of making the install also remove updates from under "C:\Documents and Settings\<user>\Local
Settings\Application Data" during a pave over install.

Comment 63

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

Attachment: trunk fix

Comment 64

[Jeroen Boomgaardt]

Maybe I misunderstand, but if it is an "old" active-update.xml, how can it be that the timestamp of the active-update.xml that I submitted (see zip-file in comment #53) has the date that this bug showed up on my computer? Is it touched or rewritten when this bug happens?

Comment 65

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

fix landed on the trunk:

Checking in nsPostUpdateWin.js;
/cvsroot/mozilla/toolkit/mozapps/update/src/nsPostUpdateWin.js,v  <--  nsPostUpd
ateWin.js
new revision: 1.12; previous revision: 1.11
done
Checking in nsUpdateService.js.in;
/cvsroot/mozilla/toolkit/mozapps/update/src/nsUpdateService.js.in,v  <--  nsUpda
teService.js.in
new revision: 1.131; previous revision: 1.130
done

what's next is to verify and then backport and land on the MOZILLA_1_8_BRANCH.

Comment 66

[Masatoshi Kimura [:emk]]

With this patch, update folder was created under
C:\Documents and Settings\kimu\Local Settings\Application Data\Mozilla\PROGRA~1\MINEFI~1
when I launched Minefield via short path.

Here is the cause:
1. getRelativeDescriptor returns "../PROGRA~1/MINEFI~1" because "Program Files" and "PROGRA~1" don't match.
2. setRelativeDescriptor combines "C:\Documents and Settings\kimu\Local Settings\Application Data\Mozilla\Firefox" and "../PROGRA~1/MINEFI~1".
You should replace not only contains() but also get/setRelativeDescriptor().

Moreover, Minefield didn't detect the updater folder when I launched Minefield via short path.
Steps to reproduce:
1. Launch Minefield via short path.
2. Help > Check for Updates > Download & Install Now
3. Click Later
4. Start Minefield
Actual result:
Updater does not run because Contains() is also used in 
http://mxr.mozilla.org/seamonkey/source/toolkit/xre/nsAppRunner.cpp#2589

Comment 67

[Masatoshi Kimura [:emk]]

Correction:
> 4. Start Minefield
4. Start Minefield again via short path

Comment 68

[Masatoshi Kimura [:emk]]

BTW, my patch attached in bug 371649 comment 35 will solve all the problem.
(However it may be too risky to land on the branch)

Comment 69

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

based on kimura's comments, I want to back myself out.

Comment 70

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

> based on kimura's comments, I want to back myself out.

I've backed myself out until I have more time to investigate the issues kimura reports in comment #66.

Comment 71

[Benjamin Smedberg]

Seth, I'll take this and ping you with questions if I need to.

Comment 72

[Masatoshi Kimura [:emk]]

Attachment: safer patch

This will guarantee the consistent update folder location.
I wouldn't take a bug because I have no enough time to request review, reflect review comment, make a branch patch, and requesting approval. Feel free to reuse the code.

Comment 74

[Benjamin Smedberg]

Because the vista support patches never landed on the 1.8.0 branch, this bug does not appear there.

Comment 75

[Benjamin Smedberg]

Attachment: Normalize to longnames using a dirprovider, and add debugging code, rev. 1

I've cleaned up the last patch a little, and added some logging code which I can use to manually detect whether this is working properly. Unfortunately, I can't figure out a way to do an automated test of this without polluting c:\Program Files, which is not a good thing to do on test machines anyway.

To test, install Firefox to c:\Program Files\SomeDir and run firefox -print-xpcom-dir UpdRootD; check the JS console or stdout (if dump is enabled) for a message about a path under the local user's home. Running the same test from a Firefox installed anywhere else should dump <Not Provided>.

Comment 76

[Matthew Kidd]

Attachment: zip containing updates.xml and active-update.xml

Comment 77

[Matthew Kidd]

I think we are seeing this problem on two machines in our organization. In both cases the affected user was running as a Limited User under XP Pro SP2. When they would start Firefox, they would receive a dialog titled "Software Update Failed" which said, "One or more files could not be updated. Please make sure all other applications are closed and that you have permission to modify files, and then restart Firefox to try again.", before the main Firefox window appeared.

Method #1 in the URL below solved the problem.
http://kb.mozillazine.org/Updates_reported_when_running_newest_version

Answering the specific questions questions posed in the URL.

1. The machine originally had some version of 1.5.0.x installed. Later this was updated to 2.0.0.0 by downloading and running the 2.0.0.0 installer without removing the 1.5.0.x of Firefox first. Subsequently, updates to 2.0.0.1, 2.0.0.2, and 2.0.0.3 were performed via Help --> Check for Update within the application when a local administrator was logged in.

5. CustomizeGoogle, DuplicateTab, Flashblock, and Nuke Anything enhanced were installed as global extensions (which owing to the installation location, the Limited User would not be able to upgrade). These were periodically upgraded via  Tools --> Add Ons --> Check for Updates, when a local administrator was logged in.

At first we thought this problem might have something to do with the globally installed extensions which the Limited User would be unable to update. So we completely uninstalled Firefox 2.0.0.3, deleted the C:\Program Files\Mozilla Firefox directory (to wipe out the global extensions), reinstalled Firefox 2.0.0.3, and reinstalled the four extensions mentioned about as global extensions. This seemed to solve the problem for a while (several days), but then it started to occur again. My guess is that the newly installed Firefox eventually got around to checking for updates for either itself and/or the extensions and ran into the same issue again.

6. The dialog would just appear every time the Limited User tried to start Firefox.

Comment 78

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

Comment on attachment 261972 [details] [diff] [review]
Normalize to longnames using a dirprovider, and add debugging code, rev. 1

Looks good but I haven't tested it yet... I'll comment again if I see any issues after testing.

>Index: toolkit/components/nsDefaultCLH.js
>===================================================================
>RCS file: /cvsroot/mozilla/toolkit/components/nsDefaultCLH.js,v
>retrieving revision 1.9
>diff -u -8 -p -d -r1.9 nsDefaultCLH.js
>--- toolkit/components/nsDefaultCLH.js	11 Mar 2007 02:21:47 -0000	1.9
>+++ toolkit/components/nsDefaultCLH.js	18 Apr 2007 16:26:20 -0000
>@@ -42,61 +42,102 @@ const nsICategoryManager       = Compone
...
>       if (win) {
>         win.focus();
>-    	  cmdLine.preventDefault = true;
>-	      return;
>+    	cmdLine.preventDefault = true;
>+	  return;
remove the stray tabs

What do you think about XRE_UPDATE_ROOT_DIR returning the update dir for all platforms? Looks like it may be a slight PITA.

Comment 79

[Benjamin Smedberg]

> What do you think about XRE_UPDATE_ROOT_DIR returning the update dir for all
> platforms? Looks like it may be a slight PITA.

I wanted to do that, but the logic in nsPostUpdateWin forks on whether the update is in the appdir or relocated.

Comment 80

[Matthew Kidd]

Attachment: zip file containing updates.xml, active-update.xml, and updates directory (except update.mar which would make the attachment too big)

Comment 81

[Masatoshi Kimura [:emk]]

Comment on attachment 261972 [details] [diff] [review]
Normalize to longnames using a dirprovider, and add debugging code, rev. 1

> +  if (_strnicmp(programFiles, longPath.get(), programFilesLen) != 0)
> +    return NS_ERROR_FAILURE;
(snip)
> +    SetRelativeDescriptor(userLocalDir,
> +                          nsDependentCString(longPath.get() + programFilesLen));
You should use AppendRelativeNativePath instead of SetRelativeDescriptor.
SetRelativeDescriptor will fail if we installed Fx on non-ASCII folder because relativeDesc is UTF-8 encoded.
http://mxr.mozilla.org/seamonkey/source/xpcom/io/nsLocalFileCommon.cpp#212
Moreover, relativeDesc supposed to be a opaque string.
http://mxr.mozilla.org/seamonkey/source/xpcom/io/nsILocalFile.idl#165
I refered relativeDesc in comment #68, but it was only for a debug purpose.

Comment 82

[Masatoshi Kimura [:emk]]

> I refered relativeDesc in comment #68,
Sorry, comment #66.

Comment 83

[Benjamin Smedberg]

Attachment: Normalize to longnames using a dirprovider, and add debugging code, rev. 1.1

Updated with comments, I'm going to commit this on trunk. Seth, I'd still like you to look over this if you have time.

Comment 84

[Marcia Knous [:marcia]]

bsmedberg: It seems Tbird users are seeing this as well (not specifically the downgrade, but being offered the update over and over again), we have seen sporadic reports on hendrix (Vista users). Should we file a separate bug for Tbird?

Comment 85

[Benjamin Smedberg]

This patch would fix tbird automatically, if it had the same root cause. I haven't yet found a user who didn't have this root cause, so I'm fairly confident that we don't need another bug.

Comment 86

[Reed Loden [:reed]]

Comment on attachment 262259 [details] [diff] [review]
Normalize to longnames using a dirprovider, and add debugging code, rev. 1.1

This patch adds "bin\components\nsDefaultCLH.js" to browser's packages-static for unix and windows. Would mail need this added, too?

Comment 87

[Benjamin Smedberg]

It would not *need* it, no. That code was added for testing/verification purposes, but it doesn't affect the update code itself. Although I will add it to tbird on trunk because it certainly wouldn't hurt.

Comment 88

[Benjamin Smedberg]

Attachment: Normalize patch for the 1.8branch

Comment 89

[Benjamin Smedberg]

I checked this in on trunk Friday.

Comment 91

[Daniel Veditz [:dveditz]]

Sorry about that, removed the "backed out" status comment. I got confused by the pending review on the trunk patch.

So does that mean we don't need the review to approve it for the branch?

Comment 92

[Benjamin Smedberg]

Well, I'd feel more comfortable if Seth looked it over, and also if QA tried this using trunk builds to confirm that it is indeed working correctly on trunk.

Comment 93

[Carsten Book [:Tomcat]]

 (In reply to comment #92)
> Well, I'd feel more comfortable if Seth looked it over, and also if QA tried
> this using trunk builds to confirm that it is indeed working correctly on
> trunk.
> 

Hi Benjamin, i have done some update tests around the trunk Builds on Windows XP x64 SP2 (from older builds to the latest trunk) and also used the testcase from comment #75. Test output is Error: print-xpcom-dir("UpdRootD"): <Not Provided>
Source File: file:///H:/gp19a5/components/nsDefaultCLH.js
Line: 60

And thats the expected result i think.

Do you know if there is a kind for testcase for trunk to test if the downgrade ? The STR from comment #23 and #55 are suggesting to install 2.0.0.1.  

Comment 94

[Benjamin Smedberg]

Carsten: the expected result depends on where you install Firefox:

If installed into c:\Program Files, then UpdRootD should point to c:\Documents and Settings\Username\Application Data\...something

If installed elsewhere, it should be <Not provided>

I believe this bug could be reproduced on unfixed nightly builds by first doing an update, then launching Firefox from "c:\Progra~1". Of course, now that nightlies update to a fixed build, I'm not sure how to test that.

Comment 95

[Carsten Book [:Tomcat]]

(In reply to comment #94)
> Carsten: the expected result depends on where you install Firefox:
> 
> If installed into c:\Program Files, then UpdRootD should point to c:\Documents
> and Settings\Username\Application Data\...something
> 
> If installed elsewhere, it should be <Not provided>
> 

Hi Benjanim, thx, i can verified fixed this on trunk. 

Tested on XP x64 Sp2 and Vista and the result is the expected result if i
install Trunk to the program files directory (Vista Result):

print-xpcom-dir("UpdRootD"):
C:\Users\test\AppData\Local\Mozilla\Firefox\Minefield

Build: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a5pre)
Gecko/2007042904 Minefield/3.0a5pre

> I believe this bug could be reproduced on unfixed nightly builds by first doing
> an update, then launching Firefox from "c:\Progra~1". Of course, now that
> nightlies update to a fixed build, I'm not sure how to test that.
> 

Since i don't see after a lot of tests on xp and vista downgrades (tested AUS updates from old nightly builds to latest nightly trunk via launching from c:\Program Files\Minefield , etc), i think i can verify this also as fixed on trunk. 

Comment 96

[Daniel Veditz [:dveditz]]

Comment on attachment 262499 [details] [diff] [review]
Normalize patch for the 1.8branch

approved for 1.8.1.4, a=dveditz for release-drivers

Comment 97

[Benjamin Smedberg]

Fixed on MOZILLA_1_8_BRANCH for 1.8.1.4

Comment 98

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

Not a huge deal, but the linux console gets output of 
  Handling command line!
on startup, which is from
  http://lxr.mozilla.org/mozilla1.8/source/toolkit/components/nsDefaultCLH.js#86

Is this debug info still needed ? Could it be removed as a ride-along change if we do more RCs for 1.8.1.4 ?

Comment 99

[juan becerra [:juanb]]

Do we need to respin for this?

Comment 100

[Benjamin Smedberg]

no. It's an extra dump statement that only will show up on stdout if you have the dom.window.dump.enabled pref set to true, which is not the default.

Comment 102

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

(In reply to comment #100)
> It's an extra dump statement that only will show up on stdout if you have
> the dom.window.dump.enabled pref set to true, which is not the default.

It was mentioned on IRC earlier that this isn't true - the JS component dump (which is what the patch uses) doesn't obey that DOM pref. That means that this does affect all builds, regardless of the pref value.

Comment 103

[Daniel Veditz [:dveditz]]

Let's track the dump separately in bug 379722 so this bug doesn't get any more confusing.

Comment 104

[Aakash Desai [:aakashd]]

A couple of things. 

1. Bug 379722 is set to verified1.8.1.4
2. A major update from 2.0.0.20 goes to 3.0.10 and does not downgrade.
3. An upgrade from last night's trunk nightly build to today's:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090721
Minefield/3.6a1pre ID:20090721044139

works perfectly fine.

I'm moving this to verified FIXED as a result, getting rid of the qawanted keyword and removing the whiteboard.