Updating from fxmetro will produce a "Class not registered" prompt message. Once you get that error, you won't be able to launch Firefox as it will keep appearing. This usually doesn't happen when you update from a "fresh" fxmetro installation, but as soon as you open a few tabs and update, you'll run into this every single time. Video of the issue: - http://youtu.be/plHRxfao0tI Steps to reproduce the issue: (video also has step by step instructions) 1) Install "Firefox Setup 28.0b9.exe" 2) Once installed, launch the browser and select "Yes" to make the browser the default (select Firefox from the modal window) 3) Select the "Firefox Menu -> Relaunch in Firefox for Windows 8 Touch" 4) Once fxmetro loads, open three different tabs (I used facebook, twitter, mozilla.org) 5) Close fxmetro by sliding it to the bottom and waiting for the "close" transition to complete 6) Go to C:\Program Files (x86)\Mozilla Firefox\defaults\pref\channel-prefs.js and change the following: - pref("app.update.channel", "beta"); --> pref("app.update.channel", "releasetest"); currently holding the BETA RC with metro removed 7) Click on the Firefox shortcut (this should launch fxmetro as it was the last environment that was used) 8) Once fxmetro opens, slide in the Windows Charm and select "Settings -> About" 9) Let the update process complete and than select "Restart to Update" 10) After you get the blue splash screen, go back to the desktop and click on any of the shortcuts (you'll receive the class error) I've reproduced this three different times going through the above test cases but couldn't reproduce it when updating using fxdesktop rather than fxmetro. I'm note sure how many people will be updating via fxmetro but this has potential to be a nasty issues for those users. They'll basically need to re-install and might end up losing data in the process.

Jim, can you please comment as to how this impacts shipping Firefox 28?

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #1) > Jim, can you please comment as to how this impacts shipping Firefox 28? this blocks. bbondy and I are working on this in the parent bug.

Agreed with Jim.. Users shouldn't be receiving error message once they update the browser through metrofx. Removing metro and making those users download a fresh build isn't a good user experience.

We'll need to get this into a 28.0 build #2 in that case, asap. Please ping in IRC when there's something reviewed that can be uplifted so we can stay on top of timing.

The timing here seems to play into things. For example if I follow the steps below and have proc mon running with the top level filters checked (registry, thread and processes, file access) such that this info is getting dumped into the main list view, this will slow things down enough that I rarely get a a failure. steps, this can be a pave over or fresh install after an uninstall: 1) set ie as the default 2) install the metro enabled build off oak - http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/03/2014-03-07-04-02-01-oak/ 3) run proc mon, deselect all the toolbar filters 4) open desktop, set as default via the windows prompt 5) switch to metro 6) open about, do the update, hit restart at this point, you get the empty splash, which we've come to understand is the result of the old updater trying to launch metro. you can flip to desktop and open the task manager and there will be a Nightly process running. Windows has found the new firefox.exe and has launched it thinking it's a metro browser here. If you wait about ten seconds, that process will terminate and you can test the desktop shortcuts. Sometimes they work, sometimes they don't. I'm still trying to catch a good failure case in proc mon to diagnose.

So I've captured a proc mon log for a failed helper but it's not much help. The process appears to launch, initialize within the system and then just exits. One odd thing I notice is that right about the same time helper.exe exits, I see the process maintenanceservice_tmp.exe run. bbondy any ideas what that might be doing? Immediately after helper exits, firefox launches with the command line: Command line: "C:\Program Files (x86)\Nightly\firefox.exe" -ServerName:DefaultBrowserServer which is the old updater is doing the metro launch that generates the empty splash.

So I'm not sure if we get into execution of our nsis script or not when helper launches, but we could investigate this by throwing up a dialog early on startup [1]. One thing I've noticed is that the exit code for helper is different between the successful session 0 run and the session 1 run, in session 0 the exit code is 2, in session 1 it's 1. I haven't tracked down the difference, but I'll bet we could sort that out by poking through the nsis source. One place we might bail early is in UninstallUnOnInitCommon where we check ${FileExists} "$INSTDIR\${FileMainEXE}" [2]. [1] http://mxr.mozilla.org/mozilla-central/source/browser/installer/windows/nsis/uninstaller.nsi#681 [2] http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/installer/windows/nsis/common.nsh#5408

