489586 - make a decision about 64-bit Mac OS X navigator.userAgent and navigator.platform

Status: RESOLVED FIXED

(Core :: General, defect)

Description

[Josh Aas]

In bug 489280 the question of whether we should have matching UA strings for 32-bit and 64-bit Mac OS X builds was raised. We need to make a decision on this by the time we ship a 64-bit build.

Comment 1

[Makoto Kato [:m_kato]]

Josh, you maybe have to consider navigator.platform, too.
See http://mxr.mozilla.org/mozilla-central/source/dom/base/nsGlobalWindow.cpp

Comment 2

[Josh Aas]

The user agent string for 64-bit Safari 4 on Mac OS X 10.6 is:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6; en-us) AppleWebKit/531.9 (KHTML, like Gecko) Version/4.0.3 Safari/531.9

Comment 3

[Josh Aas]

Attachment: fix v1.0

I propose we match Safari's behavior here. It leave navigator.platform and navigator.userAgent the same between 32-bit and 64-bit builds. This patch modifies navigator.platform to match the 32-bit value and leaves the user agent string alone.

Comment 4

[Josh Aas]

Disclaimer... It seems to me that my "fix v1.0" proposal will work, but consider it a straw man in light of the fact that I'm not very familiar with the details of user agent string use cases.

Comment 5

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

Comment on attachment 402768 [details] [diff] [review]
fix v1.0

I'm ok with this, although it seems to make these a good bit less useful.

An alternative might be to make navigator.platform be "MacIntel64" and make the user-agent have "64-bit Intel Mac OS X" or something like that, so that the 64-bit strings contain the 32-bit ones but can be distinguished.

There are advantages to this approach, though, since it keeps the user-agent string smaller.  If we offered a way to distinguish, I'd rather it be via navigator.platform than via the UA string, since then the people who care can get the information but we don't add additional overhead to every HTTP request.  However, people probably compare navigator.platform using equality rather than substring searches, which makes that painful.

So this sounds fine, at least until somebody complains about it and/or Safari changes.

Comment 6

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

But people can still distinguish 32-bit from 64-bit with navigator.oscpu, right?  If so, then I think we're fine and this is great.

Comment 7

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

Hmmm... actually, they can't, since that uses the piece of the UA string from the HTTP handler.

Anyway, this is probably fine.

In general, I'd rather make the UA string longer only when it's needed for compatibility with something, and when people need new features we should prefer adding APIs for them to get what they want from script.

Comment 8

[Josh Aas]

Thanks David. Pushed to mozilla-central.

http://hg.mozilla.org/mozilla-central/rev/e3fa67bf4fa0

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

This apparently caused a Ts regression, see:

http://groups.google.com/group/mozilla.dev.tree-management/browse_thread/thread/0832f387b12ac48e#

Comment 10

[Mike Beltzner [:beltzner, not reading bugmail]]

But wait - there is *no* way that actually was caused by this patch. :(