47080 - navigator.platform returning incompatible strings

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect, P2)

Description

[dannyg]

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

[Peter 'Rufus' Nelson]

confirming, IE5 and Nav 4.7 return "Win32" while Moz returns "Windows"

Comment 2

[Johnny Stenback (:jst)]

Eric, what's your thoughts on this, must have for beta3?

Comment 3

[ekrock's old account (dead)]

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.

Comment 4

[Judson Valeski]

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

[Nisheeth Ranjan]

Marking nsbeta3+...

Comment 6

[Johnny Stenback (:jst)]

*** Bug 47982 has been marked as a duplicate of this bug. ***

Comment 7

[Judson Valeski]

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

[Nisheeth Ranjan]

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.

Comment 9

[Nisheeth Ranjan]

On second thought, keeping the nsbeta3+ marker on because this is a fairly
important bug.

Comment 10

[Gagan]

jud could you update this bug with the discussions with ekrock? thx. 

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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 .

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

[Gagan]

->dveditz

Comment 14

[Daniel Veditz [:dveditz]]

Per PDT rules P3 bugs are now nsbeta3- Can anyone justify a higher priority 
(as defined by the PDT?)

Comment 15

[ekrock's old account (dead)]

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.

Comment 16

[Daniel Veditz [:dveditz]]

nsbeta3+ per ekrock

Comment 17

[Michael La Guardia]

pdt agrees p2

Comment 18

[Daniel Veditz [:dveditz]]

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.

Comment 19

[Daniel Veditz [:dveditz]]

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.

Comment 20

[Daniel Veditz [:dveditz]]

Attachment: Proposed patch

Comment 21

[Daniel Veditz [:dveditz]]

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?

Comment 22

[Daniel Veditz [:dveditz]]

Checked on Linux by sgehani

Comment 23

[Scott Collins]

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

Comment 24

[Daniel Veditz [:dveditz]]

Fix checked in.

Comment 25

[Judson Valeski]

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.

Comment 26

[Daniel Veditz [:dveditz]]

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.

Comment 27

[Brendan Eich [:brendan]]

Dan's right -- can we close this out?

/be

Comment 28

[Daniel Veditz [:dveditz]]

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.

Comment 29

[Judson Valeski]

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

[Prashant Desale]

Verified with 2001-020608.