Found this for exit codes on some web site, doesn't seem to match up to anything. •0 - Normal execution (no error) •1 - Installation aborted by user (cancel button) •2 - Installation aborted by script

Doing a bunch of message boxes through init and into post update I think makes sense as the last step. The tmp stuff is the maintenance service installer running the tmp maintenance service with a param to do a version compare. If the new maintenance service is newer it gets replaces. If not it doesn't. I don't think that's related.

At this point it's looking unlikely we will have a fix in time and we will have to take on the unfortunate circumstance of breaking the updates (in metro mode) for those users on beta who do update that way. This should be a relatively small number and hopefully, being beta users, they will be able to re-install beta manually (or switch to another channel) to continue to use Firefox.

Update: I added a series of dialog boxes at the start of helper.exe. If you update from Desktop, you can leave it showing these message boxes for any amount of time, and press OK to them to proceed with the PostUpdate process. If you update from Metro, you display the message box, and it will kill your process while the message box is up. I suspect that Windows sees that our process is linked to Metro, and possibly that we no longer have a Metro browser, so it kills us. Or we just take too long to finish executing and Windows kills us (In which case it would be an existing problem we just never knew about) This is what we can do to fix the problem with high probability: A session 0 SYSTEM process has the ability to impersonate a token and launch a process. It is also unrelated to Metro so Windows wouldn't kill it. We can have session 0 enumerate all non 0 sessions and launch helper.exe with each user's token that it finds. This would successfully remove the registration for any logged on session and wouldn't be killed. If we want to do this work, I think it's about 1-2 days of work and I think it has a high probability of fixing it. We may find a different route by debugging more though. Jim and I are still trying some things. Thoughts?

Out of curiosity, can you remove the key that causes this as the very last action in PostUpdate?

> Out of curiosity, can you remove the key that causes this as the very last action in PostUpdate? That's one of the things we're looking into now. Jim and I are checking whether the killing is related to us removing metro bits (new problem) or whether it's related to us just taking too long (existing problem). If it's a new problem and relating to Metro bits that's one of the things Jim and I were discussing on IRC about trying. If it's an existing problem, that won't help us here.

If it is due to taking too long then you might be able to make it the first thing it does. iirc there are a decent amount of cleanup actions in Post Update that could be moved to the end as well that won't cause harm if they don't run.

If we're on the right track, and ordering around doesn't help, the summary of API calls discussed above are: WTSEnumerateSessions For each session: WTSQueryUserToken CreateProcessAsUser helper.exe /PostUpdate

I'm not against it though that would require two updates since the code that launches the helper will need to be updated. I'll put in my 2 cents after we know the answer to comment #13

We could do the steps in Comment 15 from within helper.exe running as session 0. So would only be 1 update. But we'll discuss more once we know more.

As long as the process isn't killed too quickly for whatever reason.

The session 0 one will never be killed by windows because it's not related to Metro, it's launched as a independent process from the service.

Forgot about that. Thanks!

What about the non-service case?

It's ok for the non service case to run twice. It would run first from the session 0 spawn and then again after. But we'd remove the non service case for the subsequent updates. Or just leave it and do this session stuff just once.

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #14) > If it is due to taking too long then you might be able to make it the first > thing it does. iirc there are a decent amount of cleanup actions in Post > Update that could be moved to the end as well that won't cause harm if they > don't run. I don't think it's a time out issues. In the beta testing I did with proc mon, helper dies before it had a chance to execute the first file related activity in UninstallOnInitCommon. The thing I'm wondering about is does this have something to do with the old updater trying to launch metro after the supporting browser has been replace. We launch helper.exe, and then immediately try to launch the browser while helper is still running. LaunchWinPostProcess is called with false for forceSync, so we don't wait.

The test code we have cooking on oak right now will narrow this down, so we should know more tomorrow.

Let's also try putting sync to true to see if it is indeed when Windows tries to launch the browser and sees it has no DEH so kills us: http://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/updater/updater.cpp#2795 After your current test I mean. Should I do the session enumeration stuff in the meantime? And we'd use it if we don't find a better solution?

