Defect - Closing Firefox Metro from the applist bar on win8 desktop

RESOLVED DUPLICATE of bug 850372

Status

defect
RESOLVED DUPLICATE of bug 850372
6 years ago
5 years ago

People

(Reporter: kjozwiak, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
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.
Sorry that should read See Bug 917020 Comment 2 and Bug 917020 Comment 3
Ah, got it.  Brian is right.  Sorry for the confusion.
No longer depends on: 917020
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
Blocks: metrobacklog
No longer blocks: metrov1backlog
Whiteboard: [triage] feature=defect c=Opening_and_closing u=metro_firefox_user p=0 → 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 [1] 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.

[1] 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
No longer blocks: metrobacklog, 831888
No longer depends on: 850372
Whiteboard: feature=defect c=Opening_and_closing u=metro_firefox_user p=0
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.