User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041103 Firefox/1.0RC2 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041103 Firefox/1.0RC2 I've tested software updates following these instructions: http://www.mozilla.org/projects/firefox/qa/softwareupdate.html I've changed app.version manually to 0.10 as stated there, checked for updates and then successfully installed RC2. But after restarting Firefox app.version didn't reset to 1.0 and I still get update notification from time to time. I suppose this happens because of the fact that the pref was changed manually. But shouldn't it still be reset to a new value in this case? I understand that those were _testing_ instructions but I can easily imagine very common scenario when some user's friend changes this pref to "fix" some extension which didn't yet update its maxversion info. And then on next FireFox update user gets a trouble described as "It still requires me to download all these megabytes 8-[==]!" Reproducible: Always Steps to Reproduce: 1. 2. 3.
This may well be a dupe but I failed to find one...
I am confirming this behavior. I am not really sure it should be overriding a user set version, but clearsly the instructions need to be changes so that the end reult for users is coorect. I suggest that the instructions on http://www.mozilla.org/projects/firefox/qa/softwareupdate.html for Firefox 1.0RC1&2 Users be modified by adding the steps: 11. Open a Firefox window and type about:config in the Location Bar and hit Enter. 12. Type app.version in the Filter box replacing any text that may be there. Right click on the row that appears. 13. A context menu will appear. Select Rest from the context menu. This undes the change made earlier to fool the browser into thinking you're using an earlier version of Firefox. I have requested blocking to get this some visibility, but I do not have priviledge to change the status to new.
Just upgraded from 1.0RC1 to 1.0RC2 and am confirming this bug. The app.version says at 0.10 after upgrading when it should have switched back to 1.0. Please also note that the app.update.url didn't get changed back as well. It still says http://update.mozilla.org/update/firefox/en-US-1.0-rc.rdf.
I believe that all of this is expected. Normal users upgrading on the normal upgrade path won't be manually modifying those strings. I'll doublecheck today but I think this is expected behavior for users having followed the testing instructions.
Status: UNCONFIRMED → NEW
Ever confirmed: true
re comment #4 The point is that after following the testing instructions your borwser is horked. app.version is wrong. IF we don't fix the instructions to tell people to set it back coorectly, all the testers who don't notice this on there own have a misconfiugured browser that could result in things breaking and future bugs that no one can figure out. We at lest need to get the testing instrcuctions corrected to tell peple to set the version back manually after upgrading.
Only aviary drivers can set the blocking flags to + or -, you're welcome to nominate the flag by setting it to ? for their approval or denial.
In testing conditions this is indeed important only for testers expecting bugs by definition. But what about real-world scenario I described in comment 0? Does anyone else think it's real enough? :-)
re comment #6. It was set by me to '?' before this other person set it to '+'. Resetting to '?'. sigh.
In the real world senario described in comment #0, if you were not testing anything and you set the app.version preference to a version different than what you were running, you deserve what you get. This is not a real world issue.
I went through the testing procedure, and I assumed that I'd have to reset the values I changed manually. Having Firefox reset user-set preferences seems like a bad idea, and not something that has any chance of being implemented before 1.0, so I don't know why this is nominated as a blocker. If we're talking about amending the website, then this should be in the web site component, and there's no way it's a release blocker.
(In reply to comment #9) > In the real world senario described in comment #0, if you were not testing > anything and you set the app.version preference to a version different than what > you were running, you deserve what you get. This is not a real world issue. I disagree (or I wouldn't file this bug at all :-) ). Let me explain. Extensions are one of strong selling points of Firefox. We should care about the impression about all this subsystem. But unlike other features this one has an inherent flaw: it depends on other people code that goes directly to users without thorough review process or community testing. And we already know by previous releases (0.9, PR) that extensions' authors are a bit lazy (or busy) with updating their max versions for current Firefox update. Currently extension mechanism is not protected from this happenning (btw, I, though myself am a developer, do not know a proper way to deal with it). Two my coworkers whom I converted to the exciting world of safe and advanced browsing :-) both had this bad experience after upgrade to 1.0PR: "Ah... _They_ again deleted all my extensions". I, being familiar with the architecture, could suggest them three ways of dealing with a problem: - wait knobody knows how much time until extensions will be updated (immediately declined) - go to C:\Documents And Settings\blah..blah..blah..\extensions\Extensions.rdf, grok the format, hack max versions in certain places (sounds too tricky) - type about:config, drop app.version back to 0.10 The latter one was chosen. What I'm trying to tell is that in fact many people might face this problem since they do use extensions and do upgrade their browser. So... Firefox is intended for users who don't want to figure out whom to blame for their horked browser: Firefox developers, extension developers or their techy neighbours. They will just whine and this is understandable. So telling that it's their problem just will hurt ourselves when people will start going back to some well-known stagnant browser which just doesn't have any upgrade problems in the lack of updates themselves... Talking about blocking flags I think this issue should not block the big release. Since this all is about changing app.version on _next_ update we can deal with it after 1.0, before the next big release (1.1 may be). Also this might require some changes in prefs back-end allowing such a behaviour (but this is a wild guess, I'm not familiar with that code).
*** Bug 267724 has been marked as a duplicate of this bug. ***
*** Bug 267963 has been marked as a duplicate of this bug. ***
*** Bug 267849 has been marked as a duplicate of this bug. ***
I set the version back to 0.10 do the update, and then having done the update I reset the value, but it has not stopped the RC2 update notification (app.version is now 0.10.1, though I suspect that maybe it should be 0.10.2) About Firefox confirms that RC2 is installed. Maybe I've done something wrong, but if not then at least the value should reset to the new RC2 version number. (i.e. the default should be updated)
OS: Windows 2000 → All
Ever since I followed the instructions on http://www.mozilla.org/projects/firefox/qa/softwareupdate.html, "Firefox Update" has been acting very strangely. It will get almost to the end and just stop. It keeps working (window is not frozen), but it will not finish no matter how long I wait. It worked fine before the update, so I'm not sure if it is a result of the update or something else. Also, what exactly should the app.version be set to for somebody running 1.0RC2? Does it need to be 1.0, 0.10, or 0.10.1, etc.?
The preference app.version no longer exists on the trunk. This bug only applies to the 1.0 branch.
Version: unspecified → 1.0 Branch
Closing out bugs in old style updater, which are superseded by the new system in 1.5.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.