Last Comment Bug 297607 - change ua string for Intel-based Macs
: change ua string for Intel-based Macs
Status: RESOLVED FIXED
: fixed1.8
Product: Core
Classification: Components
Component: Networking: HTTP (show other bugs)
: Trunk
: PowerPC Mac OS X
: -- normal (vote)
: ---
Assigned To: Josh Aas
:
Mentors:
http://dbaron.org/www/httpreq
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-13 17:51 PDT by Josh Aas
Modified: 2006-02-04 16:30 PST (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
a possible approach (untested) (3.92 KB, patch)
2005-06-13 18:16 PDT, David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch)
no flags Details | Diff | Splinter Review
list of ua (& js) values from various platforms for reference (1.29 KB, text/plain)
2005-10-04 15:24 PDT, Josh Aas
no flags Details
fix v1.0 (2.56 KB, patch)
2005-10-04 16:10 PDT, Josh Aas
dbaron: review+
darin.moz: superreview+
asa: approval1.8rc1+
Details | Diff | Splinter Review

Description Josh Aas 2005-06-13 17:51:52 PDT
Summary says it all. Right now we would send a hardcoded string with "PPC" in it.
Comment 1 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2005-06-13 18:04:56 PDT
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+2 (mostly busy through August 4; review requests must explain patch) 2005-06-13 18:16:03 PDT
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.
Comment 3 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2005-06-16 17:02:11 PDT
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 2005-10-04 15:24:01 PDT
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.
Comment 5 Josh Aas 2005-10-04 16:10:58 PDT
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.
Comment 6 Josh Aas 2005-10-04 16:38:53 PDT
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 2005-10-13 18:40:59 PDT
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 2005-10-16 18:48:36 PDT
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 2005-10-17 17:38:47 PDT
OK.  Let's hold off on this patch until we know what Apple is going to do. 
Comment 10 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2005-10-17 22:23:31 PDT
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 2005-10-18 00:08:57 PDT
OK, how about MacX86 instead of MacIntel? ;-)
Comment 12 Josh Aas 2005-10-18 00:59:33 PDT
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 2005-10-18 05:00:20 PDT
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 2005-10-18 09:11:07 PDT
clearing the blocking flag, leaving the patch approval alone
Comment 15 jhp (no longer active) 2005-10-18 11:15:20 PDT
When checking this in, could you also drop the "Mach-O" bit, as dbaron suggested?
Comment 16 Josh Aas 2005-10-18 12:29:39 PDT
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) 2005-10-18 12:37:31 PDT
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+2 (mostly busy through August 4; review requests must explain patch) 2005-10-18 12:47:39 PDT
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 2005-10-18 12:49:52 PDT
checked in on trunk and 1.8 branch
Comment 20 Pu7o 2006-02-04 16:30:52 PST
(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...

Note You need to log in before you can comment on or make changes to this bug.