Reproducible on: Firefox 45.0a1 using Windows XP STR 1.Download firefox 45.0a1 from http://ftp.mozilla.org/pub/firefox/nightly/2015/12/2015-12-09-03-02-28-mozilla-central/firefox-45.0a1.en-US.win32.zip 2.Double Click on Nightly application. ER Nightly is successfully launched. AR Nightly is not opened. Windows task Manager Status is Not Responding. Additional notes: - Reproducible on: Firefox 45.0a1 from 2015-12-09 and 2015-12-10 under Windows XP 64-bit This issue is a regression: - Last good buildid: 20151208132555 - First bad buildid 20151208203040 - Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ba03ae4ac5df46e044d7120477c635d48fc172d7&tochange=a8965ae93c5d098a4f91ad9da72150bb43df07a7 So, Bug 1079858 caused this regression.
Liz, we should understand whether this will also affect 43.
Does the problem only occur on 64-bit XP? If so, then a) the summary and the platform field need to reflect that, and b) I'm not sure how interested we're going to be in fixing this.
To clarify, I've tried to reproduce on 32-bit XP and was not able to; I just get a normal browser window.
I just blocked updates for XP 64-bit on the nightly channel. Specifically, for: Build Target (exact match): WINNT_x86-msvc-x64 OS Version (partial match, because there are multiple service packs): Windows_NT 5.2
I've also failed to reproduce on an XP x64 service pack 2 virtual machine. Vasilica, can you tell us which service pack your XP x64 machine is on?
Also, Vasicica, can you clarify whether you're talking about the x64 or the Itanium (IA-64) version of Windows XP? Both are referred to as "Windows XP 64-bit".
I was not able to reproduce this issue using Windows XP 32-bit, so it is 64-bit specific. This issue still reproduces on Firefox 46.0a1 (2015-12-14) under Microsoft Windows XP Professional X64 Edition Version 2003 Service Pack 2 (AMD FX(tm)-8320 Eight-Core). I succeed to open it only using the Command Prompt.
Thanks for clarifying the Windows version involved. I can reproduce this bug now, no idea why I couldn't before. I'll add some additional detail: 1) The installer executables, both full and stub, are also affected. 2) Desktop and Start menu shortcuts to an installed copy do *not* appear to be affected; they launch normally. This means hopefully current users should not be affected, unless they need to install a new copy. Continuing to investigate.
Investigation complete. Read on for the details, or TL;DR: I think this is a Windows bug with a fix available in Windows Update. I've found two possible workarounds, either one of which makes the problem go away for me. Vasilica, would you please try these and let me know if they work for you as well? Thanks. 1) Install Windows hotfix KB2808679 from [https://www.microsoft.com/en-us/download/details.aspx?id=39157], even though what it fixes appears to be unrelated OR 2) Open the Explorer properties for the executable that doesn't launch and click the Unblock button at the bottom of the General tab I've also verified that *all* executables with SHA-2 signing certificates are affected, not just the ones that we build. To do that, I made my own self-signed copy of a different binary (I randomly chose the 7-zip installer, which is distributed unsigned), and found that it showed exactly the same behavior. Based on all of that, here's my theory of what's happening: Running the executable (when you haven't done workaround 2) triggers the XP version of the "this file was downloaded from the Internet and can potentially harm your computer" dialog box. That box performs a check of the Authenticode signature so that it can show you the name of the signer (i.e., "Mozilla Corporation"). I think it's that validation process that's failing and stopping the executable from being loaded. This would explain why the files can be run from the command window; it skips that step. It also explains why existing installations are not affected; installed files don't get the special NTFS attribute that triggers the security prompt, only directly downloaded files (that is, the installer and the .zip distribution) have it. Why exactly update KB2808679 fixes this is another interesting question. The knowledge base article states that KB2808679 is a replacement for KB2661254, which does directly impact certificate validation. My guess is that, somewhere between KB2661254 and KB2808679, some other fixes including one for this problem got merged in as well.
Both workarounds solve this problem for me as well. 1) Following the first method, initially appears a security warning and after that the Profile Manager. 2) Following the second method it is displayed only the Profile Manager.
Given the data at-hand, I'm going to make an executive decision and call this bug WONTFIX. We should relnote/SUMO this for Firefox 44 pointing people to the KB. Liz, can you help with the SUMO/relnote bits of this?
Release Note Request (optional, but appreciated) [Why is this notable]: [Suggested wording]: [Links (documentation, blog post, etc)]: Joni, this is definitely something we should write up in SUMO. Matt does this describe the issue correctly: Anyone trying to download and install Firefox (any current version) currently, can't do that on Windows XP (Only service pack 2, or other XP versions?), without using one of the two workarounds? It doesn't sound like this is only an issue for 46/Nightly but for all versions 43 and up.
Note, I meant to say in Windows XP 64-bit.
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #12) > Release Note Request (optional, but appreciated) > [Why is this notable]: > [Suggested wording]: > [Links (documentation, blog post, etc)]: > > Matt does this describe the issue correctly: Anyone trying to download and > install Firefox (any current version) currently, can't do that on Windows XP > (Only service pack 2, or other XP versions?), without using one of the two > workarounds? It doesn't sound like this is only an issue for 46/Nightly but > for all versions 43 and up. Yes, this applies to all SHA-2 signed builds, and existing installs are not impacted. I'm not sure if XP x64 older than SP2 is affected or not; I don't have a way to test that, and our user counts there don't get about the noise floor anyway. I may not have been entirely clear on this part, and I think it's important, so I'll restate it: the update I mentioned is offered by the normal Windows Update procedure. A user does not have to go and get that fix manually, they just have to have installed everything that Windows Update offers.
And to be clear, xp64 is a very unusual platform, and is no longer supported by Microsoft. We have a total of 190k current users. So in terms of overall impact and effort, this is fairly low.
No need to track this as it's a wontfix for 44.
Ben, did you ever unblock Nightly updates on XP x64? They haven't been working for a while. I don't think this bug is a reason to leave them blocked, because I get the impression it doesn't apply to downloads from the updater, and in any case we WONTFIXed it.
(In reply to dagger.bugzilla from comment #17) > Ben, did you ever unblock Nightly updates on XP x64? They haven't been > working for a while. > > I don't think this bug is a reason to leave them blocked, because I get the > impression it doesn't apply to downloads from the updater, and in any case > we WONTFIXed it. Looks like they were still disabled, yeah. I've re-enabled them now.
Sorry for the delay. I think we've already written something up on SUMO for this a while back: https://support.mozilla.org/en-US/kb/firefox-no-longer-works-some-versions-windows-xp
Too late for the release notes