New mozilla user-agent string

RESOLVED WORKSFORME

Status

()

Core
Networking: HTTP
P3
normal
RESOLVED WORKSFORME
17 years ago
6 years ago

People

(Reporter: dbaron, Assigned: dbaron)

Tracking

Trunk
Future
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

17 years ago
We need to either manually update the mozilla User-Agent string for each release
or make it happen automatically.  Right now we still say M18. :-(
(Assignee)

Comment 1

17 years ago
FWIW, this is the prerelease field.  The patch should, I think, be:

Index: all.js
===================================================================
RCS file: /cvsroot/mozilla/modules/libpref/src/init/all.js,v
retrieving revision 3.199
diff -u -d -r3.199 all.js
--- all.js	2001/01/17 00:13:37	3.199
+++ all.js	2001/01/17 20:51:15
@@ -28,7 +28,7 @@
 pref("keyword.URL", "http://keyword.netscape.com/keyword/");
 pref("keyword.enabled", true);
 pref("general.useragent.locale", "chrome://navigator/locale/navigator.properties");
-pref("general.useragent.misc", "m18");
+pref("general.useragent.misc", "0.8");
 
 pref("general.startup.browser",             true);
 pref("general.startup.mail",                false);
Status: NEW → ASSIGNED
Keywords: mozilla0.8
Target Milestone: --- → mozilla0.8
(Assignee)

Comment 2

17 years ago
I guess it should be m0.8 since the prerelease field is supposed to start with
a letter.  I guess the prerelease field doesn't really fit our current version
scheme.

Comment 3

17 years ago
*** Bug 64698 has been marked as a duplicate of this bug. ***

Comment 4

17 years ago
If we don't want to update the version number manually in the user-agent string
why don't we just call the release "trunk" like it does in the directories in
/pub/mozilla/nightly/ the build id is listed after Gecko/ and it's not a release
so really has no version number. Then for a release the value can be set as
appropriate 0.7, 0.8, 0.9 rather than "trunk"

Like so (slightly modified):

Index: all.js
===================================================================
RCS file: /cvsroot/mozilla/modules/libpref/src/init/all.js,v
retrieving revision 3.199
diff -u -d -r3.199 all.js
--- all.js	2001/01/17 00:13:37	3.199
+++ all.js	2001/01/17 20:51:15
@@ -28,7 +28,7 @@
 pref("keyword.URL", "http://keyword.netscape.com/keyword/");
 pref("keyword.enabled", true);
 pref("general.useragent.locale", "chrome://navigator/locale/navigator.properties");
-pref("general.useragent.misc", "m18");
+pref("general.useragent.misc", "trunk");
 
 pref("general.startup.browser",             true);
 pref("general.startup.mail",                false);

Comment 5

17 years ago
Naming the version "trunk" would really solve the need of manual version update.
However, we may miss seeing the version number around the psychologically
important "1.0". I will repeat my idea (the DUPLO bug) to name the version of
nightly builds "0.7+" after milestone release 0.7, and so on. It needs a manual
cjhange every 5 weeks (or so) but gives some additional important information.
And is consistent with the ancient Mozilla tradition :-)
(Assignee)

Comment 6

17 years ago
Something more consistent with the way we name the builds might be:
 * on the trunk, use "pre-0.8" (e.g., where we are now)
 * on the branch, change to "0.8"

I guess I don't really like the idea of removing the version number for
releases, as the user-agent spec says we should.  (Does 0.8 qualify as a release
rather than a prerelease?)

That would require changing the user-agent spec (again)...
(Assignee)

Comment 7

17 years ago
For reference, the current UA string spec is
http://mozilla.org/build/revised-user-agent-strings.html

Comment 8

17 years ago
Actually after studying the UA string specs, I see we have no field for actual 
version:
- the version.subversion is always 5.0 and seems cast in stone - it's not a 
version of Mozilla as we mean it, rather the generation of browsers
- Gecko version is what we use for the build number and more actually (as the 
specs say)it is: "The Gecko product token allows products that embed the Gecko 
engine, including Mozilla, to identify this significant sub-product." This again 
is not the version of Mozilla (the one that aims at 1.0 as the final product).
- PrereleaseVersion (the one we waste with m18 at present) as the name 
suggests is supposed to be used in pre-release versions only. But this is the 
only field where we may put the real Mozilla version (not 5.0 which is something 
else). 

