Closed Bug 565567 Opened 14 years ago Closed 6 years ago

FF should ask for confirmation before quitting with Cmd-Q (only on Mac)

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1438499

People

(Reporter: jhill, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: parity-chrome, Whiteboard: [Advo])

Attachments

(1 file, 1 obsolete file)

bug-565567.patch
(deleted), patch
phlsa
: ui-review-
Details | Diff | Splinter Review 
(Note: this is filed as part of the “Paper Cut” bugs — we assume that there may be multiple existing bugs on this. Please make them block this bug, and we will de-dupe if they are indeed exactly the same. Thanks!)

To reproduce:
1. Open Firefox with lots of tabs (with session save enabled)
2. Use the keyboard shortcut CMD+W but accidentally hit CMD+Q
3. Your session is saved, but it's very annoying.

Recommendation:
We should ask users if they really meant to close the window when they hit CMD+Q and have multiple tabs open. We should also have an option to "Never show this again"

Only do this when the keyboard shortcut is evoked.
We already ask, but enabling session restore disables that dialog, though. Adding yet another confirmation dialog would be rather annoying if session saving was enabled in response to seeing the current exit dialog.
Session restore shouldn't disable that dialog. While I understand the rationale ("you don't lose your session, so we shouldn't ask"), it's not straightforward and predictable behavior.

That's a slightly different issue, this bug is mostly about fixing the Mac-specific problem of having Cmd-W and Cmd-Q right next to each other.
Linux has the same problem (ctrl+w closes a tab, ctrl+q closes the window), and I think Windows does too.  Why is this mac-specific?
Adding another modal dialog to the UI is quite annoying. We should investigate doing something like: http://www.chromium.org/developers/design-documents/confirm-to-quit-experiment

I have a proof-of-concept patch for it that I'll upload shortly.

