297607 - change ua string for Intel-based Macs

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect)

Description

[Josh Aas]

Summary says it all. Right now we would send a hardcoded string with "PPC" in it.

Comment 1

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

I think that for PPC we should leave it as-is, and for non-PPC we should use the
utsname struct equivalent of 'uname -m', and drop the "Mach-O" bit.

Comment 2

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

Attachment: a possible approach (untested)

This attempts to do what I said in the previous comment while sharing as much
code with the Unix ifdefs as possible.

Comment 3

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

It's worth noting that this will automatically change navigator.userAgent and
navigator.oscpu.  navigator.platform is separate, though, and we may or may not
want to change it.

Comment 4

[Josh Aas]

Attachment: list of ua (& js) values from various platforms for reference

This is just for reference, to quickly see what others do. Patch coming up.

Comment 5

[Josh Aas]

Attachment: fix v1.0

Implements the proposed Intel values:
UA String: Intel Mac OS X
oscpu: Intel Mac OS X
platform: MacIntel

I discussed these with dbaron earlier today. They follow historical convention
and Apple's current usage of "Intel" in their Intel Safari UA string. We may
change these UA strings later on in the event that we need to sync up with
Apple again, but this should be good for now. I have filed bugs with Apple and
contacted some people there about keeping values in sync.

Comment 6

[Josh Aas]

We should think about how we want to handle Universal Binaries. Do we want to
indicate arch and UB status? I don't think we need to handle it immediately, but
we should discuss it when we know more about what we want to ship.

Comment 7

[Darin Fisher]

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

MacIntel sounds too vague to me (Intel makes more than just x86 processors!),
but if that's what Apple is using for Safari, then we should too.  sr=darin

Comment 8

[Josh Aas]

MacIntel is not being used by Apple. They have not yet updated that value in
Intel Safari (it still says MacPPC). The reason we decided to use MacIntel is
because of the historical naming convention. Apple almost never says x86, they
use the word "Intel", so we're swapping that in for PPC. I have filed bugs about
this naming stuff with Apple, and they've apparently resolved their issues in
the latest Intel developer build. I'll check it out ASAP and see what they did.

Comment 9

[Darin Fisher]

OK.  Let's hold off on this patch until we know what Apple is going to do. 

Comment 10

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

I think we're better off getting it in and changing it if Apple does something
different; sending incorrect identification is really bad, and we don't want to
accidentally ship something that does that.

Comment 11

[Darin Fisher]

OK, how about MacX86 instead of MacIntel? ;-)

Comment 12

[Josh Aas]

I will land this patch tomorrow with good values. I have the Intel build with
the new strings sitting at my office now.

Comment 13

[Josh Aas]

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

Apple is now using the exact strings used in this patch, so we should stick
with MacIntel.

Comment 14

[Scott MacGregor]

clearing the blocking flag, leaving the patch approval alone

Comment 15

[jhp (no longer active)]

When checking this in, could you also drop the "Mach-O" bit, as dbaron suggested?

Comment 16

[Josh Aas]

Javier: Mach-O already isn't in the Intel AU string in the patch.

+#elif defined (XP_MACOSX) && defined(__i386__)
+    mOscpu.AssignLiteral("Intel Mac OS X");

Comment 17

[jhp (no longer active)]

Ah, misunderstood dbaron's comment.  I was thinking that we should remove
"Mach-O" from the PPC one, since we no longer have any non-Mach-O.

Comment 18

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

No, we should leave it, since there are still *old* versions of Mozilla that are
non-Mach-O PPC, and existing sniffing code may depend on that.

Comment 19

[Josh Aas]

checked in on trunk and 1.8 branch

Comment 20

[Pu7o]

(In reply to comment #18)
> No, we should leave it, since there are still *old* versions of Mozilla that
> are
> non-Mach-O PPC, and existing sniffing code may depend on that.
> 

Why would sniffing code have to send different things whether the version is CFM or Mach-O? Specially now that CFM builds are obsolete...