I believe the US specs need changing. Definitely we need something more 
meaningfull than "trunk". We may drop the field as well as using "trunk" - no 
meaning would be lost. The last milestone has "0.7" (not "m0.7" as the 
PrereleaseVersion.  This means the "String whose first character is [a-zA-Z]" 
rule has been already broken. I believe it may be dropped, unless there is a 
good reason for it. Like "0.7+" I proposed. If not, "pre-0.8" is also a good 
name for the trunk before the next milestone (not as clear for the eye but more 
Linux-like).

Sorry for the long rant but I believe some discussion on this is needed. The UA 
string is the business card of the browser, after all.

Comment 9

17 years ago
Does the mega-patch bug 66480 fix this one as well? I ask because it fixed bug
63102 which seeme to cover a very similar topic.
(Assignee)

Comment 10

17 years ago
This has nothing to do with the installer.
(Assignee)

Updated

17 years ago
Priority: -- → P1

Comment 11

17 years ago
this is typically a build config issue since we usually update the user agent
string for new releases, etc.  I think we already have a bug filed on this, but
I'm not certain.  This is a personal must-fix for 0.8, preferably before the branch.

cc'ing leaf and jj.

Comment 12

17 years ago
related bug Jon refers to is http://bugscape.netscape.com/show_bug.cgi?id=3508
(update version number for mozilla 0.7 and Netscape 6.01 in the Mac "get info" 
string)
I just update the patch to reflect 0.8 and checked it in. That will take care of 
the MacOS "Get Info" window.

Comment 13

17 years ago
is this fixed with
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/modules/libpref/src/init&command=DIFF_FRAMESET&file=all.js&rev1=3.205&rev2=3.206&root=/cvsroot
(Assignee)

Comment 14

17 years ago
Well, the 0.8 branch work is.  Moving to 0.9.   We really do need a better
system for what to call things on the trunk, and we probably need to update the
spec to allow for the version for non prerelease and to begin with a number...
Keywords: mozilla0.8 → mozilla0.9
Target Milestone: mozilla0.8 → mozilla0.9

Comment 15

17 years ago
Good idea, especially as Mozilla0.8 will have probably "0.8" anyway (like the
0.7 milestone was just "0.7"). I've put forward 0.8+ for nightly builds between
0.8 and 0.9. Any takers?
It looks better than pre-0.9. Especially in the About window. Try for yourself
changing it in all.js and then checking chrome://global/locale/about.html
(Assignee)

Comment 16

17 years ago
Asa convinced me that 0.8.1+ is the way to go... it's what we've been using for
a while.  It still disagrees with the UA string spec, though...

We also need to decide if we want to move to "Mozilla/5.1" sometime...

Comment 17

17 years ago
I posted my reasons for moving upto Mozilla/5.1 on n.p.m.seamonkey:
news://news.mozilla.org:119/3AD7C032.5FFE5E38@ukuug.org

Basically I suggested that the bit after the 5. should follow the Mozilla
version number so Mozilla/5.1 would be 1.0, Mozilla/5.11 would be Mozilla 1.1, etc
The main reason I believe we *need* to change the UA before 1.0 is because of
the XUL syntax changes recently applied and any remote XUL written for Netscape
6.0 will break in 6.5 and Mozilla 1.0, Beonex, etc. Read the thread in
.seamonkey for more.

I think if we stick with user agents like Mozilla/5.1 and Mozilla/5.11 we avoid
the chance of breaking dodgy scripts that don't like the idea of a zero padded 3
digit minor version like Mozilla/5.010
In the three-digit format 1.0 would be 5.1(00) anyway. The question is what to 
do about 0.9.1 etc.  5.091 works OK, as long as we never have more than nine 
milestone releases between bumping up the next digit. I have no fear that we'll 
hit 1.0 long before 0.9.10, but one of these days--maybe starting with 
1.0--we'll have a long-lived stable branch where we can't make that guarantee.

We could try a 5.09.1 format, but we did try something like that at one point 
(5.0m13, roughly the format Netscape has used for beta versions except 'm' 
instead of 'b') and sites started rejecting us. The rejection is because 
financial sites tend to reject "unknown" browsers until they reassure 
themselves that it's OK. They appear to do this on a straight strcmp of 
the user-agent version; Netscape communicator has this problem every time we 
bump the "Mozilla/4.7x" user agent.

As a generational marker I could go for changing "5.0" to "5.1" or whatever, as 
long as we don't change it very often and keep the changing sub releases buried 
in the comment.

Speaking of stable branches, we're going to have to do something with the Gecko 
pulldate. The last time we had a long branch (when Netscape shipped 6.0) it 
used Gecko/20001108, but that was a lie because the code had little to do with 
the Gecko of that date. 6.0 was really Gecko/20000922 plus a bunch of fixes.

Branch developers aren't going to want to stick to the same version for the 
life of a long branch though, that's confusing to everyone. With the 
possibility of another Netscape shipping branch coming up, and the likelyhood 
of a mozilla 1.0 "stable branch" we need to figure this out.

My preference would be to use a sub-version that's number of days since the 
branch; it's compact and relatively simple. The main drawback is that people 
think in dates more easily than number of days, but any format that preserves 
the real date is much bulkier.

Netscape's 6.0 and 6.01 ship dates would have been Gecko/20000922.47 and 
Gecko/20000922.131, the typical mozilla milestone might look like 
Gecko/20010418.7

Zero-filled form would be better for mathematical comparisons between *branch* 
builds, but to handle the expected lenght of a potential stable branch we'd 
have to use a lot of digits. date-based forms get even uglier since we'd have 
to leave room for the year just in case we shipped a milestone near the end of 
December. 
> I have no fear that we'll hit 1.0 long before 0.9.10

If the 1.0 definition document is anything to go by, I would not be so sure! ;-)


