530811 - OS Sniffing doesn't support 32 bit browsers on x86_64 platform

Status: NEW

(Bugzilla :: Creating/Changing Bugs, defect)

Description

[u88484]

The OS sniffing done by bugzilla when filing a new bug doesn't detect X86_64 bit hardware and X86 is automatically chosen.

Comment 1

[timeless]

So... are you running a 64bit browser or a 32bit browser? The os detection operates on useragents, please provide the useragents you have which are 64bit.

[NEEDINFO]

Comment 2

[u88484]

(In reply to comment #1)
> So... are you running a 64bit browser or a 32bit browser? 

32 bit browser.

> The os detection operates on useragents, please provide the useragents
> you have which are 64bit.

Here is my useragent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091125 Minefield/3.7a1pre

how would anyone or OS sniffing know if that was 32 or 64 bit?

Comment 3

[Makoto Kato [:m_kato]]

(In reply to comment #2)
> how would anyone or OS sniffing know if that was 32 or 64 bit?

If you use IE, we can detect it from user-agent (ex. on WOW64, it has "WOW64" string. 64-bit version has "Win64" string.).  But other browser such as Firefox and Chrome doesn't have any string for WOW64 and Win64.

Should we implement it to user-agent like IE?  (It is already filed as bug 444770).

Comment 4

[timeless]

kurtz/mkato: when I asked for useragents, I really was asking for useragents, not random speculation.

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MDDC)

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MDDC; Tablet PC 2.0)

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; WOW64; Trident/4.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; InfoPath.2; .NET CLR 3.5.30729; .NET CLR 3.0.30729)

http://msdn.microsoft.com/en-us/library/ms537503%28VS.85%29.aspx has microsoft's relatively unhelpful information on the subject :(

I'm still very skeptical about the benefit.

We generally @bmo use the field to indicate the version of the software that is running. I don't care if you have a 256bit cpu, if you're running a 32bit version of the software, you're probably going to be experiencing bugs based on that version, and 99% of the time the other stuff doesn't matter. otoh if you're running a 128bit version of our software, and are experiencing odd problems, it's probably because you're using mkato's next unstable hacked version, and that's interesting.

Comment 5

[timeless]

Attachment: support for ia64/x86_64

Comment 6

[Frédéric Buclin]

Comment on attachment 430897 [details] [diff] [review]
support for ia64/x86_64

r=LpSolit

Comment 7

[Frédéric Buclin]

Clearing approval per discussion with timeless on IRC. The patch needs to be updated.

Comment 8

[Jesse Ruderman]

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.3) Gecko/20100423 Ubuntu/10.04 (lucid) Firefox/3.6.3

Comment 9

[u88484]

Bug 444770 fixed this for me.

Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a5pre) Gecko/20100503 Minefield/3.7a5pre

Mark as a dupe?

Comment 10

[Frédéric Buclin]

Not a duplicate, but I will let timeless close the bug AS WFM if we no longer need it.

Comment 11

[Jesse Ruderman]

Still doesn't work correctly for me on Linux (see UA in comment 8).

Comment 15

[timeless]

So, most of the 64bit stuff is already present.

what we're missing are two things:
1. a bit of fallback for itanium (not important for normal users)
2. a way for admins to handle the case of a 32bit browser running on a 64bit os

for bugzilla.mozilla.org, what we care about is the build of the browser, not the build of the os. So, we don't actually want 2 to be operative.

For people playing along at home:
1. if you're on linux, we should *already* (at least in upstream bugzilla, not quite certain about bmo) be mapping you to x86_64 if you're using a 64bit os. - if you aren't getting this behavior, please file a bug against me in this component with your useragent.
2. if you're on linux running a 32bit version of a browser on a 64bit kernel, the next patch may or may not change how things work depending on how an admin influences the variable at the top of the patch
3. if you're on windows and using a 32bit browser on a 64bit os, today you're treated as a 32bit creature, and depending on your admin that may or may not change after this patch.

Comment 16

[timeless]

Attachment: handle 32bit browsers on x86_64

(plus a minor bit for ia64)

dkl: i think this should more or less do what we want for bmo and for other browser vendors.

i don't have the energy to change the first hunk of this into a config bit and would hope that i can get a version of this landed and then have someone else convert that bit into a param or whatever.

Comment 17

[David Lawrence [:dkl]]

Comment on attachment 511005 [details] [diff] [review]
handle 32bit browsers on x86_64

Couple comments:

1. [dkl@localhost trunk]$ perl -wcT -I. enter_bug.cgi 
syntax error at enter_bug.cgi line 201, near ""PC")"
enter_bug.cgi had compilation errors.

2. Help me see what $favor_os_over_browser would ever be set to a non-zero value?
I see where you are checking in two places to see if it is true but I can't see where it would be ever set to true. I might be missing it.

Dave

Comment 18

[timeless]

Attachment: handle 32bit browsers on x86_64

sorry about the typo.

as for the other bit, this code only adds the ability to handle the other case.

i'd like to be able to land this now.

once it's deployed, people who care can tweak the value or add code for a Param() to enable their install to take the other path.

Comment 19

[David Lawrence [:dkl]]

Comment on attachment 518013 [details] [diff] [review]
handle 32bit browsers on x86_64

Aside from the unused variable, it looks fine to me for now. You can ask for approval for upstream but will probably be denied til favor_os_over_browser is actually used.

r=dkl

Comment 20

[Frédéric Buclin]

Yes, approval denied for the reason dkl gave above.

Comment 21

[David Lawrence [:dkl]]

timeless, I would like to close this but your patch is still not yet approved. Can you submit a new one that addresses the issue with the unused variable so we can approve it and close this out?

Thanks
dkl

Comment 22

[Frédéric Buclin]

Note that this patch conflicts with bug 307688. It will depend on which one is committed first.

Comment 23

[:glob ✱]

i'm happy to update this patch to fit in with the changes on bug 307688 if timeless doesn't have the time to do so.

Comment 24

[Frédéric Buclin]

(In reply to Byron Jones ‹:glob› from comment #23)
> i'm happy to update this patch to fit in with the changes on bug 307688 if
> timeless doesn't have the time to do so.

glob: just take it. timeless didn't contribute for a long time.

Comment 25

[Frédéric Buclin]

Bugzilla 4.2 is now restricted to security fixes only.

Comment 26

[Frédéric Buclin]

Bugzilla 4.4 is now restricted to security fixes only.