Closed
Bug 1318851
Opened 9 years ago
Closed 4 years ago
Firefox updates into 32 bit on top of 64 bit installation
Categories
(Release Engineering :: Release Requests, defect, P3)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: de7ilx, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161104212021
Steps to reproduce:
I updated the firefox 49.0.2 64 bit version into Firefox 50 through "Menu -> Help -> About Firefox".
I use Windows 10 Pro.
Actual results:
Firefox 50 was installed as 32 bit and separate entry in the "Programs and Features".
After installing I had 2 separate installations:
Firefox 49.0.2 64 bit and
Firefox 50 32 bit.
Expected results:
Expected result would have been that Firefox 50 should have been installed as 64 bit as well and on top of the current Installation not separate from Firefox 49.0.2.
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
Summary: Component: Installer → Firefox updates into 32 bit on top of 64 bit installation
Comment 1•9 years ago
•
|
||
I'm unable to reproduce.
1. Install Firefox 49.0.2 64 bit from
http://archive.mozilla.org/pub/firefox/releases/49.0.2/win64/en-US/
2. Update via the about window and restart.
3. Checked in task manager whether Firefox was a 64 bit process
Please install Firefox 49.0.2 64 bit and updating it to see if you can still reproduce.
http://archive.mozilla.org/pub/firefox/releases/49.0.2/win64/en-US/
Flags: needinfo?(de7ilx)
Cannot reproduce anymore neither. Probably was some very odd and rare situation under which such bug came to be. Last couple of versions all were updated through "Menu -> Help -> About Firefox".
Updated•9 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Flags: needinfo?(de7ilx)
Resolution: --- → WORKSFORME
Comment 3•9 years ago
|
||
For what it's worth I had this happen on at least 2 of my computers.
Comment 4•9 years ago
|
||
Was there some possible mis-configuration of the update server, a bug that's been fixed, or do we risk this bug reoccurring on the next cycle?
Just to mention there was one person in reddit who also had same issue:
https://www.reddit.com/r/firefox/comments/5dfhks/firefox_4902_was_64_bit_new_50_installed_as_32_bit/da4m8vd/
The topic is my made but someone in the comments said that same happened to them as well.
Comment 6•9 years ago
|
||
Again, for what it's worth, I'm on the beta channel. I was switched to 32bit during the update from 50 -> 51. This happened on 2 out of 3 computers.
Comment 7•9 years ago
|
||
I could see this happening for systems that have used a version of Firefox that wasn't installed using the installer.
Is that the case for anyone seeing this?
Flags: needinfo?(simon.trigona)
Flags: needinfo?(de7ilx)
Define the "wasn't installed using the installer."? The Obvious way is that first version is installed via Installer and all future ones are installed through the "Menu -> Help -> About Firefox" which I assume is not installed by the installer? If that's what you meant then yes I have installed multiple versions via non installer as through "Menu -> Help -> About Firefox" including the 49.0.2 -> 50.
Comment 9•9 years ago
|
||
I'm in a similar boat, I installed using a regular installed and over the course of time have upgraded through several minor and major releases - maintaining 64bit until this last release.
Comment 10•9 years ago
|
||
I was referring to using a zip version extracted, a copy of an existing install, etc. and nothing in relation to updated installations. Basically running Firefox from a location other than one added by the installer.
Comment 11•9 years ago
|
||
Ah I see. This was definitely installed via an installer.
Flags: needinfo?(simon.trigona)
| Reporter | ||
Comment 12•9 years ago
|
||
Not that I can say. I haven't downloaded any zip file from anywhere. Just the normal installer long time ago from Mozilla website and then I have updated the Firefox through "Menu -> Help -> About Firefox" only.
Comment 13•9 years ago
|
||
I'm not just referring to the one that was installed and converted from 64 to 32 bit. Were there any other locations where Firefox was launched?
Comment 14•9 years ago
|
||
I'm confident I've only ever installed/launched Firefox via any means other than the installer on these machines. One of my affected PC's was a fresh install of Win 10 as of 3-4 months ago.
The profiles themselves may have been brought over/restored from previous installations possibly including a 32bit install.
| Reporter | ||
Comment 15•9 years ago
|
||
Before Firefox got the 64 bit then the Firefox was located in the "C:\Program Files (x86)\Mozilla Firefox"
After the Firefox 64 bit came I uninstalled the 32 bit from "C:\Program Files (x86)\Mozilla Firefox" and 64 bit installed into "C:\Program Files\Mozilla Firefox". That was the only change from multiple versions back. Basically from the time when 64 bit was introduced. After that the Firefox has been launched only from "C:\Program Files\Mozilla Firefox".
Comment 16•9 years ago
|
||
Actually what I thought might cause this has a safeguard in place to prevent that. It is possible that the update server was misconfigured at one point and with it not being reproducible there isn't anything else that can be done.
Updated•9 years ago
|
Flags: needinfo?(de7ilx)
| Reporter | ||
Comment 17•9 years ago
|
||
I also should mention that I have 2 computers and both are on 64 bit Firefox and they are synced via Firefox sync. Only one computer reverted from 64 bit to 32 bit. The other one remained 64 bit. Both are on Windows 10 and are updated in parallel. When coming to Firefox then both are identical in configuration.
| Reporter | ||
Comment 18•9 years ago
|
||
And both were updated almost in same time. Only maybe with 1 minute difference. And only one of them went from 64 bit to 32 bit. If it was update server misconfigured then wouldn't both of them go from 64 bit to 32 bit?
Comment 19•9 years ago
|
||
It depends on whether a background check initiated the update since the background check happens at a time based on each individual installation.
Whatever the case, with there only being one install on these systems there is no way that the client confused one install for another. The client just sends to the update server whether it is a 64 bit build or not which is set at compile time so there is nothing of significance to compute. The update server takes that info to determine whether to serve a 64 bit build or not.
If you haven't re-installed, you can attach your updates.xml and I could check what update the server provided. Otherwise there is nothing more that can be done here without it being reproducible on the client.
Comment 20•9 years ago
|
||
Unfortunately I only thought to check for logs after I had reinstalled 64bit which cleared the logs.
Comment 21•9 years ago
|
||
If this happens again please don't reinstall and comment in this bug. Thanks
| Reporter | ||
Comment 22•9 years ago
|
||
I have this setting on in my settings "Check for updates, but let me choose whether to install them". This time I checked for the update myself through "Menu -> Help -> About Firefox". I didn't wait for the update notification to come up.
But I also don't have any logs because I reinstalled. If it happens again Ill upload my logs here :)
Comment 25•9 years ago
|
||
Rail, Ben, and Nick, I received an email from Avast saying they have reports from users using their updater that have updated a 64 bit install to a 32 bit install. Since they use their own code to create the url that balrog uses to determine that it should provide a 64 bit install this seems to me like it would be an issue on the server side.
Status: RESOLVED → REOPENED
Component: Application Update → Balrog: Backend
Ever confirmed: true
Product: Toolkit → Release Engineering
QA Contact: bhearsum
Resolution: WORKSFORME → ---
Version: 50 Branch → other
Comment 26•9 years ago
|
||
^^
Flags: needinfo?(rail)
Flags: needinfo?(nthomas)
Flags: needinfo?(bhearsum)
Comment 27•9 years ago
|
||
As always, it's much more difficult to diagnose these things without an update URL. If anyone is able to reliably reproduce this, please provide your update logs by:
1) Setting app.udpate.log to True in about:config
2) Opening the Browser Console
2) Going to Help -> About to trigger an update check
4) Copying+pasting the "AUS:SVC" parts of the Browser Console output into this bug.
Information from about:support may be helpful as well.
I did a quick sanity check of Beta and Release updates. For Beta, I constructed a few update URLs
https://aus5.mozilla.org/update/3/Firefox/51.0/20161128075558/WINNT_x86-msvc-x86/en-US/beta/Windows_NT%206.1.0.0%20(x86)/default/default/update.xml (32 on 32)
https://aus5.mozilla.org/update/3/Firefox/51.0/20161128075558/WINNT_x86-msvc-x64/en-US/beta/Windows_NT%206.1.0.0%20(x86)/default/default/update.xml (32 on 64)
https://aus5.mozilla.org/update/3/Firefox/51.0/20161128075558/WINNT_x86_64-msvc-x64/en-US/beta/Windows_NT%206.1.0.0%20(x86)/default/default/update.xml (64 on 64)
Both 32-on-32 and 32-on-64 served http://download.mozilla.org/?product=firefox-51.0b6-complete&os=win&lang=en-US for a complete MAR. I downloaded and unpacked it, and the binaries appear to be 32-bit:
firefox.exe.out: PE32 executable (GUI) Intel 80386, for MS Windows
64-on-64 served http://download.mozilla.org/?product=firefox-51.0b6-complete&os=win64&lang=en-US. Its binaries appear to be 64-bit:
firefox.exe.out: PE32+ executable (GUI) x86-64, for MS Windows
I constructed similar URLs for release:
https://aus5.mozilla.org/update/3/Firefox/50.0.1/20161123182536/WINNT_x86-msvc-x86/en-US/release/Windows_NT%206.1.0.0%20(x86)/default/default/update.xml
https://aus5.mozilla.org/update/3/Firefox/50.0.1/20161123182536/WINNT_x86-msvc-x64/en-US/release/Windows_NT%206.1.0.0%20(x86)/default/default/update.xml
https://aus5.mozilla.org/update/3/Firefox/50.0.1/20161123182536/WINNT_x86_64-msvc-x64/en-US/release/Windows_NT%206.1.0.0%20(x86)/default/default/update.xml
As with Beta, both 32 versions got the same MAR (http://download.mozilla.org/?product=firefox-50.0.2-complete&os=win&lang=en-US) and the binaries inside appear to be 32-bit. The 64-bit version got http://download.mozilla.org/?product=firefox-50.0.2-complete&os=win64&lang=en-US, and the binaries inside appear to be 64-bit.
One thing I noticed while reading https://www.reddit.com/r/firefox/comments/5dfhks/firefox_4902_was_64_bit_new_50_installed_as_32_bit/ is that it claims there is more than one Firefox install in Program & Features. Correct me if I'm wrong, but I don't think this would be the case if an update switched somebody from 64 -> 32. I'm pretty sure that can only happen if the installer is run a second time.
Component: Balrog: Backend → Releases
Flags: needinfo?(bhearsum)
QA Contact: bhearsum → rail
Comment 28•9 years ago
|
||
Hello, used the update button from an Avast Software Update popup about an update to Firefox. It installed the 32-bit Firefox and replaced 64-bit one i had installed. Avast said that is a problem on Mozilla's side and pointed me to this page. Another user's dutch Firefox was converted to English. :(
Comment 29•9 years ago
|
||
(In reply to Lyubomir Parvanov from comment #28)
> Hello, used the update button from an Avast Software Update popup about an
> update to Firefox. It installed the 32-bit Firefox and replaced 64-bit one i
> had installed. Avast said that is a problem on Mozilla's side and pointed me
> to this page. Another user's dutch Firefox was converted to English. :(
Do you happen to know if this ran the installer or not?
Adding some other folks, because it sounds like Avast may be a factor in at least some of these cases.
Comment 30•9 years ago
|
||
For what it's worth - I do not run Avast and experienced this issue on 2/3 of my computers.
I only had the 1 instance of Firefox listed in Programs and Features. The Maintenance Service has a separate listing, but I believe that's normal.
Comment 31•9 years ago
|
||
(In reply to Simon Trigona from comment #30)
> For what it's worth - I do not run Avast and experienced this issue on 2/3
> of my computers.
>
> I only had the 1 instance of Firefox listed in Programs and Features. The
> Maintenance Service has a separate listing, but I believe that's normal.
Yeah, that's totally normal re: the maintenance service. Thanks for the info!
It could be that there's multiple similar bugs here, or maybe some people just have old versions of Firefox installed that are showing up there.
Are you able to reliably reproduce this bug?
Comment 32•9 years ago
|
||
I haven't tried to be honest.. I guess I should install the latest 50.x beta build and see what happens during the update. I'll do that a bit later when I get some work out of the way.
| Reporter | ||
Comment 33•9 years ago
|
||
(In reply to Ben Hearsum (:bhearsum) from comment #27)
> One thing I noticed while reading
> https://www.reddit.com/r/firefox/comments/5dfhks/
> firefox_4902_was_64_bit_new_50_installed_as_32_bit/ is that it claims there
> is more than one Firefox install in Program & Features. Correct me if I'm
> wrong, but I don't think this would be the case if an update switched
> somebody from 64 -> 32. I'm pretty sure that can only happen if the
> installer is run a second time.
That topic there is from me. I had only one 64 bit version installed on programs and files. After checking it manually at "Menu -> Help -> About Firefox" I installed update which installed 32 bit Firefox 50 leaving 2 entries. The update was done once and I don't think the installer was used because through "Menu -> Help -> About Firefox" it just gave button to update which then run some progress bar and then asked browser to restart. After that there was 2 entries. 64 bit Firefox 49.0.2 and 32 bit Firefox 50.
I am not able to reproduce it anymore.
Updated•9 years ago
|
Flags: needinfo?(nthomas)
Updated•9 years ago
|
Flags: needinfo?(rail)
Updated•9 years ago
|
Priority: -- → P3
Comment 34•9 years ago
|
||
In some cases people have installed 64 bit but also ran 32 bit likely due to the installer updating the shortcut. See bug 1342574 for one example.
Comment 35•9 years ago
|
||
Note: this wouldn't be caught by update logging.
Comment 36•9 years ago
|
||
https://www.camp-firefox.de/forum/viewtopic.php?f=7&t=120141&p=1031175#p1031175 describes another potential instance of this.
I'm still really baffled by this bug. I simply cannot come up with an explanation for how an update (that is, a new version of Firefox installed from a MAR) ends up adding an extra Firefox entry to "Programs and Features". I can imagine a scenario where this could happen for people updating through Avast (perhaps they fallback to the installer if the MAR is unavailable, or maybe they have a bug), but I don't see how it can happen for other users unless they ran the installer.
Comment 37•9 years ago
|
||
I talked with one client that thought installing 64 bit automatically removed 32 bit and hence they thought their 64 bit install updated to 32 bit just like in bug bug 1342574.
Comment 38•8 years ago
|
||
Bulk change of QA Contact to :jlund, per https://bugzilla.mozilla.org/show_bug.cgi?id=1428483
QA Contact: rail → jlund
Comment 39•4 years ago
•
|
||
Looks like this bug has gone stale and, given the last few comments, may be explained by firefox 32 and 64 bit both being installed in parallel and causing confusion, so I'll close this as incomplete.
Status: REOPENED → RESOLVED
Closed: 9 years ago → 4 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•