User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release) Build ID: 20140410214046 Steps to reproduce: 1. Tried downloading the latest beta version of Firefox from https://www.mozilla.org/mk/firefox/beta/ 2. The page contains a large green button suggesting the most appropriate action on which it says: Firefox Beta free download (probably because it is localized in my language) Linux*29.0b7*Macedonian(Македонски; localized for my language) 3.Clicked the button so that I would start the download 4. Got a file named firefox-29.0b7.tar.bz2 5. Unpacked the received file 6. Tried to start firefox from the console Actual results: 1. Firefox fails to start displaying the following message: XPCOMGlueLoad error for file /home/petar/Desktop/firefox/libxul.so: libdbus-glib-1.so.2: cannot open shared object file: No such file or directory Couldn't load XPCOM. Is it some bug in the source code? Is i some bug in the binary build? Is it some incompatibility with the operating system? Can't really be sure, as I'm just a regular user. But let's say that I'm not a regular user. So I try to look for this libdbus-glib thing. I open my package manager and look for a package with that name, it my package manager says that not only that my system has such package, but it's olready installed. Confusing, isn't it? It must be a problem with the binary build. So off to the Mozilla's bugzilla to report a bug! Expected results: Firefox should have worked normaly but it didn't. The problem is that I'm using a 64bit version of a Linux distribution, but Mozilla's website offered me a big green button suggesting the most appropriate action to be taken and then dilevered me a 32bit build. How do I know this? I was fortunate to be able to figure this out by muself after being subscribed to bug #723487 (https://bugzilla.mozilla.org/show_bug.cgi?id=723487) when I first hit this problem. Only after someone suggested trying to download the latest build from the Mozilla's FTP site, where there is a clean delimitation between 64bit and the 32bit builds, did I come to conclusion that it wasn;t really my fault that I was trying to use wrong binary build because: 1. From the experience from other websites offering compiled linux software, those websites recognize that I'm using a 64bit version of Linux ant their gren buttons offer a 64bit package/archive 2. To make things less confusing to users, those packages/archives are named with names that usually contain a string that indicates that they are either the 32bit or 64bit build/version of the package/archive For good example of this, try downloading the latest build of LibreOffice from www.libreoffice.org But instead of this, Mozilla has decided only to parse part of the HTTP headers sent to it, so it does know that: 1.I'm using Linux 2. It knows that my first language is Macedonian, although I'm not actualy using a localized version of Firefox. I use the default English-US version, as using computers for 20 years without localization makes using localized software less efficient. So how does it know that it needs to offer the Macedonian localized version? Either from my IP address, or from my Firefox Preferences setting (Firefox Preferences->Content->Languages->Languages in order of preference->1.Macedonian [mk] 2.English/United states [en-us]) (which I doubt regular users even know about). My point is, when a user, expecially a more experienced one like myself, sees that the website does this kind of HTTP request parsing, he(I) also expect that the parser will also take into consideration the User-Agent string telling it that I'm using a 64bit version of Linux and therefore I'm trying to download a 64bit package/archive as this is how things work on other websites (eg. www.libreoffice.com). The second line of defence from making a mistake of using a non working 32bit version on a 64bit Linux would be if the name of the archive delivered to my by Mozilla would contain a string indicating the version - usually x86 for 32bit versions and x86_64 for the 64bit version (there are varieties on this theme, but still...). But atMozilla, both the 32bit version and the 64bit version of the software are named identically. If you download in two different directories, you get identicaly named files(archives) with different sizes. Morover even if I unpack them I can't be sure which is which?! This is not only my problem. The bug #723487 still shows activity from time to time, even though I'm not even sure if the original report had anything to do with using the 32bit vs the 64bit version. I honestly expected that someone should have already fixed this problem, as I believe it requires a minimal (or should I say miniscule) changes to Mozilla's website code but instead I get messages in my email inbox that yeat another user is being confused due to the failure of the webmasters or the UX team to recognize this problem. I leave you with an open question of the number of users that were influenced by this problem, but never found a solution or filed a bug and simply gave up and moved to another browser. It seams that Google's Chrome download page doesn't try to behave like Mr. Smarty pants and offers a list with 4 equaly presented options (if we ignore the order, and the fact that the first one is selected by default): 32bit .deb, 64bit .deb, 32bit .rpm, 64bit .rpm. No big green suggestive buttons there and the file I get is containing "i386" string for the 32bit version, and "amd64" string for the 64bit version of the package (Debian naming convention). Not delivering packages but archives is not an excuse for the confusing naming convention used by Mozilla!

Yes, Bug 809697 fixed the same issue on http://www.mozilla.org/firefox/channel/ The issue on http://www.mozilla.org/firefox/beta/ will be fixed once the page is migrated to the new Bedrock platform.

For what its worth, I ran into the same problem with this page: http://www.mozilla.org/en-US/firefox/aurora/ This page: http://www.mozilla.org/en-US/firefox/channel/ at least shows os=linux64 when I hover over the button (although it still downloads the 32-bit version though).

Yes, this known issue only happens on the older pages: /firefox/beta/ and /firefox/aurora/. We might redirect those pages to /firefox/channel/.

I stand corrected. The Beta page downloaded http://download-installer.cdn.mozilla.net/pub/firefox/releases/29.0b9/linux-x86_64/en-US/firefox-29.0b9.tar.bz2 which is the 64-bit version. (I was expecting to see the x86_64 in the filename)

Doh - just noticed the arrows to change the channel. That seems to be picking the right file for aurora as well.

As per Bug 1005237, /firefox/beta/ will be removed soon. Closing.