Closed
Bug 375710
Opened 17 years ago
Closed 17 years ago
Firefox wants to downgrade to 2.0.0.2 from 2.0.0.3
Categories
(Toolkit :: Application Update, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: dennis, Assigned: benjamin)
References
()
Details
(Keywords: fixed1.8.1.4)
Attachments
(26 files, 3 obsolete files)
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
|
dveditz
:
approval1.8.1.4+
|
Details | Diff | Splinter Review |
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•17 years ago
|
||
Can you attach the updates.xml and active-update.xml from the firefox application directory (like c:\program files\firefox)
Reporter | ||
Comment 2•17 years ago
|
||
Reporter | ||
Comment 3•17 years ago
|
||
Reporter | ||
Comment 4•17 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•17 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?
Comment 6•17 years ago
|
||
same issue "reported" at http://www.flickr.com/photos/uberhax0r/431323902/
Comment 7•17 years ago
|
||
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•17 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. :-)
Comment 9•17 years ago
|
||
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•17 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?
Comment 11•17 years ago
|
||
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•17 years ago
|
||
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•17 years ago
|
||
Comment 15•17 years ago
|
||
Comment 16•17 years ago
|
||
Comment 17•17 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•17 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.
Comment 19•17 years ago
|
||
> 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
Comment 20•17 years ago
|
||
>> 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•17 years ago
|
||
Comment 22•17 years ago
|
||
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•17 years ago
|
||
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•17 years ago
|
||
> 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•17 years ago
|
||
Comment 26•17 years ago
|
||
Comment 27•17 years ago
|
||
Comment 28•17 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 .
Comment 29•17 years ago
|
||
thanks for the files, Eli. Your files indicate a successful 2002 -> 2003 update.
Comment 30•17 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.
Comment 31•17 years ago
|
||
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•17 years ago
|
||
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•17 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•17 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•17 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•17 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 37•17 years ago
|
||
Comment 38•17 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!
Comment 39•17 years ago
|
||
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•17 years ago
|
||
realm's updates.xml file
Comment 41•17 years ago
|
||
Comment 42•17 years ago
|
||
Comment 43•17 years ago
|
||
Comment 44•17 years ago
|
||
^^ 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•17 years ago
|
||
Comment 46•17 years ago
|
||
Comment 47•17 years ago
|
||
Comment 48•17 years ago
|
||
Attachment #260844 -
Attachment is obsolete: true
Comment 49•17 years ago
|
||
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•17 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•17 years ago
|
||
Comment 52•17 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•17 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•17 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.
Comment 55•17 years ago
|
||
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•17 years ago
|
||
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•17 years ago
|
||
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•17 years ago
|
||
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•17 years ago
|
||
Attachment #261326 -
Flags: review?(benjamin)
Comment 60•17 years ago
|
||
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•17 years ago
|
||
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•17 years ago
|
||
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•17 years ago
|
||
Attachment #261355 -
Flags: review?(benjamin)
Updated•17 years ago
|
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•17 years ago
|
Attachment #261326 -
Flags: review?(benjamin) → review+
Assignee | ||
Updated•17 years ago
|
Attachment #261355 -
Flags: review?(benjamin) → review+
Comment 64•17 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?
Comment 65•17 years ago
|
||
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
Closed: 17 years ago
Resolution: --- → FIXED
Whiteboard: [landed on the trunk, needs verification before landing on the MOZILLA_1_8_BRANC
Comment 66•17 years ago
|
||
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•17 years ago
|
||
Correction:
> 4. Start Minefield
4. Start Minefield again via short path
Comment 68•17 years ago
|
||
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•17 years ago
|
||
based on kimura's comments, I want to back myself out.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 70•17 years ago
|
||
> 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•17 years ago
|
||
Seth, I'll take this and ping you with questions if I need to.
Assignee: sspitzer → benjamin
Status: ASSIGNED → NEW
Comment 72•17 years ago
|
||
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.
Updated•17 years ago
|
Attachment #261326 -
Attachment is patch: true
Updated•17 years ago
|
Flags: blocking1.8.1.4?
Updated•17 years ago
|
Flags: blocking1.8.1.4? → blocking1.8.1.4+
Updated•17 years ago
|
Flags: blocking1.8.0.12?
Assignee | ||
Comment 74•17 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•17 years ago
|
Whiteboard: [landed on the trunk, needs verification before landing on the MOZILLA_1_8_BRANC → [backed out on trunk]
Assignee | ||
Comment 75•17 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 76•17 years ago
|
||
Comment 77•17 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 78•17 years ago
|
||
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•17 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 80•17 years ago
|
||
Attachment #261984 -
Attachment is obsolete: true
Comment 81•17 years ago
|
||
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•17 years ago
|
||
> I refered relativeDesc in comment #68, Sorry, comment #66.
Assignee | ||
Comment 83•17 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)
Comment 84•17 years ago
|
||
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•17 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 86•17 years ago
|
||
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•17 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•17 years ago
|
||
Attachment #262499 -
Flags: approval1.8.1.4?
Updated•17 years ago
|
Whiteboard: [backed out on trunk] → [backed out on trunk] waiting on r=sspitzer
Assignee | ||
Comment 89•17 years ago
|
||
I checked this in on trunk Friday.
Status: NEW → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → FIXED
Comment 91•17 years ago
|
||
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•17 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.
Updated•17 years ago
|
Keywords: qawanted
Whiteboard: waiting on r=sspitzer → waiting on r=sspitzer and/or QA trunk verification
Comment 93•17 years ago
|
||
(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•17 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.
Comment 95•17 years ago
|
||
(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•17 years ago
|
||
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+
Comment 98•17 years ago
|
||
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•17 years ago
|
||
Do we need to respin for this?
Assignee | ||
Comment 100•17 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.
Comment 102•17 years ago
|
||
(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•17 years ago
|
||
Let's track the dump separately in bug 379722 so this bug doesn't get any more confusing.
No longer depends on: 379722
Updated•16 years ago
|
Product: Firefox → Toolkit
Comment 104•15 years ago
|
||
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•15 years ago
|
Attachment #262259 -
Flags: superreview?(moco)
You need to log in
before you can comment on or make changes to this bug.
Description
•