Closed Bug 297607 Opened 18 years ago Closed 18 years ago

change ua string for Intel-based Macs


(Core :: Networking: HTTP, defect)

Not set





(Reporter: jaas, Assigned: jaas)




(Keywords: fixed1.8)


(2 files, 1 obsolete file)

Summary says it all. Right now we would send a hardcoded string with "PPC" in it.
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.
Attached patch a possible approach (untested) (obsolete) — Splinter Review
This attempts to do what I said in the previous comment while sharing as much
code with the Unix ifdefs as possible.
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.
This is just for reference, to quickly see what others do. Patch coming up.
Attached patch fix v1.0Splinter Review
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.
Attachment #186169 - Attachment is obsolete: true
Attachment #198520 - Flags: review?(dbaron)
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.
Attachment #198520 - Flags: review?(dbaron) → review+
Attachment #198520 - Flags: superreview?(darin)
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
Attachment #198520 - Flags: superreview?(darin) → superreview+
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.
OK.  Let's hold off on this patch until we know what Apple is going to do. 
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.
OK, how about MacX86 instead of MacIntel? ;-)
I will land this patch tomorrow with good values. I have the Intel build with
the new strings sitting at my office now.
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.
Attachment #198520 - Flags: approval1.8rc1?
Flags: blocking1.8rc1?
Attachment #198520 - Flags: approval1.8rc1? → approval1.8rc1+
clearing the blocking flag, leaving the patch approval alone
Flags: blocking1.8rc1?
When checking this in, could you also drop the "Mach-O" bit, as dbaron suggested?
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");
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.
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.
checked in on trunk and 1.8 branch
Closed: 18 years ago
Resolution: --- → FIXED
Keywords: fixed1.8
(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...
You need to log in before you can comment on or make changes to this bug.