navigator.platform returning incompatible strings

VERIFIED FIXED

Status

()

Core
DOM: Core & HTML
P2
normal
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: dannyg, Assigned: dveditz)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3+][pdtp2]fix in hand, URL)

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
Values being returned by JavaScript reference navigator.platform in M16 are 
strings like "Windows" and "Macintosh", but in NN4 and IE4+, there had been 
established a coding that has been incorporated into a lot of existing scripts 
(and in examples that were used to report bugs 7022 and 44285--these bugs may be 
'caused' by the navigator.platform not returning expected values). Values 
returned by navigator.platform should be strings like "Win32" and "MacPPC" etc.

The new navigator.oscpu property is returning the values that _had_ been 
navigator.platform. For compatibility's sake, restore the codes to 
navigator.platform, and do with navigator.oscpu as you like, since it is new with 
mozilla, and it will not step on anything (and doesn't it sound like oscpu should 
include some mention of the CPU family [a la IE's navigator.cpuClass property]?).

Comment 1

18 years ago
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.
Keywords: nsbeta3

Comment 4

18 years ago
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?

Comment 5

18 years ago
Marking nsbeta3+...
Status: NEW → ASSIGNED

Updated

18 years ago
Whiteboard: [nsbeta3+]
*** Bug 47982 has been marked as a duplicate of this bug. ***

Comment 7

18 years ago
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.

Comment 8

18 years ago
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
Whiteboard: [nsbeta3+]

Comment 9

18 years ago
On second thought, keeping the nsbeta3+ marker on because this is a fairly
important bug.
Whiteboard: [nsbeta3+]

Comment 10

18 years ago
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).

Comment 13

18 years ago
->dveditz
Assignee: gagan → dveditz
(Assignee)

Comment 14

18 years ago
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
Whiteboard: [nsbeta3-]
(Assignee)

Comment 16

18 years ago
nsbeta3+ per ekrock
Whiteboard: [nsbeta3+]

Comment 17

18 years ago
pdt agrees p2
Whiteboard: [nsbeta3+] → [nsbeta3+][pdtp2]
(Assignee)

Comment 18

18 years ago
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.
(Assignee)

Comment 19

18 years ago
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.
(Assignee)

Comment 20

18 years ago
Created attachment 15263 [details] [diff] [review]
Proposed patch
(Assignee)

Comment 21

18 years ago
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?
(Assignee)

Comment 22

18 years ago
Checked on Linux by sgehani
Keywords: patch
Whiteboard: [nsbeta3+][pdtp2] → [nsbeta3+][pdtp2]fix in hand

Comment 23

18 years ago
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
(Assignee)

Comment 24

18 years ago
Fix checked in.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 25

18 years ago
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 → ---
(Assignee)

Comment 26

18 years ago
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
(Assignee)

Comment 28

18 years ago
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 ago18 years ago
Resolution: --- → FIXED

Comment 29

18 years ago
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.

Comment 30

18 years ago
Verified with 2001-020608.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.