(In reply to Brian R. Bondy [:bbondy] from comment #25) > Let's also try putting sync to true to see if it is indeed when Windows > tries to launch the browser and sees it has no DEH so kills us: > http://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/updater/ > updater.cpp#2795 We're updating with the old updater though, so we can't flip this in release. Maybe we should try flipping it in the ini file instead. http://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/common/updatehelper.cpp#79 > Should I do the session enumeration stuff in the meantime? And we'd use it > if we don't find a better solution? if we still get killed after we test disabling the unregister stuff in session 0 in the oak builds, then I think our guess about windows killing us after the launch is spot on. In which case doing the helper stuff sync is probably our best bet.

(In reply to Jim Mathies [:jimm] (away 4/1-4/21) from comment #26) > (In reply to Brian R. Bondy [:bbondy] from comment #25) > > Let's also try putting sync to true to see if it is indeed when Windows > > tries to launch the browser and sees it has no DEH so kills us: > > http://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/updater/ > > updater.cpp#2795 > > We're updating with the old updater though, so we can't flip this in > release. Maybe we should try flipping it in the ini file instead. > > http://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/common/ > updatehelper.cpp#79 to the ini to patch it. Doh! Yep. I don't think we can do it via INI because that function writes to the ini just before executing it. > > > Should I do the session enumeration stuff in the meantime? And we'd use it > > if we don't find a better solution? > > if we still get killed after we test disabling the unregister stuff in > session 0 in the oak builds, then I think our guess about windows killing us > after the launch is spot on. In which case doing the helper stuff sync is > probably our best bet. It may be useful to do even if we guessed spot on in case we can't find a solution to fix it, as a contingency plan. I'm just not sure if it's worth the resources to do that though. We may just end up saying that people won't hit this too commonly because metro isn't used a lot and not fix it.

Not sure if this is what you are talking about but the updater reads the updated ini file just as it launches the updated helper based on the value in the ini file so the old updater would run it sync if it set in the updater.ini. Of course, that would slow down startup after update.

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #28) > Not sure if this is what you are talking about but the updater reads the > updated ini file just as it launches the updated helper based on the value > in the ini file so the old updater would run it sync if it set in the > updater.ini. Of course, that would slow down startup after update. Looking at the flags: http://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/common/updatehelper.cpp#78 I don't see these values in the file we have checked in: http://mxr.mozilla.org/mozilla-central/source/browser/locales/en-US/updater/updater.ini I'm wondering if we can flip this somehow through a checkin when we do the update from metro to non-metro, then somehow flip it right back on the next non-metro update.

Ok found this, which is where I think we can add it. We just need a way to flip it back once this specific update has occurred. We can test our "sync flag fixes the world" theory on oak next.

This is updater code so such a fix only really helps us determine if we're right about launching the browser is what's causing the problem.

I think this theory is looking more sound. The latest oak builds have in them: 1) no session 0 de-registration 2) updater.cpp output debug string output throughout the update process 3) dialog on helper start in session 1 4) lots of output debug string output during post update On three different test runs with DbgView up on split screen while the metro browser updates, I've seen: 1) updater completed update, visible helper dialog, accepting this and completing the post update. 2) helper launched bu no dialog, updater killed while in LaunchCallbackApp 3) helper launched, helper dialog displayed, updater and helper killed during LuanchCallbackApp updater's LuanchCallbackApp seems to be the trigger for early process termination.

