Closed Bug 267697 Opened 20 years ago Closed 17 years ago

User set app.version doesn't change after update (to RC2 for example)

Categories

(Toolkit :: Application Update, defect)

1.7 Branch
x86
All
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: Maniac, Assigned: bugs)

References

Details

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.
Flags: blocking-aviary1.0?
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
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0-L10N+
Flags: blocking-aviary1.0+
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.
Flags: blocking-aviary1.0-L10N+
Flags: blocking-aviary1.0+
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.
Flags: blocking-aviary1.0?
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. ***
Flags: blocking-aviary1.0? → blocking-aviary1.0-
*** 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
Closed: 17 years ago
Resolution: --- → WONTFIX
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.