Closed Bug 274501 Opened 20 years ago Closed 17 years ago

No keybinding for File->Quit in Gnome/KDE

Categories

(Firefox :: Shell Integration, defect)

1.0 Branch
x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 189290

People

(Reporter: dowobeha, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: platform-parity)

Firefox on Linux lacks a keybinding (such as ctl-q) with which the user can quit
Firefox.

This functionality is present in the Mac OS X version of Firefox. It is present
in the vast majority of KDE applications. 

In a KDE environment, the failure of Firefox to have this standard keybinding is
extremely annoying. While not all users may want this feature, there should (at
the very least) be a mechanism for enabling this functionality.
Blocks: firekey
Keywords: access
I'm told that under both Gnome and KDE, the norm is to use Ctrl+Q. Does it
mention this in any UI style guides for these platforms?

In Firefox, Ctrl+Q isn't so dangerous anymore that we can't have it when it's
the norm to do so. We have the exist confirmation dialog now.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: No keybinding for File->Quit → No keybinding for File->Quit in Gnome/KDE
Actually, File->Exit skips confirmation on Windows, I need to retest on trunk,
but I know there's a bug out there.  The behaviour is a bit suboptimal in the
"accidentally killing all windows because you fat-fingered the close tab
shortcut" way, so this won't happen until that bug is fixed.
For me, File -> exit gives me the confirmation dialog.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041215
Firefox/1.0+
Aaron, sorry, should have been more precise.  If you have three single tab
windows, you don't get a prompt... unless that's changed very recently.
Mike and Aaron,

I'm the guy who submitted this bug. Based on what you're saying, it sounds like there may be problems 
under certain circumstances where a person accidentally quits Firefox when all they meant to do is 
close a tab (hitting ctl-q instead of ctl-w).

I'd ask that even if this is a problem for some people, that you at least make it so that a person can 
configure Firefox on Linux to use ctl-q. It wouldn't have to be default behavior (although that would be 
nice), as long as it can be done. Most other key commands can be configured with config files - why 
not File->Exit?

Also, the problem of hitting ctl-q instead of ctl-w is a QWERTY-specific problem. I use the Dvorak 
keyboard layout, and so am in very little danger of running into this problem since the q and w keys are 
on opposite sides of the keyboard. I know that most people use QWERTY, but again, all I'm asking is for 
an option to enable ctl-q behavior.

