confirming, IE5 and Nav 4.7 return "Win32" while Moz returns "Windows"
Status: UNCONFIRMED → NEW
Ever confirmed: true
Eric, what's your thoughts on this, must have for beta3?
Nom. nsbeta3 and *strongly* recommending that we do this for nsbeta3. (Please escalate back to me for work priorities tradeoff if we don't think we can.) The *only* thing we should be doing for values such as these is providing backward compatibility with the behavior of Nav4 (and IE, where possible) because scripts on the web depend on this and introducing gratuitous incompatibilities only causes Gecko to break on existing content and creates new work for content developers by forcing them to add complex tests to existing code. cc:ing dbaron to see if he has any insight on how these values are being produced (and why we're not currently backwardly compatible with behavior of Nav4) from his work on the user agent string. cc:ing valeski as well for same reason.
I agree. We need to address this. I think mozilla's platform and OSCPU api's impls are actually reversed. Does the correct thing happen if you switch the two js apis?
Status: NEW → ASSIGNED
*** Bug 47982 has been marked as a duplicate of this bug. ***
We're currently doing what the spec outlines (http://www.mozilla.org/build/revised-user-agent-strings.html) for platform values. I believe our logic for sticking w/ this (and I suspect we can find evidence of it in npm.netlib discussions) is/was as follows: Windows machines - the majority of sniffers today will be sniffing platform for "Win" which will hit on 4.x ("Win32"), and 6.0 ("Windows"). Mac machines - the majority of sniffers today will be sniffing platform for "Mac" which will hit on 4.x ("MacPPC"), and 6.0 ("Macintosh"). Unix - these values change so dramatically that it's believed unix falls in the sniffer's "other" bin so n/a. An upside to our new spec is that there will finally be consistent unix values. Bug 7022, which was mentioned above, is a problem accessing the navigator object in JS. However, the values that script is sniffing for indeed would break in 6.0, but keep in mind that is a one off script someone threw together which wouldn't even work in 4.x for long.
Gagan, please own this because navigator.platform asks nsIHTTPProtocolHandler for this information. I'm removing the nsbeta3+ marker so that you can triage this according to your group's priorities.
Assignee: jst → gagan
Status: ASSIGNED → NEW
On second thought, keeping the nsbeta3+ marker on because this is a fairly important bug.
jud could you update this bug with the discussions with ekrock? thx.
A list of what is returned by some browsers I've examined or gotten others to examine is at http://www.people.fas.harvard.edu/~dbaron/tmp/uaresults . The test used is http://www.people.fas.harvard.edu/~dbaron/tmp/uatest .
For those who haven't looked at the links above, I will point out that navigator.platform does not always correspond to a part of the UA string (e.g., on Linux).
Assignee: gagan → dveditz
Per PDT rules P3 bugs are now nsbeta3- Can anyone justify a higher priority (as defined by the PDT?)
Whiteboard: [nsbeta3+] → [nsbeta3-]
Yes, I can. Per the PDT team criteria, this is a P2 bug because it is high profile backwards compatibility, not P3. The PDT team itself is already aware of how much fun it is to break the web's client sniffers--remember the E*Trade fiasco before PR1? Granted, this one is not *quite* as serious as messing up the Mozilla/x.yzw string, but: 1) Not fixing it would introduce a gratuitous backward incompatibility with client sniffers (as in the example already provided) which will break an unknown number of pages--I'd really prefer not to find out how many the hard way! 2) Fixing this is trivally easy, so let's be smart and take the easy fix to avoid backward incompatibilities with platform client sniffers. Setting P2 and clearing [nsbeta3-] for dveditz to re-evaluate on this basis.
Priority: P3 → P2
nsbeta3+ per ekrock
pdt agrees p2
Whiteboard: [nsbeta3+] → [nsbeta3+][pdtp2]
navigator.platform does not always match the user agent. The user agent gives info about what machine the code is running on, the platform was defined to give info about what machine it was *compiled* on. The reason was that in 4.5 we introduced binary patching to SmartUpdate, and we could only patch bits that matched exactly. Windows and macintosh will be easy to make match 4.5+ because they were hardcoded. Unixes will be harder because they were done based on build defines we probably don't use anymore and will be hard to reverse engineer.
There are two js files in xpfe/prefwindow that check navigator.platform == "Windows", so those will have to be changed when we fix this for backwards compatibility. CC'ing Ben.
Patch attached, can anyone review this? As I'm at home today I could not try it on Mac or Linux -- is there anyone who could test this on other systems?
Checked on Linux by sgehani
Whiteboard: [nsbeta3+][pdtp2] → [nsbeta3+][pdtp2]fix in hand
dveditz' patch from <a href="http://bugzilla.mozilla.org/ showattachment.cgi?attach_id=15263">09/21/00 18:43</a> looks good to me. r=scc
Fix checked in.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
dan, this stuff needs to go in around here http://lxr.mozilla.org/seamonkey/source/netwerk/protocol/http/src/nsHTTPHandler.cpp#683 we can't scatter this stuff around as is done in the proposed patch.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
But I didn't want to affect any other client of nsHTTPHandler -- and /especially/ didn't want to affect the user Agent over which many people fought long and hard over the current spec. I only wanted to fix the navigator.platform backward compatibility issue. navigator.platform was never intended to come from part of the user agent, or at least it was not in Communicator 4.x. The "Platform" part of the user Agent for all unixes under 4.x was "X11", but navigator.platform gave which machine archicture Communicator had been compiled for. *NOT* running /on/ like the userAgent.
Dan's right -- can we close this out? /be
I'm closing again because I think this solves the specific problem described in this bug. Jud, feel free to open a different bug that describes the changes you think should be made, if any after my explanation.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago → 18 years ago
Resolution: --- → FIXED
hmm, wrong move IMO. we now have deviation between JS routines and underlying UA implementation. Dan, as you seem to be OK w/ this, UA bugs will now go to you as the one person that's going to remember that this happened :-). Note: the UA string is not backwards compatible. Note2: I personally like the current UA spec as is (and as is currently implemented in the HTTP handler), but it is not backwards compat verbatim.
Verified with 2001-020608.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.