(In reply to Jim Mathies [:jimm] (away 4/1-4/21) from comment #31) > Ok found this, which is where I think we can add it. We just need a way to > flip it back once this specific update has occurred. > > We can test our "sync flag fixes the world" theory on oak next. Missed posting the link of what I found - http://mxr.mozilla.org/mozilla-central/source/browser/installer/windows/nsis/updater_append.ini#7

Pushed sync helper launch to oak for testing. bbondy pointed out yesterday on irc that if the removal of files like CommandExecuteHandler is the trigger, we're basically sol unless we find a way to remove registration prior to the updated browser being moved over. However if the trigger is the LaunchCallbackApp call in the old updater, the sync helper change should fix this.

Here's the code that launches a subprocess in each logged on user session. (This is only possible from session 0 system processes) I Just need to convert it to NSIS and launch helper.exe /PostUpdate instead of this. I think we're just going this route if the sync launch doesn't help things. But I just wanted to give an update. > WTS_SESSION_INFO *pSessionInfoStart = nullptr; > DWORD count; > if (WTSEnumerateSessions(WTS_CURRENT_SERVER_HANDLE, 0, 1, &pSessionInfoStart, &count)) { > for (int i = 0; i < count; i++) { > WTS_SESSION_INFO *pSessionInfo = pSessionInfoStart + i; > if (pSessionInfo->SessionId != 0) { > HANDLE session; > if (WTSQueryUserToken(pSessionInfo->SessionId, &session)) { > > STARTUPINFOW si = {0}; > si.cb = sizeof(STARTUPINFOW); > si.lpDesktop = L"winsta0\\Default"; > PROCESS_INFORMATION pi = {0}; > > CreateProcessAsUserW(session, L"C:\\windows\\system32\\calc.exe", > L"", nullptr, nullptr, FALSE, 0, nullptr, nullptr, > &si, &pi); > CloseHandle(session); > } > } > } > for (int i = 0; i < count; i++) { > WTSFreeMemory(pSessionInfoStart + i); > } > }

So looks like the theory was wrong. With the syn change, post update runs and exits, then the old updater tries to launch the browser and we get an empty splash with nor browser. After closing that, I'm still seeing the "Class not registered" error prompt for a taskbar shortcut. Part of the problem was the registration code not executed, but now that we've found a way to make sure that happens, seems we still have an issue with explorer trying to instantiate the missing delegate execute handler.

(In reply to Jim Mathies [:jimm] (away 4/1-4/21) from comment #37) > So looks like the theory was wrong. With the syn change, post update runs > and exits, then the old updater tries to launch the browser and we get an > empty splash with nor browser. After closing that, I'm still seeing the > "Class not registered" error prompt for a taskbar shortcut. > > Part of the problem was the registration code not executed, but now that > we've found a way to make sure that happens, seems we still have an issue > with explorer trying to instantiate the missing delegate execute handler. s/syn/sync s/nor/no

(In reply to Jim Mathies [:jimm] (away 4/1-4/21) from comment #37) > So looks like the theory was wrong. With the syn change, post update runs > and exits, then the old updater tries to launch the browser and we get an > empty splash with nor browser. After closing that, I'm still seeing the > "Class not registered" error prompt for a taskbar shortcut. > > Part of the problem was the registration code not executed, but now that > we've found a way to make sure that happens, seems we still have an issue > with explorer trying to instantiate the missing delegate execute handler. This might be a side effect of disabling the helper run in session 0. What I think we need to do here is unregister local machine config in session 0, and current user in session 1 (sync). Looking through my registry I'm seeing local machine config left behind with the current test builds.

Looks like this is working. launching via shortcuts works as expected. The only negative side effect is we still get the blank splash screen on restart. Builds - http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/03/2014-03-14-08-06-36-oak/

I don't know if this is related, but since updating to today's (2014-03-25) nightly build, i get a "Class not registered" error whenever I try to launch Nightly from the desktop shortcut (not metro) in Windows 8.1). The only way I can launch it is via the "Run" command (WindowsKey+R).

Confirmed: 2014-03-24 build works, 2014-03-25 build is broken.

Oh and launching URLs from other apps also no longer works, falls back to IE because Nightly barfs.

(In reply to Marco Zehe (:MarcoZ) from comment #41) > I don't know if this is related, but since updating to today's (2014-03-25) > nightly build, i get a "Class not registered" error whenever I try to launch > Nightly from the desktop shortcut (not metro) in Windows 8.1). The only way > I can launch it is via the "Run" command (WindowsKey+R). We tried to avoid that in the patches that landed but maybe we missed a corner case. Best work around I think would be to uninstall/reinstall. Can you try that and see if it clears things up?

There is probably some fallout relating to multiple installs in respect to removing the DEH component. Please try to open from c:\program files .exe file and then set the default again.

Hi Marco can you confirm if setting the default fixes it for you? I think this is related to multi installs. I'd like to close this as a dupe of 981166 but it would be good to determine a work around for those affected in this bug and add it to the whiteboard.

Updated Nightly today and hit this.

Hi Kyle, could you try opening firefox.exe from the install path, then set the default to Firefox from within Firefox? If Firefox is already the default then try setting IE as the default first, and then back to Firefox. Does that fix the shortcut?

Also note this error will also come up if you started with a zip install. I think setting default away from Firefox and back on Firefox will fix it.

(In reply to Brian R. Bondy [:bbondy] from comment #48) > Hi Kyle, could you try opening firefox.exe from the install path, then set > the default to Firefox from within Firefox? If Firefox is already the > default then try setting IE as the default first, and then back to Firefox. > > Does that fix the shortcut? No, I tried a variety of handler fixes; it was a no-go. (In reply to Brian R. Bondy [:bbondy] from comment #49) > Also note this error will also come up if you started with a zip install. > I think setting default away from Firefox and back on Firefox will fix it. I used the installer when Nightly died like this last time.

Yeah, this is still totally busted. The application no longer errors out, but nothing else can use it.

(In reply to Brian R. Bondy [:bbondy] from comment #45) > There is probably some fallout relating to multiple installs in respect to > removing the DEH component. Please try to open from c:\program files .exe > file and then set the default again. That definitely does not fix the issue. I tried that first thing when encountering this problem and finding this bug.

(In reply to Jim Mathies [:jimm] (away 4/1-4/21) from comment #44) > We tried to avoid that in the patches that landed but maybe we missed a > corner case. Best work around I think would be to uninstall/reinstall. Can > you try that and see if it clears things up? It doesn't. neither does setting IE as the default and then letting Nightly, launched from the Run dialog, re-set itself as the default. All to no avail. Current nightly on Win 8.1 is completely broken for me. Even when it's running from the Run dialog, other apps can't manage to pass web site URLs to it any more. They simply open in IE even though Nightly clearly shows up in the Default Programs, and the option to set it as the default is grayed out in Settings/Advanced.

Does installing on top fix the issue?

Sorry missed that second reply.

Possibly what's happened is you have a taskbar icon link pointing to your installation path but with the wrong app user model ID in it, pointing to a location in registry that wasn't cleaned. A work around for now is just to create a new shortcut from your installation path and drag it onto your taskbar.

(In reply to Brian R. Bondy [:bbondy] from comment #54) > Does installing on top fix the issue? Nope. (In reply to Brian R. Bondy [:bbondy] from comment #56) > Possibly what's happened is you have a taskbar icon link pointing to your > installation path but with the wrong app user model ID in it, pointing to a > location in registry that wasn't cleaned. a) I'm trying to launch from the *desktop* icon, not a taskbar one. b) That desktop icon was completely removed when I uninstalled Nightly. c) The newly created desktop icon of the new installation exhibits the same problem.

Here's something you can try - uninstall whatever you have installed. Then install/uninstall with an older build prior to 2014-03-25. Then install the latest build.

(In reply to Jim Mathies [:jimm] (away 4/1-4/21) from comment #58) > Here's something you can try - uninstall whatever you have installed. Then > install/uninstall with an older build prior to 2014-03-25. Then install the > latest build. OK here's what I tried: A. Uninstalled both Nightly and Firefox Release. B. Installed 2014-03-24 Nightly. 1. Got a message near the end of the installation that said "an app for the http protocol was installed". Some sort of app notification bubble possibly down at the bottom of the screen, my screen reader didn't tell me where. 2. Launched that instance. I was asked to confirm to make Nightly my default browser. 3. I then got a Windows dialog asking me what http should be opened with. The options were "Keep IE", "Nightly", and "Look for app in Store". I chose Nightly. 4. Updated to latest nightly via the auto updater. Result: Desktop shortcut broken, "no class registered". C. Uninstalled, then reinstalled that same 2014-03-24 nightly build. 1. Steps B.1 to B.3 went as before. 2. I then did not do the auto-updater, but the downloaded full install of 2014-03-25 on top of the other one. Result: Same. "No class registered". D. Uninstalled Nightly, then reinstalled the 2014-03-24 build without launching it. The message from B.1 appeared. 1. Uninstalled that build straight away. 2. Installed the 2014-03-25 build and got the same message as in B.1. 3. Launched that build and was asked to make it my default browser. 4. Also got the Windows message with the same options as in B.3. 5. Closed that build after the start page appeared and tried to relaunch. Result: "Class not registered".

I got this error today, but I noticed it only came up when launching Nightly from a shortcut (opening firefox.exe directly wouldn't trigger it). I just manually replaced all shortcuts (Start screen and taskbar) with new ones I also created myself and the popup was gone.

Marco, do you have other repos installed on the system (aurora, beta, release)?

(In reply to Gustavo Silva from comment #60) > I got this error today, but I noticed it only came up when launching Nightly > from a shortcut (opening firefox.exe directly wouldn't trigger it). I just > manually replaced all shortcuts (Start screen and taskbar) with new ones I > also created myself and the popup was gone. Thanks for the report.

(In reply to Jim Mathies [:jimm] (away 4/1-4/21) from comment #61) > Marco, do you have other repos installed on the system (aurora, beta, > release)? I had release installed, but along with Nightly, uninstalled it to make sure I had no Firefox on my system whatsoever.

One additional piece of info: If I right-click the desktop icon and tell it to run as administrator, everything works. If I then again just double-click it or focus it via the keyboard and press Enter, which executes it with normal user privileges, I get the "class not registered" error again.

marco - two question, after an uninstall, curious if you've tried a simple reboot? It's a long shot but you never know. second, when you install nightly, do you install it into the default location?

No avail whether I reboot after the uninstall, the install, or both. I install into C:\Program Files (X86)\Nightly as given by the installer. It's a Windows 8.1 X64 system.

Is it possible, if it exists, to delete the reg key: HKEY_CURRENT_USER Software\Classes\EEFEA8717BC47F65

(In reply to Brian R. Bondy [:bbondy] from comment #67) > Is it possible, if it exists, to delete the reg key: HKEY_CURRENT_USER > Software\Classes\EEFEA8717BC47F65 It was there, I deleted it, but it made no difference, the error still occurs.

Thanks for troubleshooting with us, I know it's a pain. Is there one in HKEY_LOCAL_MACHINE too?

Can we get this backed out later today so more users don't fall victim to this over the next 5 automated snapshots? bsmedberg seemed to indicate a 3 day lag before applications, which most certainly will destroy most of the user-base over the weekend.

Note: this is definitely not affecting everyone since I have the same specifications as this bug and have not experienced it and several people on the metro team also have the same specifications without experiencing it. Having said that, figuring out how big the impact is and what - if any - the work around and / or fix is would be a good thing before it hits people on beta and aurora.

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #71) > Note: this is definitely not affecting everyone since I have the same > specifications as this bug and have not experienced it and several people on > the metro team also have the same specifications without experiencing it. > Having said that, figuring out how big the impact is and what - if any - the > work around and / or fix is would be a good thing before it hits people on > beta and aurora. I'm all for breaking Nightly. However, in previous bugs bsmedberg claimed no one works on the weekends, so leaving a landmine in trunk seems kind of bad if no one's present.

Which is why I said "before it hits people on beta and aurora". Put another way, without the understanding I stated in comment #72 this should not hit people on beta or aurora and if it requires a backout so be it.

(In reply to Kyle Sanderson from comment #70) > Can we get this backed out later today so more users don't fall victim to > this over the next 5 automated snapshots? bsmedberg seemed to indicate a 3 > day lag before applications, which most certainly will destroy most of the > user-base over the weekend. As far as potential user-base impact goes, between mc, ma, and mb, we have about 400K users running win8, and our testing indicates most shouldn't have an issue. Thus far we only have two reports of problems. If that gets worse over the next couple days we can consider pulling it. Aurora will go out tomorrow which should help improve test coverage.

(In reply to Marco Zehe (:MarcoZ) from comment #68) > (In reply to Brian R. Bondy [:bbondy] from comment #67) > > Is it possible, if it exists, to delete the reg key: HKEY_CURRENT_USER > > Software\Classes\EEFEA8717BC47F65 > > It was there, I deleted it, but it made no difference, the error still > occurs. I'm still stumped as to how this was left behind. http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/installer/windows/nsis/common.nsh#7798 We explicitly delete this key in the unregister routine.

I think maybe his installation path is hashing to a different value perhaps? If there is no HKLM entry matching that, then this would be the most plausible explanation. If HKLM entry exists, and the path does indeed hash to that ID, then deleting it should fix the problem.

(In reply to Jim Mathies [:jimm] (away 4/1-4/21) from comment #74) > Aurora will go out tomorrow which should help improve test coverage. I believe you just confirmed the problem. (In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #73) > Which is why I said "before it hits people on beta and aurora". Put another > way, without the understanding I stated in comment #72 this should not hit > people on beta or aurora and if it requires a backout so be it. If you're willing to do so on the weekend, excellent. All I'm seeing though is at least four more broken snapshots. I realize most Mozillian's are hopefully sane, but did anyone experiencing this do the upgrade to 8.1 from 8? or is it a mixture?

The next beta will be built today and will most likely go out either tomorrow or Friday morning.

(In reply to Brian R. Bondy [:bbondy] from comment #69) > Thanks for troubleshooting with us, I know it's a pain. > Is there one in HKEY_LOCAL_MACHINE too? Yes there was. After deleting it, Nightly again starts from the desktop shortcut. I am still seeing a problem with launching URLs e. g. from Thunderbird. But maybe I can re-declare it as standard browser now without breaking things.

marcoZ one more thing that can help us if you don't mind checking. Do you have an <installation_path>\uninstall\uninstall.log file?

(In reply to Brian R. Bondy [:bbondy] from comment #82)

Here is mine.

Additional info: Uninstalling the 2014-03-25 build and reinstalling it from the full install put both keys back in its place, again breaking the desktop launch icon. Removing them fixed the issue. The automatic update to 2014-03-26 build then only put the one under HKEY_CURRENT_USER back in place, not the one under HKEY_LOCAL_MACHINE.

Oh and yes, they always need to both be removed for the desktop shortcut to work, so every update currently breaks things even when the key is only put back for HKCU.

In case anyone was wondering, this did indeed impact more users over the weekend (to which no developers responded). bug 988927 I still don't see the impact of breaking installations when no one's working.

(In reply to Kyle Sanderson from comment #87) > In case anyone was wondering, this did indeed impact more users over the > weekend (to which no developers responded). bug 988927 > I still don't see the impact of breaking installations when no one's working. The report is for aurora, and the fix landed on aurora on Wednesday. Not over the weekend. The reports happened on Thursday and Friday. The real problem here is that the bug was reported to the wrong component, and not linked to the existing bug as a duplicate or as a dependency. There are hundreds of thousands of bugs in bugzilla and no one knows about each of them.

Brian, do we see a potential fix for this bug in 29? (if it is still relevant) Thanks

I think there have only been a few cases of this reported and I think those are edge cases that have been worked around. I'm marking this as a dupe of bug 981166.

Removing the "verifyme" keyword as this was tested and documented in Bug #981166.

Setting the status flags to match bug 981166 as per comment 92.

My firefox nightly has been broken from a "task bar pin" shortcut for a while now (at least a month or so) so I finally was bothered to attempt to resolve the issue. To fix the issue I simply deleted the - HKLM\Software\Classes\EEFEA8717BC47F65 registry key. Note that HKEY_CURRET_USER\Software\Classes\EEFEA8717BC47F65 didn't exist. After removing the registry key (HKLM above) I simply clicked the already existing short cut link and it worked right away. - Windows 8.1 64 bit - Firefox nightly 31.0a1 (2014-04-11) (I think the issue started previous to this version though, I had launched nightly directly from firefox.exe after the shortcut link was broken) After launching from the now working "task bar pin" firefox nightly went through a series of updates 2014-04-14, 2014-04-30 and seems to be working fine. Just wanted to confirm that deleting the registry key got me back working again. Thanks!

I've been looking for a fix for the task bar pin issue for about the same time. Sadly, I don't have either of the registry keys listed, and none of the other fixes have any effect. Certainly no life changer, but it'd be nice to have the functionality back in place. Current config: W8.1 (v6.3 b9600) FF Nightly 32.0a1 (2014-05-15) Thanks in advance for any advice.

(In reply to Jerry from comment #96) > I've been looking for a fix for the task bar pin issue for about the same > time. Sadly, I don't have either of the registry keys listed, and none of > the other fixes have any effect. Certainly no life changer, but it'd be > nice to have the functionality back in place. > > Current config: > W8.1 (v6.3 b9600) > FF Nightly 32.0a1 (2014-05-15) > > Thanks in advance for any advice. Uninstall all versions of Firefox. Download a ZIP of Nightly and throw it into Program Files. Create a short cut and you should be good to go.

Confirming....thanks so much for the quick response. (Why this didn't work the first few times I tried it...who knows?) Happy happy. Thanks again.