Thanks,
Lane
(In reply to comment #5)
> Most other key commands can be configured with config files - why 
> not File->Exit?

Not in Firefox, unless you're building from source.

This will probably be dealt with in the future once we have true keybinding
configuration, but that's probably 2.0 material.
Mike,

Couple of comments. First off, I guess I misspoke when I said that other key commands are 
configurable. I remember doing editing config files to change key bindings, but that must have been in 
Mozilla proper, not Firefox.

Back to my original issue...

You wrote that the keybinding for Firefox on Linux can't be changed because there is an open bug for 
Firefox on Windows where no confirmation screen appears under certain circumstances. This is a valid 
reason to leave out ctl-q bindings on Windows. But unless this bug also exists in Firefox on Linux, why 
is this a reason to not provide the ctl-q binding in the Linux version?

The KDE and GNOME user interface guidelines both indicate that ctl-q should be used. 

All example menus in the KDE UID doc indicate the ctl-q binding for File->Exit. This jives with my 
experience as a regular KDE user; pretty much all KDE apps that I use have ctl-q.

The GNOME Human Interface Design document explicitly states that File->Exit should bind to ctl-q. 
Here's the relevant section:

"Quit
Ctrl-Q

Closes the application. If there are unsaved changes in any open documents, present the user with a 
confirmation alert for each affected document, giving the option to save the changes, discard them, or 
cancel. If there are no unsaved changes, close the application immediately without presenting any 
further messages or dialogs.

In particular, non-document based applications, for example a game or a calculator, should save their 
state and exit immediately. This state should be restored the next time the application is started."


GNOME HID document:
http://developer.gnome.org/projects/gup/hig/2.0/menus-standard.html#the-file-menu

KDE User Interface Design
http://developer.kde.org/documentation/standards/kde/style/menus/file.html
Actually, the same bug would exist on Linux as well, the code is shared, I just
haven't tested on Linux.  And you don't need to tell me what the GNOME HIG says,
I'm the local GNOME HIG zealot.  HIG compliance is a good thing, _if_ it doesn't
create a potential for dataloss/angry users.  There was a reason the keybinding
was removed in the first place, of course.
Mike, thanks for the info. I was mostly quoting the HID guideline info because
Aaron had asked in an earlier post what the GNOME and KDE guides said regarding
ctl-q.

Given the bug that you have mentioned, would it be possible to at least have a
non-default option to enable ctl-q behavior? 
not on its own, I don't want to deal with legacy migration bits.

Once we get that working, we'll be able to do it.
I see this as more of an OS integration or platform parity bug than an
accessibility bug.
Assignee: aaronleventhal → bugs
Component: Keyboard Navigation → OS Integration
Keywords: accesspp
QA Contact: jruderman → os-integration
any more action on this one since january?
i sure do miss ctrl+q
is there not a way to put it in a config file for now?
I haven't heard anything. Maybe Mike or Aaron could give us an update? 

Does the bug still exist where File->Exit skips confirmation under certain
circumstances? If so, could you please post the bug number so that those parties
interested in this (lack of Ctl-Q) bug can track the status of that (no
File->Exit confirmation) bug?

Is there a release target for resolution of these bugs?
Related to/duplicate of bug 189290?
Just for reference, I have found a workaround for this bug until it is fixed.

To work around, follow these steps:

1. Install the keyconfig extension from
http://extensionroom.mozdev.org/more-info/keyconfig

2. After restarting Firefox, go to Tools...Keyconfig...

3. Click the "Add a new key" button. A new window will appear. There will be a
small text box on top and a large text box below.

4. Delete any sample text from both text boxes.

5. In the small text box, enter "Quit" without the quotes. In the large text
box, enter "goQuitApplication();" without the quotes. Click OK.

6. An entry for Quit will now appear in the main Keyconfig window. Select the
Quit entry, then click in the small text area beside the Apply button.

7. Press the Control and Q keys. The text "Ctrl-Q" should appear in the text
box. Click the Apply button. Click the Close button.

8. Open a new window or restart Firefox. Ctrl-Q should now function normally.
Assignee: bugs → nobody
I also miss ctrl-q.  FWIW, apparently this is not linux-specific, I know for sure it also is relevant in both win2k and xp. This seemingly should be changed to ALL.  
(In reply to comment #16)
> I also miss ctrl-q.  FWIW, apparently this is not linux-specific, I know for
> sure it also is relevant in both win2k and xp. This seemingly should be changed
> to ALL.  

This bug is not relevant to Mac OS X. I believe that it does affect all other platforms.
As comment 14 suggests, this is a duplicate of bug 189290.

> Actually, File->Exit skips confirmation on Windows, I need to retest on trunk,
> but I know there's a bug out there.  The behaviour is a bit suboptimal in the
> "accidentally killing all windows because you fat-fingered the close tab
> shortcut" way, so this won't happen until that bug is fixed.
...
> Aaron, sorry, should have been more precise.  If you have three single tab
> windows, you don't get a prompt... unless that's changed very recently.

In the latest trunk nightly, if I open three single tab windows and select File > Quit, then Firefox prompts me with the following dialog:

---
Do you want Minefield to save your tabs and windows for the next time it starts?
[] Do not ask next time

[Quit]                        [Cancel] [Save and Quit]
---

So the blocker has been resolved, and it is now possible to implement this keybinding.  I'll attach a patch to do so over in bug 189290.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.