change ua string for Intel-based Macs

RESOLVED FIXED

Status

()

Core
Networking: HTTP
RESOLVED FIXED
12 years ago
12 years ago

People

(Reporter: Josh Aas, Assigned: Josh Aas)

Tracking

({fixed1.8})

Trunk
PowerPC
Mac OS X
fixed1.8
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Assignee)

Description

12 years ago
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.
Created attachment 186169 [details] [diff] [review]
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.
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.
(Assignee)

Comment 4

12 years ago
Created attachment 198511 [details]
list of ua (& js) values from various platforms for reference

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

Comment 5

12 years ago
Created attachment 198520 [details] [diff] [review]
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.
Attachment #186169 - Attachment is obsolete: true
Attachment #198520 - Flags: review?(dbaron)
(Assignee)

Comment 6

12 years ago
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+
(Assignee)

Updated

12 years ago
Attachment #198520 - Flags: superreview?(darin)

Comment 7

12 years ago
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+
(Assignee)

Comment 8

12 years ago
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

12 years ago
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.

Comment 11

12 years ago
OK, how about MacX86 instead of MacIntel? ;-)
(Assignee)

Comment 12

12 years ago
I will land this patch tomorrow with good values. I have the Intel build with
the new strings sitting at my office now.
(Assignee)

Comment 13

12 years ago
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?
(Assignee)

Updated

12 years ago
Flags: blocking1.8rc1?

Updated

12 years ago
Attachment #198520 - Flags: approval1.8rc1? → approval1.8rc1+

Comment 14

12 years ago
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?
(Assignee)

Comment 16

12 years ago
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.
(Assignee)

Comment 19

12 years ago
checked in on trunk and 1.8 branch
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Keywords: fixed1.8

Comment 20

12 years ago
(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.