Closed Bug 10465 Opened 21 years ago Closed 20 years ago

User Agent Components need to be platform/build specific


(Core :: Networking, defect, P3)

Windows NT





(Reporter: jud, Assigned: jud)



(Whiteboard: [PDT+] waiting on UA service checkin, early M14)

Currently the user agent string components are hard coded in
mozilla/netwerk/base/src/nsIOService.cpp. We need a solution that will allow
each platform to set their appropriate fields.
ifdefs are the current "solution" which is broken.
a) ifdef'ing platform specific code in network (xp code) isn't a good idea)
b) most of these pieces aren't ifdefable (language, security level)
*** Bug 6090 has been marked as a duplicate of this bug. ***
There's nothing wrong with idfefs in this context. This is the perfect example
of when you really do want them -- when the implementation has to be different
on different platforms. Using them in an API would be bad, but I don't see any
problem in the implementation.
As far as the platform peice of the UA is concerned; do we have #ifdef's for all
thirty (or whatever the number is) of the platforms we run on?
Could we pick up those platform specific information from external files such as
property files? XPCOM interface, nsIStringBundle (and nsIStringBundleService),
can be used to resolve such problems. For such case, localization note needs
to be provided to L10n group.

Hardcoding shall be used as the last resort.
I see no problem with the following:

#ifdef XP_MAC
#elif defined(XP_WIN)
... others...
#error No agent string for this platform -- developer please add one here.

If there are 30 different strings you need, I'd put this in a header file and
put 30 different #defines in each part of the ifdef.

I don't see why we need a more dynamic solution involving resource files, etc.
but I could be wrong. Would someone ever want to take a Windows build and
operate it with a different agent string? OS/2 maybe?
I don't have a strong feeling about the platform-specific portion of the user
agent string. As long as the locale/language specific portion is localizable,
i.e., not hardcoded. Unfortunately, it appears to be hardwired now:

You need to call nsILocale to get the current app/sys locale instead of
hardcoding it as "en".

This needs to be fixed. Add i18n folks to CC list.
Whiteboard: the language portion is hardcoded now
Add comments to the status Whiteboard.
Target Milestone: M9
Blocks: 10730
*** Bug 6297 has been marked as a duplicate of this bug. ***
tao, how do I get this nsILocale info. I can't find the nsILocale interface
definition anywhere.
tao, what does the nsILocale api look like? I can't find it in lxr. What method
would I call on it to the the lang designation (for example "en")?
Please refer to this method in nsStringBundle

The interface, nsILocale, itself does not provide such method, you'll need to
extract it in your code.

BTW, you can the idlized interface declaration here:
Assignee: valeski → tague
Target Milestone: M9 → M10
I'm not getting any response from Tague regarding how to have i18n set the
language string. I'm assigning this to him for now. I'm also moving this to M10.
We're sending legitimate UA right now, just not totally truthful.
i'll get you some sample code on monday (8/15/99).   i've had other m9 things
that needed to be taken care of.
Assignee: tague → valeski
I checked in a change to nsILocaleService today to add
GetLocaleComponentForUserAgent.  Use this API to get the appropriate locale
component for the user-agent string.

reassiging back to  let me know if you need help hooking
this up.
Blocks: 12562
the language problem is solved, but how would you set a Netscape user agent vs.
the Mozilla user agent?

can this be configurable through some js pref file? I would like to avoid
recompiling at all costs.
Adding to cc list.
Blocks: 12833
PR_GetSystemInfo can provide the following strings based on the system we're on.
Does anyone have a pointer to the old doc that jwz produced regarding UA string
composition? I'm thinking it would be cool to use at least the raw SYSTEM string
in the UA string.

unix defers to uname() and OS2 to its equivelent. mac and win don't produce
release strings.


I've whacked off the language portion of this bug (waiting for tree to open for
checkin). Still mulling the system portion (anyone have any revelations?).

NOTE: Currently the lang piece (on my machine here in the US) comes back as
"en-US". Is this ok? It used to be "en".
Whiteboard: the language portion is hardcoded now → Wan-teh, PR_GetSystemInfo() appears hosed.
Ok. I'm using PR_GetSystemInfo() to set the platform piece of the UA string. My
guess is that this will break some cgis as the format has changed (all upper
case now, and introduction of new platform strings), but this is the right thing
to do and we'll give it a shot.

NOTE: PR_GetSystemInfo is returning WIN95 even though I built on WINNT.

language and new platform code checked in 9/14/99 11:40am
I have no problem with the locale string comming back as en-US.  It makes it
easier to distinguish between other English clients (en-UK, etc.) Anyone else
have a problem?
Target Milestone: M10 → M13
Shouldn't this be done for beta?

Has nspr 3.5 changed anything here?
Depends on: 15738
Srinivas fixed PR_GetSystemInfo() to return the name
of the runtime OS as NSPR bug #15738.  According to
his comments on 10/20/99 06:26 in that bug report,
his fix was checked into the tip of mozilla/nsprpub.
Run this in the location bar:

I got "Mozilla/5.0 [en-US] (Windows_NT; I)". You might try other platforms under
different locale.

I checked some other platforms and locales.
Below is my finding:
Platform/Locale                      userAgent
Windows NT4.0 Japanese             Mozilla/5.0[ja_JP](Windows_NT; I)
Windows 98    Japanese             Mozilla/5.0[ja_JP](Windows_98; I)
Windows 95 Traditional Chinese     Mozilla/5.0[zh_TW](Windows_95; I)
Red Hat 6.0 with Japanese locale   Mozilla/5.0[x-user-defined] (Linux; I)
Bulk move of all Necko (to be deleted component) bugs to new Networking

FYI the user-agent for Mac is inconsistent with 4.5:

user-agent: Mozilla/5.0 [en-US] (MacOS; I)
User-Agent: Mozilla/4.5 (Macintosh; I; PPC)

this is going to break a number of sites

I just noticed valeski asking the jwz user agent string document.
*** Bug 20139 has been marked as a duplicate of this bug. ***
Assignee: valeski → shaver
Whiteboard: Wan-teh, PR_GetSystemInfo() appears hosed.
shaver is going to build a JS UA object that will "do the right thing" wrt these
Depends on: 24336
Whiteboard: waiting on UA service checkin, early M14
Target Milestone: M13 → M14
The UA service uses PR_GetSystemInfo (under the hood), so it should make this
better.  Checking the whole mess in early in M14.
FWIW, current progress has the UA string looking like:

User-Agent: Mozilla/5.0m13 (X11; N; Linux 2.2.5-15ipsec; en-US) Gecko/

on my Linux box.  Locale comes from the locale service, base platform from a
default pref file, etc.
Sorry for my ignorance. Bt, what's the "base platform" you're referring to here?
Is it the system info? In addition, which default pref file it is?

The base platform is "X11", and will be "Macintosh" on the Mac, "Windows" on
Win.  Those settings come from the per-platform pref files: unix.js, winpref.js,

The system info is "Linux 2.2.5-15ipsec", and it comes from the PR_SystemInfo
call, which calls through to uname on Unix and does something similar on the
other platforms.

The "N" (no security) is from all.js, and I would expect it to be set to "I" or
"U" by the installation of an https component.
somewhere in the system info we need to specify architecture (for example
parsing scripts need to differenciate between Linux unix arch and Linux x86
arch). I don't think PR_GetSystemINfo() give us this. I was making a direct call
to uname on unix to get it (per jwz's doc).
PR_GetSystemInfo gives it to us, and I just added it:

User-Agent: Mozilla/5.0m13 (X11; N; Linux 2.2.5-15ipsec/x86; en-US) Gecko/
Since we are already getting some info from the *.js in composing the user
agent string, may I propose that we store the language info in all.js?

Localization group will need to localize this string for each localized build.
I will post it to newsgroup for comments.

How is that better than just getting it from the locale service, as Tague
requested long ago?
The locale info returned by the nsILocale is the system/application locale
which indicates the l10n characteristics of the native OS.

It does not reflect the client's localization characteristics which is to
be revealed by the user agent string for statistical purpose.
OK, I'll make it back to "mozilla.useragent.locale".  Thanks for the info.
*** Bug 23807 has been marked as a duplicate of this bug. ***
Shaver: Are you still working on this, or should it go back to Jud now?
need the user agent to stablize at beta1 so content developers
can start to use it for content negociation.  jud, take this bug
back if your ready to work on it.
Keywords: beta1
PDT+. Back to valeski
Assignee: shaver → valeski
Whiteboard: waiting on UA service checkin, early M14 → [PDT+] waiting on UA service checkin, early M14
not so fast. shaver put a hell of a lot of work into this, and I'm not about to 
re-create it unless I get confirmation from him that he's ditched it. My last 
conversation with him was that he was right no the cusp of checking it in.
Assignee: valeski → shaver
Hi, Jud:

Any idea about Shaver's plan on this bug? We need to decide whether to 
evangelize the U-S string change in beta1.

The lang portion in the app comment is now (once I checkin) a pref 
("mozilla.useragent.locale", en-US). we do not init this field from teh webshell 
init anymore. is this what you want tao?
Assignee: shaver → valeski
Which JS file will contain this pref? And you will use this value to compose
the U-A string?

all.js and yes. is this what you want?
Yes, that's what was decided. Will installer be able to access this value 
during Seamonkey install session? I am under the impression that the prefs value
in JS could be accessed in a very earlier session. 
I have no clue.
ok, platform piece is in. language is localizable via all.js 
"general.useragent.locale", en-US (the default).
Closed: 20 years ago
Resolution: --- → FIXED
setting tever as qa to verify
QA Contact: paulmac → tever
NT 2000021408
You need to log in before you can comment on or make changes to this bug.