(In reply to comment #3)
> Linux has the same problem (ctrl+w closes a tab, ctrl+q closes the window), and
> I think Windows does too.

No. ctrl+shift+w closes a window on Windows and Linux. ctrl+q closes the app on Mac and Linux. alt+f4 closes the app on Windows.
Whiteboard: [parity-chrome]
This is extremely annoying when you're working with multiple tabs and you have Firefox set to erase history on exit. When you accidentally hit Cmd+Q instead of Cmd+W you lose all your tabs without a warning prompt and without them restoring when reopening Firefox.
Chrome's proposed solution, as Comment 5 points out, is to display an overlay as soon as the user presses ⌘Q which says "Hold ⌘Q to quit."  If the user holds ⌘Q for a set duration (one or two seconds), Chrome quits.  The next KeyUp event is not finalized until the user releases ⌘Q, because otherwise the command begins closing other applications as soon as Chrome quits.  Can we do something similar in Firefox - maybe even try it out in UX branch to get the duration right?
Depends on: 550559
Summary: Ask when hitting Cmd-Q (only on Mac) → FF should ask for confirmation before quitting with Cmd-Q (only on Mac)
From the web, there are curretly many user-suggested workarounds to this bug. None of them actually work, so forums are littered with people complaining about them. As far as I can see, ALL the following ought to work - but do not, and haven't worked for the last few years :(.

Adding here because maybe - just maybe - it's possible to fix *one* of these easily, and then users would at least have a viable workaround to the bug.

1. Open Firefox's Options/Preferences, go to the Tabs section, and make sure "Warn me when closing multiple tabs" is checked.

2. Manually set:
 - browser.showQuitWarning;true
 - browser.warnOnQuit;true

3. From terminal, type:

defaults write NSGlobalDomain NSUserKeyEquivalents '{"Quit Firefox" = "@$Q";}'

The first two are simply ignored by FireFox (a quick search of bugzilla shows lots of semi-dupes of those bugs, this bug seems the cleanest, hence I'm reporting on this one).

The last one shows up in the GUI - the file menu has changed shortcut to "shift-command-q" - but FireFox *still* closes on command-q! It's as if someone has added an extra handler to force cmd-q to always quit, even when the user / OS has been configured to use something else :(.
I use this add-on:

  https://addons.mozilla.org/en-US/firefox/addon/always-ask/

I give a silent prayer of thanks to the author every time it saves me.

I would really like Firefox to stop treating me with contempt.
Whiteboard: [parity-chrome] → [parity-chrome] [Advo]
I made a workaround a while back: https://addons.mozilla.org/en-US/firefox/addon/warn-before-quit/

This does work on Linux and Mac as far as I know (though, I'd love to see the add-on made redundant)
This is not limited to OS X. Same annoying problem happens on Linux. If you hit Ctrl+Q by mistake and "show windows and tabs from last time" is set, Firefox quits without any warning. That's quite annoying and can be disruptive if you have something running in the browser. Being able to restore tabs and windows doesn't really make this a non issue. At the very least there should be some flag that would make exit warning mandatory, no matter what else is set.

Also, setting both browser.warnOnQuit and browser.showQuitWarning to true doesn't work.
browser.showQuitWarning works for me, but only if I have more than one tab (or window) open when I quit.

Note that in Firefox : Preferences : General, you can set "When Firefox starts" to "Show my windows and tabs from last time".
> browser.showQuitWarning works for me, but only if I have more than one tab
> (or window) open when I quit.
It also works for me, and the bus is still reproducible.

So there are two steps here to solve this issue.
1. Fix the "more than one tab/window" bug.
2. Set `browser.showQuitWarning` as `true` by default.
Add into the "Fix a number of default browser prompt issues" QX cluster.
Blocks: 1247818
Move to QX holding area to consider the priority.
Blocks: qx-feedlot
No longer blocks: 1247818
Attached patch bug-565567.patch (obsolete) (deleted) — — Splinter Review 
Hi Philipp,

Could you give feedbacks for the UI changes?

You can see it on the video[1]. And you also can download the Mac OS, Linux, or Windows builds on [2].

Thanks.

[1]: https://youtu.be/i2xJKs7ylCY
[2]: https://treeherder.mozilla.org/#/jobs?repo=try&revision=1f57daf077ec
Attachment #8790142 - Flags: ui-review?(philipp)
Assignee: nobody → evan
Finding a reviewer for reviewing code...
Comment on attachment 8790142 [details] [diff] [review]
bug-565567.patch

Hi Gavin,

Could you help review the patch?

Thanks.
Attachment #8790142 - Flags: review?(gavin.sharp)
Comment on attachment 8790142 [details] [diff] [review]
bug-565567.patch

Gavin has left Mozilla for years already...
Attachment #8790142 - Flags: review?(gavin.sharp) → review?(dolske)
Hey! I need a bit of clarification...
If I'm understanding correctly, then this patch would show the dialog even when just one tab is open or when automatic session restore is turned on. Is that correct? If so, what is the reason for also enabling it when only one tab is open?

We also have this other feature in the works (session restore button > https://bugzilla.mozilla.org/show_bug.cgi?id=1219725) that would make session restore a whole lot more discoverable.
Hi Philipp,

(In reply to Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from comment #27)
> Hey! I need a bit of clarification...
> If I'm understanding correctly, then this patch would show the dialog even
> when just one tab is open or when automatic session restore is turned on. Is
> that correct?
Not really. The dialog will also be shown when automatic session restore(`browser.sessionstore.resume_session_once`) is "off" or any one tab(one or more than one) is opened. If automatic session restore is "on", the dialog will not be shown when quit Firefox with CMD+Q.

> If so, what is the reason for also enabling it when only one tab is open?
For consistency, the dialog will be shown when one or more than one tab is opened. But if only showing the dialog when more than one tab is opened is better for UX, let's do it.
Hi Philipp,

One more question for Comment 27. So do we want to show the dialog only when more than one tab is opened? Don't show when only one tab is opened, right?

Thanks for the response. :)
(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #26)
> Comment on attachment 8790142 [details] [diff] [review]
> bug-565567.patch
> 
> Gavin has left Mozilla for years already...

Tim, thanks for finding correct reviewer.
(In reply to Evan Tseng [:evanxd][:愛聞插低] from comment #29)
> Hi Philipp,
> 
> One more question for Comment 27. So do we want to show the dialog only when
> more than one tab is opened? Don't show when only one tab is opened, right?

Yes, let's please only show it when multiple tabs are affected.
Also, this would be a good chance to give that dialog some better copy.
Michelle, could you help here? We are talking about this dialog: https://cl.ly/2c0X2I1L1O47
Flags: needinfo?(mheubusch)
Guys, I strongly disagree. FF should _always_ confirm whether to quit or not, regardless how many tabs/windows may be open.

Imagine that user is within a complex transaction that would take him half an hour to repeat -- do you think they would be happy if they lost everything just by a "Quit" (cmd-Q) they didn't intend to perform?
Comment on attachment 8790142 [details] [diff] [review]
bug-565567.patch

Setting this to ui-r- since there were change requests.
Attachment #8790142 - Flags: ui-review?(philipp) → ui-review-
(In reply to Ralf G. R. Bergs from comment #32)
> Guys, I strongly disagree. FF should _always_ confirm whether to quit or
> not, regardless how many tabs/windows may be open.
> 
> Imagine that user is within a complex transaction that would take him half
> an hour to repeat -- do you think they would be happy if they lost
> everything just by a "Quit" (cmd-Q) they didn't intend to perform?

Yes, but we need to weigh that possibility against the much more frequent case where a user gets held back when simply wanting to end a task by closing the browser.
(In reply to Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from comment #34)
> (In reply to Ralf G. R. Bergs from comment #32)
> > Guys, I strongly disagree. FF should _always_ confirm whether to quit or
> > not, regardless how many tabs/windows may be open.
> > 
> > Imagine that user is within a complex transaction that would take him half
> > an hour to repeat -- do you think they would be happy if they lost
> > everything just by a "Quit" (cmd-Q) they didn't intend to perform?
> 
> Yes, but we need to weigh that possibility against the much more frequent
> case where a user gets held back when simply wanting to end a task by
> closing the browser.

Why not simply have a setting that allows you to configure the behavior?

[X] Prompt "Really quit?"
  (*) In any case
  ( ) Only if more than one tab open
Hi Ralf,

> Why not simply have a setting that allows you to configure the behavior?
> 
> [X] Prompt "Really quit?"
>   (*) In any case
>   ( ) Only if more than one tab open
Looks like we need more discussion for your idea. How about only showing the dialog when more than one tab is opened? Make things happen first. And then let's file a new bug to discuss your idea. :)
Attached patch bug-565567.patch (deleted) — — Splinter Review 
Hi Philipp,

I updated patched for your comments. Now only show the quit dialog when more than one tab is opened.

You can see it on the video[1]. And you also can download the Mac OS, Linux, or Windows builds on [2].

Thanks.

[1]: https://youtu.be/z3_3aySsKxM
[2]: https://treeherder.mozilla.org/#/jobs?repo=try&revision=d0f1b3fc953e
Attachment #8790142 - Attachment is obsolete: true
Attachment #8790142 - Flags: review?(dolske)
Attachment #8792420 - Flags: ui-review?(philipp)
(In reply to Evan Tseng [:evanxd][:愛聞插低] from comment #36)
> Hi Ralf,
> 
> > Why not simply have a setting that allows you to configure the behavior?
> > 
> > [X] Prompt "Really quit?"
> >   (*) In any case
> >   ( ) Only if more than one tab open
> Looks like we need more discussion for your idea. How about only showing the
> dialog when more than one tab is opened? Make things happen first. And then
> let's file a new bug to discuss your idea. :)

My "design draft" was for the Settings, where users can change the desired behavior. Use a reasonable default ("prompt in any case" so that people don't lose work, and in case this goes on people's nerve they can change the default to a relaxed way of protecting them).
(In reply to Evan Tseng [:evanxd][:愛聞插低] from comment #37)
> I updated patched for your comments. Now only show the quit dialog when more
> than one tab is opened.

For me this is too much already, and might confuse users.

We have "When Firefox starts" already in the settings. When users set this to "Save my windows and tabs from last time" they don't want to be nagged, just do it (save when browser exits, possibly after user confirmed they actually want to exit).

I have currently this (https://addons.mozilla.org/en-US/firefox/addon/always-ask/?src=api) installed, and it does exactly what I want.
(In reply to Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from comment #34)
> (In reply to Ralf G. R. Bergs from comment #32)
> > Imagine that user is within a complex transaction that would take him half
> > an hour to repeat -- do you think they would be happy if they lost
> > everything just by a "Quit" (cmd-Q) they didn't intend to perform?
> 
> Yes, but we need to weigh that possibility against the much more frequent
> case where a user gets held back when simply wanting to end a task by
> closing the browser.

I agree that we should NOT get in the way of the primary use case (quitting Firefox).  Instead, we should likely rely on session restore button (https://bugzilla.mozilla.org/show_bug.cgi?id=1219725) as the solution to the accidental quit scenario.
Comment on attachment 8792420 [details] [diff] [review]
bug-565567.patch

So, I looked into this a little further. What I didn't notice before was that this patch spawns a different prompt than the one we have when the user just closes a window.

New Cmd-Q prompt: https://cl.ly/3t302r161g1P
Current prompt when clicking the x: https://cl.ly/1V3l0z1B3H2A

This complicates things, since we are sending two similar but crucially different messages, with different opt-out options.

On top of that, the product team is currently evaluating some variations on making session restore easier in general. The starting point is this bug[1], but we are also doing user testing on other options, like enabling session restore by default. In any case, it will allow us to learn a great deal more about the quitting/restoring behavior of users.

I'd like to pause work on this bug until we have answers from research. The solution in the patch might be the right one, but it would be good to consider the scenarios around it and then make an educated decision and then have a holistic, rather than a partial solution.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1219725
Flags: needinfo?(mheubusch)
Attachment #8792420 - Flags: ui-review?(philipp) → ui-review-
(In reply to Alex Limi (:limi) — Firefox UX Team from comment #2)
> Session restore shouldn't disable that dialog... 
> "you don't lose your session, so we shouldn't ask")

... [more talk that assumes session restore means quitting is OK] ...

Maybe that was true in 2011 and still holds true for e.g. Bugzilla. But on complex modern web sites, I *lose data* when I quit the browser, information that session restore doesn't restore. Dynamically-generated content on dynamically-updated pages is gone along with whatever I've entered. A few times a year I end up grepping through sessionstore.js trying to find information from a lost tab.

I agree with comment #32 that Firefox's default behavior is damaging. I use the warn-before-quit add-on on Linux to fix it.
> I'd like to pause work on this bug until we have answers from research. The
> solution in the patch might be the right one, but it would be good to
> consider the scenarios around it and then make an educated decision and then
> have a holistic, rather than a partial solution.

Sure, let's continue to work on this after we have a clear solution.

Do need-info here. Philipp, could you please reply it once we have conclusions for the solution? Thanks.
Flags: needinfo?(philipp)
I found Firefox 51 don't show quit dialog when open multiple tabs when I set browser.showQuitWarning=true

After that, I set "When Firefox starts:" from "Show last time" to "Show home page".
Now quit dialog can show again.

So, to make this quit dialog work again. You must set these 2 prefs.
browser.showQuitWarning=true
browser.startup.page=1
Unassign myself and wait for the research result(Comment 41).
Assignee: evan → nobody
Now that https://addons.mozilla.org/en-US/firefox/addon/always-ask/?src=api is going away, what is the best way to have command+q not quit the browser immediately?
(In reply to John Ford [:jhford] CET/CEST Berlin Time from comment #46)
> Now that https://addons.mozilla.org/en-US/firefox/addon/always-ask/?src=api
> is going away, what is the best way to have command+q not quit the browser
> immediately?

The best way is for Firefox to implement it, and provide an option to enable it. The main problems, any such kind of feature is now impossible to supply through add-ons, and Mozilla developers can decide not to implement it for whatever reason. It's not a pleasant situation for end users in the end.
(In reply to skierpage from comment #42)
> (In reply to Alex Limi (:limi) — Firefox UX Team from comment #2)
> > Session restore shouldn't disable that dialog... 
> > "you don't lose your session, so we shouldn't ask")
> 
> ... [more talk that assumes session restore means quitting is OK] ...
> 
> Maybe that was true in 2011 and still holds true for e.g. Bugzilla. But on
> complex modern web sites, I *lose data* when I quit the browser, information
> that session restore doesn't restore. Dynamically-generated content on
> dynamically-updated pages is gone along with whatever I've entered. A few
> times a year I end up grepping through sessionstore.js trying to find
> information from a lost tab.
> 
> I agree with comment #32 that Firefox's default behavior is damaging. I use
> the warn-before-quit add-on on Linux to fix it.

Agreed. The assumption that session restore is good enough for accidental quits isn't quite right. There are many times (offline, complex front-end ui/data, etc.) when this can be a total headache. Given that WebExtensions can't address this, the option ought to be baked into firefox.
And there is another HUGE problem. Even if we for a moment assume that "session restore" is "good enough"... it's not, because it doesn't work reliably in Fx (and haven't for ages). Previously I was using separate Session Restore plugin to that end, but it doesn't work with new version and what's more - the new version tend to loos tabs roughly in 50% cases...
(In reply to ktos.obcy from comment #49)
> "session restore" ... doesn't work reliably in Fx (and haven't for ages). ...
> ... the new version tend to loos tabs roughly in 50% cases...

You should request help in the support forum or file a bug report in that area, because for the vast majority of users it is highly reliable.
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-chrome
Whiteboard: [parity-chrome] [Advo] → [Advo]
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(philipp)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: