594161 - On Windows delay closing the application for a few seconds

Status: NEW

(Firefox :: General, defect)

Description

[Alex Faaborg [:faaborg] (Firefox UX)]

Through casual ethnographic observation (watching people use Firefox in their native habitat), we've found three distinct and common ways for the user to perform a search, in reverse order of knowledge of the product's features:

1) using the search bar or location bar
2) [if the user hasn't discovered these two] hitting the home button
3) [if the user hasn't discovered the home button] closing the application and relaunching from the start menu, desktop, or quick launch bar in order to get their home page back and perform a search.

Unfortunately, for all of the users in group 3, our start up time becomes a regular part of using the product throughout the day.  Each search can take several seconds to initiate (or worse) as we do a cold launch.

On OS X this isn't an issue, since the dock is designed to deal with this type of user confusion, and it's easy for an application to remain open even if the user has closed all of the application's windows.  This design of the dock in OS X is very likely a response to them monitoring the same type of user behavior, namely people who don't want to think about something being open or closed, they just want their computer to be as fast as possible.

On Windows, I recommend that we delay closing Firefox for several seconds after the last window close so that we can perform an extremely fast "start" if in fact the user was only closing the window so that they could re-launch Firefox and access their home page.

description of keyword use:

ux-implementation-level: when the user double clicks the Firefox icon, it will either be slow or fast to display.  In this delay we are implicitly surfacing implementation level information that is outside of the user's concern.

ux-mode-error: Firefox will display quickly or slowly depending on which mode it is in (open or closed), however users won't necessarily know that these are two different modes, and may continually have Firefox display slowly (because they have a single window) when they actually want it to display quickly (they have multiple windows)

Comment 1

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

I would hope any such change would have a pref-based implementation (eg, an integer pref called "browser.shutdowntimeout", and the value of the pref is the number of seconds for the timeout).

Reason being, I close the last open window and relaunch Firefox to start a completely new session, so if this bug lands with a 2-3 second pause, closing and relaunching will keep the previous session running. If I could set a pref to '0' to have no shutdown delay, everyone would be happy.

Comment 2

[Jesse Ruderman]

For me, most of startup time is accounted for by new-window time, so speeding up launch will require keeping the XUL window around (hidden) rather than just the process.  I don't know if that makes things more complicated.

We'll want to skip the delay when:
* Firefox is waiting to update itself.
* Firefox is waiting to update an extension.
* Firefox is using more memory than it should after the last window has closed.
* Firefox is quitting because the OS is shutting down.
* A relaunch would not reuse the process (-no-remote?).

This will slow down a few cases that are relatively rare:
* An installer is waiting for Firefox to exit.
* You launch Firefox right after an old process decides to start its shutdown.
* You're restarting Firefox in order to work around or troubleshoot a bug.

How will this interact with user-visible things that happen "on shutdown"?  I'm thinking of the trashing of session cookies, clear-private-data settings, and warnings about the termination of downloads.

Comment 3

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

(In reply to comment #2)

> We'll want to skip the delay when:
The "Help -> Restart with Add-ons Disabled" menu item is used to trigger the restart.

Comment 4

[Alex Faaborg [:faaborg] (Firefox UX)]

>How will this interact with user-visible things that happen "on shutdown"?  I'm
>thinking of the trashing of session cookies, clear-private-data settings, and
>warnings about the termination of downloads.

All of those would happen first, and from the user's perspective (unless they are watching the task manager), Firefox just closes entirely.  If they launch it again, it launches nearly instantly since it was already open (not even a warm launch, but a "hot launch"?).

Comment 5

[scratch]

This should definitely have a pref, as Jesse's "relatively rare" cases and ones like them are pretty common for those of us who like to tweak Firefox.  I frequently shut down with the intent to start a brand new process within seconds -- userContent.css changes, userChrome.css changes, changes to files within an extension or theme, changes to files within omni.jar, etc.  There are also times where I notice excessively high memory usage even after closing some tabs and so I'm restarting the process to get back down to a normal memory size.  And for those of us who don't fall into category 3 (do you have any statistics on what percentage of FF users do?), this feature would really never be something that'd help me out.