When closing Firefox Metro from the applist, restarting the browser doesn't start in a clean state and re-opens all the previous opened tabs. It appears that the following code isn't being executed: http://dxr.mozilla.org/mozilla-central/source/widget/windows/winrt/MetroApp.cpp#l228 This is occurring on Windows 8.0 (don't have a device with 8.1 to test this) Steps to reproduce the issue: 1) Open Firefox Metro 2) Open up several different tabs (5 or so should do) 3) Switch back to the Desktop (leaving Firefox Metro opened) 4) Move the mouse cursor to the applist, right click on Firefox Metro and select "Close" 5) Re-open Firefox Metro and you should notice that all the tabs are re-opened and a new slate wasn't started Current Behavior: - Closing Firefox Metro via the applist isn't closing it correctly, starting it the second time around will still have all the previous tabs opened Expected Behavior: - Closing Firefox Metro via the applist should completely close Firefox Metro. When the user re-launches the browser, a brand new slate should be started Used the following build: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-09-30-07-12-02-mozilla-central/
Note that the expected behavior for this bug will change when bug 917020 is fixed.
Depends on: 917020
Are you sure? I think that on crashes we will still restore session store even after bug 917020. Closing from that bar basically just kills the process so it is basically seen as a crash. The code Kamil mentioned that isn't working though, detects this situation to ensure a fresh start.
Right, but after bug 917020 we will restore the session after either clean or unclean shutdown, so the "Expected Behavior" above will change -- instead of expecting a new "clean" session we will expect a restored session.
(In reply to Matt Brubeck (:mbrubeck) from comment #3) > Right, but after bug 917020 we will restore the session after either clean > or unclean shutdown, so the "Expected Behavior" above will change -- instead > of expecting a new "clean" session we will expect a restored session. That's not correct, after bug 917020 we will not restore the session. See Comment 2 and Comment 3.
Ah, got it. Brian is right. Sorry for the confusion.
Whiteboard: feature=defect c=Opening_and_closing u=metro_firefox_user p=0 → [triage] feature=defect c=Opening_and_closing u=metro_firefox_user p=0
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: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 850372
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.