Firefox wants to downgrade to 2.0.0.2 from 2.0.0.3

VERIFIED FIXED

Status

()

--
major
VERIFIED FIXED
12 years ago
10 years ago

People

(Reporter: dennis, Assigned: benjamin)

Tracking

({fixed1.8.1.4})

unspecified
x86
Windows XP
fixed1.8.1.4
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.8.1.4 +
blocking1.8.0.12 -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(26 attachments, 3 obsolete attachments)

74.31 KB, image/jpeg
Details
3.79 KB, text/xml
Details
57 bytes, text/xml
Details
57 bytes, text/xml
Details
1.93 KB, text/xml
Details
18.49 KB, application/octet-stream
Details
643 bytes, application/xml
Details
57 bytes, text/xml
Details
1.00 KB, text/xml
Details
21.41 KB, application/octet-stream
Details
2.30 KB, application/x-zip-compressed
Details
2.80 KB, text/xml
Details
1000 bytes, text/xml
Details
19.80 KB, application/octet-stream
Details
9 bytes, application/octet-stream
Details
59 bytes, text/xml
Details
1.00 KB, text/xml
Details
22.34 KB, application/octet-stream
Details
15.94 KB, application/zip
Details
4.10 KB, application/x-zip-compressed
Details
6.53 KB, patch
benjamin
: review+
Details | Diff | Splinter Review
6.55 KB, patch
benjamin
: review+
Details | Diff | Splinter Review
16.95 KB, patch
Details | Diff | Splinter Review
63.32 KB, application/force-download
Details
22.13 KB, patch
Details | Diff | Splinter Review
23.64 KB, patch
Details | Diff | Splinter Review
(Reporter)

Description

12 years ago
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
Can you attach the updates.xml and active-update.xml from the firefox application directory (like c:\program files\firefox)
(Reporter)

Comment 2

12 years ago
Posted file updates.xml
(Reporter)

Comment 3

12 years ago
Posted file active-update.xml
(Reporter)

Comment 4

12 years ago
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

12 years ago
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?
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

12 years ago
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. :-) 
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.
Assignee: nobody → sspitzer
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 10

12 years ago
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?
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.
Duplicate of this bug: 376197
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

12 years ago

Comment 15

12 years ago
Posted file updates.xml - Eli

Comment 16

12 years ago

Comment 17

12 years ago
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

12 years ago
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.
> 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.
Status: NEW → ASSIGNED
>> 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.
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!
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. 
> 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 28

12 years ago
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 .
thanks for the files, Eli.

Your files indicate a successful 2002 -> 2003 update.

Comment 30

12 years ago
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.
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
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

12 years ago
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

12 years ago
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

12 years ago
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

12 years ago
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 38

12 years ago
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!
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
realm's updates.xml file
^^ 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
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

12 years ago
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

12 years ago

Comment 52

12 years ago
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

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

Comment 54

12 years ago
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.
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.)
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)) {
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.
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...
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.
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.
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.
Attachment #261326 - Attachment description: patch, instead of using nsILocalFile.contains(), use parent and equal to roll my own. → MOZILLA_1_8_BRANCH patch
(Assignee)

Updated

12 years ago
Attachment #261326 - Flags: review?(benjamin) → review+
(Assignee)

Updated

12 years ago
Attachment #261355 - Flags: review?(benjamin) → review+

Comment 64

12 years ago
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?
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Whiteboard: [landed on the trunk, needs verification before landing on the MOZILLA_1_8_BRANC
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
Correction:
> 4. Start Minefield
4. Start Minefield again via short path
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)
based on kimura's comments, I want to back myself out.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
> 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.
Status: REOPENED → ASSIGNED
(Assignee)

Comment 71

12 years ago
Seth, I'll take this and ping you with questions if I need to.
Assignee: sspitzer → benjamin
Status: ASSIGNED → NEW
Posted patch safer patchSplinter Review
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.
Attachment #261326 - Attachment is patch: true
Flags: blocking1.8.1.4?
Duplicate of this bug: 371649
Flags: blocking1.8.1.4? → blocking1.8.1.4+
Flags: blocking1.8.0.12?
(Assignee)

Comment 74

12 years ago
Because the vista support patches never landed on the 1.8.0 branch, this bug does not appear there.
Flags: blocking1.8.0.12? → blocking1.8.0.12-
(Assignee)

Updated

12 years ago
Whiteboard: [landed on the trunk, needs verification before landing on the MOZILLA_1_8_BRANC → [backed out on trunk]
(Assignee)

Comment 75

12 years ago
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>.
Attachment #261972 - Flags: superreview?(sspitzer)
Attachment #261972 - Flags: review?(robert.bugzilla)

Comment 77

12 years ago
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 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.
Attachment #261972 - Flags: review?(robert.bugzilla) → review+
(Assignee)

Comment 79

12 years ago
> 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 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.
> I refered relativeDesc in comment #68,
Sorry, comment #66.
(Assignee)

Comment 83

12 years ago
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.
Attachment #261972 - Attachment is obsolete: true
Attachment #262259 - Flags: superreview?(sspitzer)
Attachment #261972 - Flags: superreview?(sspitzer)
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?
(Assignee)

Comment 85

12 years ago
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 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?
(Assignee)

Comment 87

12 years ago
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.
(Assignee)

Comment 88

12 years ago
Attachment #262499 - Flags: approval1.8.1.4?
Whiteboard: [backed out on trunk] → [backed out on trunk] waiting on r=sspitzer
(Assignee)

Comment 89

12 years ago
I checked this in on trunk Friday.
Status: NEW → RESOLVED
Last Resolved: 12 years ago12 years ago
Resolution: --- → FIXED

Updated

12 years ago
Duplicate of this bug: 378511
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?
Whiteboard: [backed out on trunk] waiting on r=sspitzer → waiting on r=sspitzer
(Assignee)

Comment 92

12 years ago
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.
Keywords: qawanted
Whiteboard: waiting on r=sspitzer → waiting on r=sspitzer and/or QA trunk verification
 (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.  
(Assignee)

Comment 94

12 years ago
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.
(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 on attachment 262499 [details] [diff] [review]
Normalize patch for the 1.8branch

approved for 1.8.1.4, a=dveditz for release-drivers
Attachment #262499 - Flags: approval1.8.1.4? → approval1.8.1.4+
(Assignee)

Comment 97

12 years ago
Fixed on MOZILLA_1_8_BRANCH for 1.8.1.4
Keywords: fixed1.8.1.4
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 ?

Do we need to respin for this?
(Assignee)

Comment 100

12 years ago
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.

Updated

12 years ago
Duplicate of this bug: 379567
(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.
Depends on: 379722
Let's track the dump separately in bug 379722 so this bug doesn't get any more confusing.
No longer depends on: 379722
Depends on: 379722
Depends on: 379738
Product: Firefox → Toolkit
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.
Status: RESOLVED → VERIFIED
Keywords: qawanted
Whiteboard: waiting on r=sspitzer and/or QA trunk verification
(Assignee)

Updated

10 years ago
Attachment #262259 - Flags: superreview?(moco)
You need to log in before you can comment on or make changes to this bug.