453614 - Command Q quits instantly with data loss on OS X, no way to prevent it

Status: RESOLVED DUPLICATE of bug 419009

(Firefox :: Session Restore, defect)

Description

[adam.m.s.martin]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1

Firefox currently quits instantly if you hit command-q, and you *lose* any unsaved data (e.g. form contents) that you had at the time. I feel a bit bad about marking something this simple as "critical" but the only reason I'm reporting it as a bug is the large number of times I have *already* lost data because of it. There is no confirm dialog (any other application with unsaved data would throw up an "Are you sure?" dialog).

NOTE: I have "warn me before closing multiple tabs" selected, and I have verified that it works if you click the close button at top left of any multi-tab window; but that check is NOT being performed in reaction to the command-q shortcut.

I also have my "on starting firefox, open what?" set to "the set of tabs and windows that were opened when last quit".

The bug part here is that it causes data-loss, and there is apparently:
 - no way to disable the command-q shortcut
 - no way to enable a "confirm before quit" option without disabling / misconfiguring other parts of firefox

I've searched through the options, and the forums, and BZ, and couldn't see an obvious way to fix this?

There is no option to turn off or reassign the command-q shortcut (I've tried using various software, both OS X tools and Firefox plugins, to reassing that shortcut, but it appears hardcoded, I can change / disable all the others but not that one).

Because the command-w (used hundreds of times a day) and command-q shortcuts are one key apart, this sadly happens quite often.

Reproducible: Always

Steps to Reproduce:
1.Got to a wiki, e.g. especially a MediaWiki
2.Edit a page and make lots of changes
3.Go to any other tab or window, and try to close it, but hit command-q instead of command-w, and say goodbye to everything
4.Reload firefox, and have your tabs come back
Actual Results:  
The edit-page form on the wiki has lost all your changes (of course it has - you hadn't saved them).

Expected Results:  
EITHER: it should NOT quit instantaneously (why does it do this? This is horrible behaviour)
OR: it should reload the form contents as they were before it quit (this would be an acceptable workaround, because then there would be no dataloss. It works OK with reloading form contents when using the Back and Forwards controls, but not persisted across restart)

Comment 1

[Mats Palmgren (inactive)]

Works for me, Firefox 3.0.1 on MacOSX 10.5.4
using this page for testing:
http://www.mediawiki.org/w/index.php?title=Sandbox&action=edit

Comment 2

[Simon Bünzli]

(In reply to comment #0)
> I also have my "on starting firefox, open what?" set to "the set of tabs and
> windows that were opened when last quit".

Yeah, that currently suppresses the prompt.

>  - no way to disable the command-q shortcut

As a quick work-around, try the keyconfig extension from <http://mozilla.dorando.at/readme.html> which allows to modify key bindings. Else that's a DUPE of bug 257241.

>  - no way to enable a "confirm before quit" option without disabling /
> misconfiguring other parts of firefox

That's a DUPE of bug 433123.

> There is no option to turn off or reassign the command-q shortcut

If keyconfig doesn't work, maybe the OS X keyboard configuration does.

> The edit-page form on the wiki has lost all your changes

We should be saving your work. Does the wiki happen to have an httpS URL? If so, go to about:config and set browser.sessionstore.privacy_level to 0 to at least have Firefox restore that text data (note: this might casue credit card numbers to be written to disk - not that you might care).

Comment 3

[Simon Bünzli]

(In reply to comment #0)
> EITHER: it should NOT quit instantaneously (why does it do this? This is
> horrible behaviour)

Actually, that's pretty much bug 419009. Duping...

Comment 4

[adam.m.s.martin]

(In reply to comment #2)
> (In reply to comment #0)
> > The edit-page form on the wiki has lost all your changes
> 
> We should be saving your work. Does the wiki happen to have an httpS URL? If
> so, go to about:config and set browser.sessionstore.privacy_level to 0 to at
> least have Firefox restore that text data (note: this might casue credit card
> numbers to be written to disk - not that you might care).

Aha! Yes, I hadn't realised, but I went back and checked, and the wikis I had been using were both https only. Thanks!