When attempting to switch between Metro -> Desktop using the oak build relating to the shared profile ticket, it will switch to the Windows desktop environment but will never run the Firefox Desktop at times. This seems to usually happen when switching between Metro -> Desktop. I've ran into this problem a few times when switching between Desktop -> Metro but 99% of the time it occurs when switching from Metro -> Desktop. It doesn't produce any "prompt" crashes nor does it add any entries inside "about:crash". However I did find that when Firefox Desktop doesn't launch, a WER crash file is created (open these in notepad). I've attached some of these files from both computers in the zip file. I tried removing everything from the machine relating to Firefox just in case if something was corrupted while switching. I restarted, re-installed several times with the same issues occurring. I also reproduced the same problem using the oak build on my main desktop machine. At first, I thought it could be related to the tabs being opened while switching back and forth, but I got the issue to reproduce by simply just switching back and forth between the environments without any tabs being opened (just the starting page) - Attached a short video of the issue Steps to reproduce the issue: 1) Install the oak build from Bug 924860 Comment 7 (Nightly oak build from Shared Profiles) 2) Once installed, launch Firefox Desktop 3) Select the Firefox Menu and then select "Relaunch in Windows 8 style Nightly" 4) Should launch Firefox Metro 5) In Firefox Metro, go to wikipedia.org and then slide in the Navigation App Bar 6) Select the "menu" icon from the Navigation App Bar and select "Relaunch in Desktop" Do this a few times and you should see the issue occur. If you can't reproduce with a single tab, try using a few tabs and switching back and forth Current Behavior: - Switching environments between Metro -> Desktop not always working (Firefox Desktop doesn't appear at times) Expected Behavior: - Should be able to switch between the two environments without any issues

Adding 2 points from contingency bug.

Point value previously accounted for in contingency.

I have been running into this as well while using Windows 8.1. I managed to capture a dump of the crash, and uploaded here: https://www.dropbox.com/s/a5wxopcxuj6fh7g/firefox.exe.4796.zip I'm not familiar enough with Windows startup sequence to have any useful insight as of yet.

According to the MSDN docs, COM should be running during ShellExecuteEx: http://msdn.microsoft.com/en-us/library/windows/desktop/bb762154%28v=vs.85%29.aspx After moving the XPCOM shutdown after the ShellExecuteEx call, I'm no longer running into this issue and switching Desktop <-> Modern UI is working as expected. Not sure if this is ideal or not, though.

Comment on attachment 8338871 [details] [diff] [review] bug940101.patch Review of attachment 8338871 [details] [diff] [review]: ----------------------------------------------------------------- Thanks for taking the time to try and fix this problem. ::: widget/windows/winrt/MetroAppShell.cpp @@ +229,5 @@ > } > > + // This calls XRE_metroShutdown() in xre. This will also destroy > + // MessagePump. > + sMetroApp->ShutdownXPCOM(); The ShelExecuteEx call needs to happen before we shutdown XPCOM so that the profile is not in use. I tested to see if it was related to CoInitialize calls and it doesn't seem to be. I can still reproduce the problem with this patch applied and with simply wrapping extra CoInitialize/CoUninitialize around the code.

See the extended description embedded in the patch for more info. Due to some kind of windows internal handling, I can't explain it :) I can consistently reproduce it without the patch though and can consistently not reproduce it with the patch. I even tried popping and pushing several times to make sure I was not seeing some false conclusion due to intermittent failures.

I was now able to switch between the desktop and metro environments using latest Nightly and latest Oak builds using the steps from the description and got the expected results each time. I tried using single/multiple tabs without any issue.