> Netscape's 6.0 and 6.01 ship dates would have been Gecko/20000922.47 and 
> Gecko/20000922.131, the typical mozilla milestone might look like 
> Gecko/20010418.7

I like it. (A lot.)

Comment 20

17 years ago
I agree with dveditz's comments about the use of the Gecko/ part of the user
agent, his comments about the Mozilla/5.1 jump also make sense and based on what
he says I think we should go for Mozilla/5.1 for the 1.0 release but keep it
like that for any milestone releases (1.1, etc) and then only change it again
for the next major version (2.0) which would be Mozilla/5.2. The distinction
between 1.1 and 1.2 can be left in the pre release field of the comment part.

If we adopt this scheme we should also make 0.9 use the Mozilla/5.1 string if
this is going to still be the recommended beta point for embedders and Netscape
(this is because more people will see a beta release and people would like to
know what user-agent string that Mozilla 1.0 and Netscape 6.5 will be using by
release.

Comment 21

17 years ago
I think its too late in the milestone cycle to fiddle with 
fundemental user agent changes and try and deal with their
possible side effects.  moving this off the 0.9 radar.

Comment 22

17 years ago
regardless of the long term solution, as soon as we branch we need to update the
branch and trunk both.

Comment 23

17 years ago
asa - this bug has been sidetracked into debate hell.  I'd recommend filing a
separate bug to just update the existing user agent as is on the trunk and
branch and set that one to mozilla 0.9.

Comment 24

17 years ago
bug 77185 filed for Mozilla 0.9 user agent update.  pushing this out to 0.9.1 TM
(please forgive the trespass).
Target Milestone: mozilla0.9 → mozilla0.9.1

Updated

17 years ago
Keywords: mozilla0.9 → mozilla0.9.1

Comment 25

17 years ago
updating summary to better reflect bug.  this doesn't need to get done for 0.9.1
or 0.9.2 so moving to 0.9.3.
Keywords: mozilla0.9.1
Summary: Update mozilla user-agent → New mozilla user-agent string
Target Milestone: mozilla0.9.1 → mozilla0.9.3
(Assignee)

Comment 26

17 years ago
Well, if that's what the bug's become (which isn't how it was originally
intended), why did we add "rv:"?

Comment 27

17 years ago
David: Probably because the UA spec (linked to from this page) says about
"PrereleaseVersion" field (presently rv:0.9+ for the trunk):

"String whose first character is [a-zA-Z]. By convention, used to indicate
pre-release versions, such as beta quality software, or milestones. This should
not be present in final release software."

This field is the issue we seem to target in this bug now. By adding "rv:" we
obey the specs. OK. 

So what exactly do we need to do before mozilla0.9.3? Update the specs?
(Assignee)

Comment 28

17 years ago
The original intent of that field was that it not be used for releases.  We
could argue about whether 0.9 or 0.9.1 is actually a release, but I think we've
basically made the decision that it *should* be used for releases.  Since not
all our releases start with "b" (beta) or "m" (milestone) I was thinking we
should drop that restriction from the UA spec and note officially that the field
should be the release version rather than prerelease version only.
(Assignee)

Updated

17 years ago
Priority: P1 → P3
(Assignee)

Updated

17 years ago
Target Milestone: mozilla0.9.3 → mozilla0.9.4
(Assignee)

Updated

17 years ago
Target Milestone: mozilla0.9.4 → mozilla0.9.5
(Assignee)

Updated

16 years ago
Target Milestone: mozilla0.9.5 → mozilla0.9.6
The reason for using "rv:"--an earlier published spec had "prv:"--was to provide
a searchable token that was unlikely to otherwise occur. Without something like
this  reliably pulling the version out of the UA programatically is difficult.

Comment 30

16 years ago
Sorry for the spam, but is there a way to at least modify the user agent via
editing a pref file? I am tired of microsoft not letting me enter some sites
because i am not using internet explorer. That is discrimination
I tried to search for bugs related to this but i did not find something like
"change user agent", but i think i saw some time ago about a way to change it
manually, because no UI was available.
Other browsers like konqueror do this...
(Assignee)

Updated

16 years ago
Target Milestone: mozilla0.9.6 → mozilla0.9.7
(Assignee)

Updated

16 years ago
Target Milestone: mozilla0.9.7 → mozilla0.9.8
(Assignee)

Updated

16 years ago
Target Milestone: mozilla0.9.8 → mozilla0.9.9
(Assignee)

Updated

16 years ago
Target Milestone: mozilla0.9.9 → Future

Comment 31

16 years ago
Should this bug be closed ?
dbaron?
(Assignee)

Comment 33

16 years ago
Still need to do comment 28 and perhaps some other things.
Created attachment 85100 [details] [diff] [review]
Proposed changes to the spec

Ok, well, here's one option.
(Assignee)

Updated

16 years ago
Target Milestone: Future → mozilla1.1beta

Comment 35

16 years ago
The modified spec (attachment 85100 [details] [diff] [review]) still mentions UA's that have values other
than Mozilla/5.0, has it been decided what is going to be done in the future -
are we ever going to increment Mozilla/5.0 in the future?
Somewhere lost in the things drivers are supposed to be deciding is a format for
changing the Gecko part of the token. I think I owe an update of the spec which
I've been too busy to work on, although we did send in a text spec.

I still favor something like my comment 18, but in compromise with the
evangelism team we ended up with something more complicated. It's been posted to
npm.seamonkey a couple of times.

Updated

16 years ago
Blocks: 71569
(Assignee)

Updated

16 years ago
Target Milestone: mozilla1.1beta → mozilla1.2alpha
(Assignee)

Updated

15 years ago
Target Milestone: mozilla1.2alpha → Future
In the almost six years since the last comment above, the User-Agent string has evolved. The current trunk setting for SeaMonkey on my machine, for instance, is "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008033001 SeaMonkey/2.0a1pre". The field this bug was about (between rv:<something> and the closing parenthesis) has disappeared, and a new "Product/Version" has appeared at far right, in this case "SeaMonkey/2.0a1pre".

I believe that everything this bug was about has been taken care of one way or another. If someone thinks this still isn't FIXED, please speak up.

Comment 38

10 years ago
Because it seems obvious this bug is no longer valid I'll take the risk of marking it as WORKSFORME (not FIXED because I did not fix it). If anyone disagrees, please feel free to reopen.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.