Our metro app, once launched, will be suspended if it is not currently in the foreground. If the machine becomes resource-constrained, Windows will terminate suspended processes. Currently, metroFx reacts to such termination as if it were a crash, but should instead be able to distinguish these cases and respond appropriately: 1 Suspend>Terminate>Activate 2 Suspend>Terminate>Close>Activate 3 Suspend>Terminate>Close>Reboot>Activate 4 Suspend>Terminate>Reboot>Activate "Respond appropriately" probably means to restore the user's session silently in case 1, and use the value of the "When Firefox Starts" pref to determine what to do in cases 2-4.  http://msdn.microsoft.com/en-us/library/windows/apps/hh464925.aspx  http://msdn.microsoft.com/en-us/library/windows/apps/hh465088.aspx  http://msdn.microsoft.com/en-us/library/windows/apps/windows.applicationmodel.activation.applicationexecutionstate.aspx
Marking this bug as dependent on bug 850372 since fixing that bug will also fix this bug. When metroFx gets suspended, our MetroApp::OnSuspending  function gets called. At this point, our process has 5s to flush its session state to disk or be terminated. Once metroFx is suspended, there is no guarantee that it will get to execute any additional code. In particular, if the user closes metroFx from the suspended state (bug 922657), or if the machine reboots (bug 850372), or if Windows terminates the process to free up resources (bug 949107), metroFx does not execute any additional code. Currently, metroFx treats any termination from a suspended state as a crash, but it needs to treat termination from a suspended state as a normal shutdown.  https://mxr.mozilla.org/mozilla-central/source/widget/windows/winrt/MetroApp.cpp?rev=7c8790d032b5#137
Depends on: 850372
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 850372
You need to log in before you can comment on or make changes to this bug.