Closed Bug 297607 Opened 16 years ago Closed 16 years ago
change ua string for Intel-based Macs
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.
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.
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.
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 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?
Attachment #198520 - Flags: approval1.8rc1? → approval1.8rc1+
clearing the blocking flag, leaving the patch approval alone
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
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
(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.