Closed Bug 52821 Opened 24 years ago Closed 3 years ago

too easy to hit CTRL+Q instead of CTRL+W

Categories

(Firefox :: Keyboard Navigation, enhancement, P5)

x86
All
enhancement

Tracking

()

RESOLVED FIXED
87 Branch
Tracking Status
firefox-esr78 --- wontfix
firefox85 --- wontfix
firefox86 --- wontfix
firefox87 --- fixed

People

(Reporter: jefu, Assigned: evilpie)

References

(Blocks 2 open bugs)

Details

(Keywords: dataloss, helpwanted, papercut, Whiteboard: Workaround: https://addons.mozilla.org/firefox/addon/disable-ctrl-q-and-cmd-q/ (WebExtension for Firefox 57+) (Gnome/linux - use Keyboard application to add custom shortcut handled by Ctrl-Q) || Workaround Gnome-Linux: Open Keyboard application and add c…)

Attachments

(1 file, 9 obsolete files)

I frequently open new windows on almost every page i visit.  Then I have a bunch
of browser windows to close.  Several times recently I've hit the <ctrl>-q
rather than <ctrl>-w - which of course closes mozilla and loses all the context
I've set up.  It would be nice to be able to disable the <ctrl>-w key so this
does not occur.
Hmm, Ctrl-W is somewhat standard for closing single windows, so that probably 
isn't going to change.  I think what we really need is a dialog saying "Are you 
sure you want to close all open Mozilla windows?", and perhaps also the removal 
of ctrl-q/exit from auxillary windows.  See bug 39057.
URL: any
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: poor control key assignments → too easy to hit ctrl-q instead of ctrl-w
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Depends on: 39057
No longer depends on: 39057
Depends on: 39057
Chaning the qa contact on these bugs to me. MPT will be moving to the 
owner of this component shortly. I would like to thank him for all his hard 
work as he moves roles in mozilla.org...Yada, Yada, Yada...
QA Contact: mpt → zach
Jeff, why do you want to disable Ctrl-W?  The only thing that would make sense
to me would be to disable Ctrl-Q.  But then, a warning dialog (bug 39057) would
be enough IMHO.  So I suggest marking this as a duplicate of bug 39057 instead
of dependent.
updating to new owner. sorry for the spam.
Assignee: hangas → mpt
Status: ASSIGNED → NEW
I think, this was a typo and Jeff asked (for the option) to remove Accel-Q.

I agree that bug 39057 is better UI. This bug might be fixed automatically
anyway by generic customizable shortcuts.
I think a lot of the discussion about bug 39057 that has been verified as
WONTFIX is caused by the existence of the ctrl-q shortcut more than anything else.

My idea is that ctrl-q is not an action that deserves a shortcut as it is one of
the least frequently used. Having the File->Quit menu command is great, but my
impression is that a shortcut is too much.

If ctrl-q (only the keyboard shortcut) was to be disabled, many people would be
happier.
agreed. any objections?
Yes [I object].  Please spend your time working on getting user controlled 
keybindings implemented instead of this. Then people can disable or rebind 
ctrl-q.
Removing the Ctrl+Q shortcut will help people who accidentally hit the wrong 
key when they're trying to close a window, but it won't help people who use 
the "hit the last item on the file menu" gesture to close a window.
timeless, I don't think that user-defineable shurtcuts are about to go in in the
next month or so? The time that *I* loose from accidently hitting ctrl-q *one or
two* times at the wrong moment is already more than it takes the create the
patch (not including all that review and checkin stuff).
David, yes, but that's not what this bug is about.
It would be interesting to simply have Ctrl+Q = Close and none of the Exit or
Ctrl+W stuff. It would be more "correct" IMO.
Agreed with Marko. Hitting Ctrl+W while focus is in a text field has one
behavior (erase previous word); however, if you accidentaly didn't give the text
field focus, it'll close the current window. Making Ctrl+Q have the current
Ctrl+W behavior and making Ctrl+W do nothing when no text field is in focus
would help.
Um, the fact that ctrl-w does different things is because people liked that 
feature, considering you are making this error I would propose that we switch 
to non emacs bindings so that people don't even _try_ to do this.  But that's 
for another bug -- bottom line: your argument doesn't fit here.
Timeless: just because that's being discussed somewhere else, doesn't mean it's 
not relavent here.
I was bored and frustrated, so I changed the key for quit to be accel+shift+Q
I'm attaching a patch, take it or leave it
Myth's patch sounds like a good compromise to me, and was just mentioned on as 
an alternative on n.p.m.ui.  I say go for it.
Keywords: patch, review
This patch is against the wrong file, it just makes a change to the contents of 
the jar.  If that's the file, then I think that we need a patch that goes 
against platformGlobalOverlay.xul in 
  xpfe/global/resources/content  /mac  /os2  /win  /unix

and probably keep the other platformGlobalOverlay.xul in synch, in

  xpfe/communicator/resources/content  /mac  /os2  /win  /unix

Removing keywords for now.
Keywords: patch, review
Why are there two sets of these files?
Keywords: patch, review
accel-shift-Q is Log Out on Mac OS X...
Changing Quit to shift-accel-Q is also against the HIG on Mac Classic.

Please avoid changing the shortcut on Mac.
I know that entire epics have been written on the merits or otherwise of ctrl-Q,
(hey, I just read all of bug 39057) but I do have one thing to add:

In Outlook Express, the keyboard shortcut for "mark this [e-mail/news posting]
as read" is (wait for it...) ctrl-Q!

Lovely.  Anyone who's been using OE for their mail/news may well now have a left
hand which is muscle-memory programmed to hit ctrl-Q when they finish reading a
post.  Whoops, Kaboom!  There goes mozilla, without warning.  Anyone attempting
to migrate is going to go nuts.
> In Outlook Express, the keyboard shortcut for "mark this [e-mail/news posting]
> as read" is (wait for it...) ctrl-Q!

It is entirely untrue that MS did this only to make migration to Netscape
harder. ;-P

Is anyone going to suggest an alternative shortcut?
Note that these shortcuts are effectively platform-specific,
so that Mac users can suggest a Mac-only shortcut if they wish.
gavin, outlook express users deserve to be punished! jks :)

I've been going NUTS since ctrl-w was disabled.  I use tabbed browsing (it's
faster, so I converted) so the ONLY way to close the tab is to click the X - Alt
F4 closes the whole window and all tabs.

Within 1 day I've been inconvenienced far more by not being able to ctrl-w than
by hitting ctrl-q accidentally.  I think you should enable ctrl-w and ctrl-q
again and have a popup alert asking "are you sure" for exiting mozilla.  Then
people bumping the wrong key have no grounds for complaint, and later on
implementing a customisable keyboard shortcut can make everyone happy.

Please give me back ctrl-w though.  This sucks. :(
4.72 pops up a warning dialog on Quit if more than one window is open. Marking
4xp and nominating for MachV.
Keywords: 4xp, nsbeta1
§$!@½%&!!!

dataloss.
Keywords: dataloss
Additional note: It is also easy to accidentally hit command-q when cycling
through windows using command-1.

I think changing the common bindings would be a bad thing, but there really,
really should be an opt-in warning dialog about quitting.
It sounds from reading the comments here that this bug has gone unfixed because 
there was never a consensus as to what to do about it. In order to restart the 
stalled discussion and get to a consensus I'd like to list the logical 
possibilities:

Aside: I take it that Accel is another name for the Alt key. But I'm using Alt 
below since I'm not absolutely sure. 

1) Have a dialog box pop up for confirmation of whether to exit Moz when Ctrl-Q 
is typed.
   This could be made a configurable option. My advice is that if it is 
configurable then the default should be to pop up the confirmation dialog box. 
Give people training wheels and then let them take the training wheels away if 
they are feeling luckly. "Do you feel lucky punk? Well, do you?"

2) Change the Ctrl-Q assignment for exiting Moz to Ctrl-Alt-Q or Ctrl-Shift-Q 
or some other harder-to-hit combination involving Q.
   This could be done by a preference checkbox. This doesn't seem like a good 
idea unless the default is to 

3) Change the Moz Exit command to an entirely different key mapping.
   I just tried a number of applications and none of them used Ctrl-Q to exit. 
Among those tried on NT: IE 5.5 Sp2, Visual Slick Edit with Brief and CUA key 
mappings, JBuilder with Brief and CUA key mappings, JBuilder Help, PM Mail, 4NT 
command interpreter, MS Access 97 MicroPlanet Gravity. So Ctrl-Q is not a 
popular standard for exiting apps. 

4) Change the Close Tab from Ctrl-W to some other key stroke. But keep in mind 
on this one that people who use this command do so very often. It shouldn't be 
a Ctrl-Alt combination. It makes more sense to make it harder to close Moz than 
to close a particular tab web page. 

5) Have a user setting that optionally disables Ctrl-Q for Moz app exit.

I've accidentally exited Moz a half dozen times with upwards of 40 tabs open in 
a few windows when I was just trying to close a single tab. I just hate it when 
that happens. It is great that Moz has gotten so stable that one can leave 
dozens of tabs open to read at one's leisure confident that it will not crash 
before one gets to all the tabs and reads them all. Moz runs for a week or two 
at a time for me continuously 24x7 without crashing. I'm now losing it 10 times 
more often from accidental Ctrl-Q hits than from Moz crashing. So this bug is 
an app stability bug from my parochial perspective. 
2, 3 and 4 are bad since people are used to Ctrl+W closing window/tab and Ctrl+Q
closing everything. 5 isn't perfect since you could still lose everything to an
accidental Exit in the File menu. 1 is definitely the way to go, and it's what
4.x does.
Jonas, I'd personally settle for a preference that allowed me to disable Ctrl-Q 
entirely. I never use it. I run Moz continuously for a week or more 24x7 and 
never shut down. When I do shut Moz down there are at least 2 other ways to do 
it. 

I'm not so sure that is the best decision for everyone though. How often do 
average user start and stop their browser entirely? I'm also wondering what 
percentage of them use Ctrl-Q to do it. Most people I've observed use the mouse 
to shut down an app. Others use File|Exit (at least in apps that list shutting 
down a process as Exit - which most of mine do btw).

In reaction to the stated reason by mpt as to why 39057 was closed: I consider 
an exit of Moz to be a considerable loss. Therefore I disgree with the 
reasoning for making 39057 WONTFIX and hope the same reasoning will not be 
applied to 52821. Since the tab feature was added I've gotten into the habit of 
having dozens of pages open at once. Since some pages (eg web logs) have 
history scrolling off if Moz exits I lose what I loaded a day earlier. Even if, 
ala Opera, Moz could be enhanced to restart and reload all tabs using the URLs 
they last had loaded many pages would still would not be restored to the 
previous state. Also, some news sites expire pages. So not all page reloads 
will work.

See thread in netscape.public.mozilla.general "Close Tab and Close Window keys 
are too close" for more discussion.
Please, no dialog and no pref.

Personally, I'd go for Ctrl-Alt-Q.
What I like about having a dialog is that it would fix bug 39057 as well...
Ben, what is the argument against a dialog if there is a checkbox to get rid of it?
Because (if they appear at all), they should be reserved to something
destructive. Otherwise, the user will desensitize. If you have 50 urls open, or
a longer text in a textarea, then Exit is maybe destructive. In most cases, it
isn't (most users use exactly one browser window). Editors have a "dirty" flag
and only ask for confirmation, if there is actually something to lose.
Otherwise, it'd be annoying. Guys, you are power users. Very few people load a
page to read it the next day.
Average user even doesn't know something like keyboard shortcuts exist. So who
use them? Powerusers.

When Mozilla started to behave differently than Netscape4 and let you quit
without notice, it was annoying. But since Mozilla has tabs (and I know about A
LOT OF people who converted to Mozilla because of that), this is bad. Personally
I'm very calm, but accidental hitting of CTRL+Q when I have a lot of tabs open
is one of those things that make me loose my mind ^_-

BTW: If CTRL+ALT+Q is not bind to anything else (like, ehm ehm, CTRL+TAB), it
sounds very good to me.
Yeeesh Ben.  If closing every part of mozilla in one fell stroke isn't
destructive, what is?  :)  

Anyway, I could live with ctrl-alt-q.  The Mac people will have a problem I
think (since ctrl-q is very common on that platform), so be sure to keep away
from the mac platform.
A few points:

1) More people will keep more pages open once they start using tabs. Tabs make
it having many pages open at once a natural thing to do.

2) One of the latest trends on the web is web logs (eg
http://instapundit.blogspot.com to see what I mean). This way of communicating
involves lots of short posts with one or more links per post to refer to
articles that the post responds to. This sort of discussion lends itself to
having lots of pages open to news articles while reading one or more logs. 

3) In terms of state lost when a web browser exits I see a few parts to this:
   A) You lose which pages you had open.
   B) You lose text you had entered and switches you had set.
   C) If you are walking thru a large sequence of pages you may even need to go
back and start at an earlier place.
   D) You lose your place in a large article.

4) As Jiri points out, Power Users (wear that badge proudly) are the ones
learning and using keyboard shortcuts.  

5) Power users are people too <sob> and we don't deserve to be dismissed so
readily. I mean, <sob> <whimper> <sob> (on come on, stop whimpering) what have
we ever done to you? ;>

But lets turn it around: What are the reasons for leaving it as it is? How many
programs use Ctrl-Q to exit? I tried a dozen of them that I happen to use and
none of them did. Among those that I tried were the very mainstream MS Word 97,
MS Access 97 and MS IE 5.5 Sp2. So its harldy like there is a large mindset out
there among computer users in general that Ctrl-Q means exit or close anything.
If Mac uses Ctrl-Q for that purpose then I can only say with all due respect to
Mac users that they are about 3% of the market and not setting standards at this
point. If NS 4.x does use Ctrl-Q to exit it keep in mind that NS 4.x is a small
and dwindling portion of the browser user base at this point and it has the
pop-up dialog to prevent accidental exit. 
> As Jiri points out, Power Users (wear that badge proudly) are the ones
> learning and using keyboard shortcuts.  

I assumed that the dialog is for both they menu item and the keyboard shortcut.
Compare bug 39057 and note that it would probably harder to implement to
separate both.
A confirmation dialog for File|Exit would be a usability disaster.
> A confirmation dialog for File|Exit would be a usability disaster.

We see "Do you want to save your changes to the active document before
quitting?" dialogs everywhere, and I wouldn't call them disasters... and 4.x had
a dialog for File|Exit.
Guys, please read what I wrote before replying to me. If you have "active
documents" (forms with significant content) or many open windows, I do't oppose
a dialog. I just oppose one that appears in all cases, because the mentioned
cases are the *exception* (maybe not for you, but overall).
Imagine the Windows Calculator or the RealPlayer would let you confirm a quit.
It would drive me nuts.
I don't think making the dialog only pop up when there are at least X windows
open is an option.  Ben: if there is a checkbox to turn off the dialog, won't
the single window user just turn it off and be done with it?  Or if they only
use one window, is it asking too much to assume that they'll read a dialog?
> I don't think making the dialog only pop up when there are at least X windows
> open is an option

I don't see why it isn't an option. 4.x did it.
In reply to Ben's comment 42:
Both Calculator and RealPlayer have a single window -- when you quit, you know
exactly what you're doing. Moreover, if you have several instances open you need
to close them one by one. The browser should behave exactly like that.

A realistic scenario is having several Mozilla windows open, some looking very
different (e.g., mail-related stuff). From the naive user's perspective, there
is nothing in common between these windows -- each of them was opened separately
from the Programs menu (or equivalent). The fact that all are handled by one
instance of MOZILLA.EXE is a technicality which should be, and usually is,
transparent. The Exit option breaks this transparency, and in the worst possible
way -- guaranteed data loss without confirmation. 

If each Mozilla window looks like an independent application, a "close all
Mozilla windows" command simply does not make sense. Indeed, Internet Explorer
(which runs as a single instance of IEXPLORE.EXE) doesn't have an global Exit
option -- how many times did you wish it did?

As for the claim that only power users create a lot of state: I've seen many
decidedly non-power users experience browser crash, and they didn't look too
happy either ("Damn, it took me so long to find these search results!"). Wrongly
invoking "Exit" (say, from Mail&News) has an identical effect.

Personally, I'm a power user and very fond of effective commands and quick
shortcuts. Yet, I'd never think of using a command whose effective meaning is
"Quick! Forget anything that has something to do with the Internet!" -- unless
my boss passes by, that is. :-)
mozilla2eran@tromer.org, that belongs to bug 65121.

> won't the single window user just turn it off and be done with it? 

No, he will be scared to mess something up and just confirm the useless dialog
each time.
Well then, I'll whip out my tiny little violin for him/her each and every time
this happens.  If they care, they'd learn to read (as long as the dialog wording
is clear, it should be fine.)
I tend to use Ctrl+Q a lot to close all open mozilla windows.

But I don't use Ctrl+W anymore after pressing Ctrl+Q by mistake one too many times.

I don't oppose a "close everything" shortcut (I use Ctrl+Alt+Del when I want to
quit Enlightenment, and it *asks* for confirmation even if there's nothing
open), but please, make it harder to hit by mistake...
How hard would it be to add an option in preferences to "confirm ctrl-q exit" so
that people who DO use ctrl-q often can leave it off, and people who very rarely
use ctrl-q can turn it on, and if they bump ctrl-q by accident they get a
dialog.  If they really mean to exit then they just say yes.
> How hard would it be to add an option in preferences 

That's not the point. The point is that each new dialog, each new pref
diminishes the rest of them, and the rest is much more important. Esp. if there
are alternatives.
Well we're spending a bloody long time debating this issue for something that's
"not important" then.  I do consider it important when I lose many browser
windows because I accidentally bumped the key next to the one I wanted. 
Undesirable actions should not be linked to the key next to a desirable action,
it's a recipe for **** people off.  Traditionally, ctrl-q and ctrl-w have
both been close functions so it makes sense to keep the letters the same but
make it harder to activate one function when you're trying to do the other one
(ie make it alt-q, or ctrl-shift-q or something).
I too am a bit perturbed by ben's trivializing the loss of multiple data.  Sorry
ben, but you're the only one here with that opinion.  Let's just make it
ctrl-alt-q and be done with it!
I just went thru and read all the messages after I posted my list of
alternatives. It looks like no one objects to Ctrl-Alt-Q as a solution. Does
anyone object to Ctrl-Alt-Q as a solution?

Do we need to put this proposed solution out to a larger group of people to
ensure this is not going to cause any objections?
You need approval of the moduke owner, which is effectively Peter Trudelle
<trudelle@netscape.com>, I think. After that, you need the usual review and sr
for a concrete patch.
IF you want to be really nice, you can post to a newsgroup. But usually,
*anyone* will object to anything. If he is in the minority (which is the case
here, it seems), it depends on the reason he gives.
Thanks for nailing this down, finally.
Just recognise that something needs to be done, and think of the best way to do
it and then do it.  Nothing worse than people who are too scared to do anything
unless they get no objections.  Trying to do things on a consensus basis NEVER
works, you can't satisfy everyone.  Just go with ctrl-alt-q or whatever
Uh oh, check out bug 69954.  Seems ctrl-alt combinations are broken on win32.  I
think the fates are against us here.
Depends on: 69954
Please avoid changing the common shortcuts. That would be against the HIG and
would confuse users.

The state of the browser is an asset that needs protection. (Currently, I have
63 browser windows open in three browsers. And I wouldn't want to lose them
because I hit the wrong key.) Perhaps the mythical "average user" only uses one
window, but that doesn't make the browser state power users generate less worthy
of protection.

Adding a dialog users don't want causes an inflation of dialogs. People just hit
enter. I suggest making the dialog opt-in instead of making it opt-out.

The destructive operation shouldn't be the default. I suggest making "Cancel"
the default and marking the other button "Quit".

mpt would probably be against adding clutter to the pref windows. I suggest that
a UIless pref be tested at least at first. That way at least the people who know
about hidden prefs could turn on the dialog.
Havn't we already established that ctrl-q is *not* a common key combination for
closing multiple windows applications?

Once again, I feel the need to establish the fact that windows does not have the
common association that multiple windows containing data are in fact *one*
application and there is no commmon expectation to be able to close all of these
seemingly unrelated windows with one fell swoop.  In windows, the application is
the window.  You close the window to close the application.  There is no
real/ingrained precedent that you can have one application with multiple main
windows.  The other expectation is a macintosh thing, where the application is
not completely tied to the window, but rather sits on the common menubar at the
top of the screen and can control multiple windows, etc...  

Please take this into consideration.
The arguments for changing from Ctrl-Q to Ctrl-Alt-Q for exiting the process 
are as follows:

1) Ctrl-Q is not considered by most users as a standard way to exit a process. 
Few applications use it to mean that. Go try Ctrl-Q on a bunch of apps on 
Windows (which is used by well over 90% of users) if you doubt this.
   So changing to Ctrl-Alt-Q is not an abandonment of a popular standard.

2) Other browsers do not use Ctrl-Q to mean exit process or even to mean exit 
or close anything at all. 
   MS IE does NOT use Ctrl-Q to exit its process. In fact, I can't find any way 
to exit all MS IE windows with a single key stroke. Each window has to be 
closed separately. Typing Ctrl-Q doesn't appear to do anything in IE. Well, IE 
is the most popular browser and most future Moz users will be people who know 
IE. 
   I also tried Opera and again Ctrl-Q did not exit it. In Opera Ctrl-Q 
means "Send queued e-mails from current account" and Ctrl-Shift-Q means "Send 
queued e-mails from all accounts". Ctrl-Alt-Q does not appear to do anything in 
Opera. Opera does not appear to have a key mapping for exit process.  

3) There appears to be some opposition from Netscape developers to having a 
warning dialog on exit. It used to be there in NS 4.x and they took it out for 
Moz and NS 6.x. Read the discussion on this bug and elsewhere (eg Bug 39057) 
for the reasoning. 

4) There is also opposition to adding a pref to disable Ctrl-Q or otherwise 
modify its behavior. Again, read the arguments. 

5) Most users do not use key mappings to exit Moz or Netscape. Most use a mouse 
to do so. So not many current users will be affected by the change.

6) A user who tries and fails to use Ctrl-Q to exit Moz will still be able to 
exit it a couple of other ways and those other ways are widely understood. One 
of those ways is common to all apps (click on the exit icon). The other way 
(File pop-down) will show the user the new key mapping on the Exit entry of the 
pop-down list. 

I personally want A solution and would accept any of several possibilities. 
Since Ctrl-Alt-Q seems to elicit the least amount of opposition this choice 
seems like the way to go.

BTW, a reason to prefer Ctrl-Alt-Q rather than Ctrl-Shift-Q is that Ctrl-Shift-
Q is too close to Ctrl-Shift-W for closing a window. The use of Alt makes a 
mistake less likely.
*** Bug 125974 has been marked as a duplicate of this bug. ***
nsbeta1- per ADT triage. 
Keywords: nsbeta1nsbeta1-
Another argument for giving Ctrl+Q and File>Exit a dialog when there are
multiple Mozilla windows open, or for removing File>Exit and putting File>Close
at the bottom of the menu:
Most users only have one browser window open at a time.  If a user browses in
one window most of the time, he might not find out that File>Exit closes "all
mozilla.exe windows" until the the first time he tries browsing using multiple
windows.  This might discourage him from browsing in multiple windows in the future.

re rgparker:
Opera does have a way to close all Opera windows: Alt+F, X.  Of course, Opera
having a feature doesn't make it right for Mozilla to have it, or even for Opera
to have it.
Wow! This really needs a quick and fast solution!

I do know that keymapping guidelines on other plattforms than Mac are verry
different, but I do know that they are completely fixed on the Mac. So remapping
"Quit" to something different is no option there.

The Apple HIG also says (AFAIK) that any potential dataloss _has to_ have a
dialog before it in a way that just hitting enter without reading it _wont_ give
you the dataloss.

So I cant speak for other plattforms here, but this is a clear violation of HIG
on the mac and therefore needs a quick fix by having (maybe an opt out) dialog
box that asks bevore Mozilla quits.

-----

For the other plattforms: I cant really speak for these "normal" users with only
one window open. But if I read it right what other people tell here and
elsewhere then only those mythical PowerUsers really _use_ shortcuts on these
Plattforms, because they are soo different in every Programm that no "normal"
user starts to learn them.

If this is the case, then it wouldn´t (IMHO) hurt to have some safety net on
these plattforms too... but thats something the users of these plattforms will
have to discuss with themselves.
Ahh mist. There was an error in my last post: for shure the Dialog should _not_
 be  oopt out! Just as every other app behaves.


It imho would be usefull though to have moz save the currently loaded set of
websites and form-content on <enter>.
And it is debatable if this dialog should only fire if mozilla is in some sort
of "dirty" state, which could mean, having more than one window open, or one
window with more than one tab etc.

<rant> What I really dont understand is why theres no expert prefferenzces all
around. When you all agree that the basic prefferences need to be simple and
clean, then why doesn´t mozilla just have a small "expert" preffs button
somewhere at the bottom of the preffs dialog, that takes you to all these preffs
that every poweruser loves? </rant>

Sorry to spam you again. :(
> It imho would be usefull though to have moz save the currently loaded set of
> websites and form-content on <enter>.

Bug 36810
For your information, the Konqueror browser doesn't do anything on ctrl+W, but
it will close the current window on ctrl+Q. I can't say I like this behavior,
but it means that some Konqueror users are in for an unpleasant surprise when
using Mozilla for the first time.

My experience is that I have accidentally hit ctrl+Q in Mozilla too many times,
when aiming for ctrl+W, and it was terribly uppsetting each time. I don't care
much for a shortcut for Quit, but I use ctrl+W extensively and I would hate to
see that go.

Is there any hope that ctrl+Q will be disabled before Mozilla 1.0.0 hits the
streets?
Severity: normal → critical
Mpt, could you please tell us what should happen here? One good reason why we
haven't got a patch could be that nobody knows what that patch should do...

It seems that the four options here are to 1) change Ctrl+Q to something else,
2) remove the shortcut completely, 3) add a pref which allow you to disable
Ctrl+Q, or 4) make exiting Mozilla completely display a confirmation dialog *if
and only if* there are two or more windows open.

Personally I'm in favor of either option 4 (it should *of course* not happen
when there's only one window open, that would be a nightmare) or option 2.
One vote for "2) remove the shortcut completely".
hmm, I vote for option 4), I also got bitten by the Menu-Command "Exit", we
cannot remove that.
Voting for option 4 here too. (make exiting Mozilla completely display a
confirmation dialog *if and only if* there are two or more windows open.)

Suggestion:
"This will close all opened windows in Mozilla. Are you sure you want to do this?
[Yes] [No]
[x] Don't ask me this question again"

(Execuse me for spamming, but I can't just vote for the bug since there are
several alternatives!)
*** Bug 148701 has been marked as a duplicate of this bug. ***
Voting for option 4), too, but slightly modified: "make exiting Mozilla
completely display a confirmation dialog *if and only if* there are two or more
windows OR TABS open" (i.e. even one window with two tabs should trigger the
dialog). Also, the dialog should make it clear that this includes not only
browser windows but also mail windows etc. (Actually, I find the very existence
of this command completely unnecessary and misleading, but removing it has been
rejected, I think.)

It is amazing that a bug that stirs much emotion, that should be trivial to fix
and that involves serious dataloss (as agreed by overyone except Ben Bucksch, it
seems) has remained open for 21 months and will now obviously even make it into
the 1.0 release. :-((( I admire the Mozilla project and its organization and all
the work than went into it, but I really think there is something rotten here.

(Oh, and sorry about the dupe.)
--> me (i'm working on a patch)
Assignee: mpt → jonasj
Keywords: patch, review
Target Milestone: Future → ---
This patch will make a confirmation dialog appear when you press Ctrl+Q or
choose File|Exit if there are multiple windows open. If there is only one open
window, the dialog will not appear.

Known problems with this patch:
* It asks a Yes/No question but shows an OK/Cancel dialog
* It will not ask for confirmation if there are multiple tabs in the same
window (that should probably only happen on Ctrl+Q, not on File|Exit)

Comments are welcome.
Instead of "Close all windows and exit %S?"
concider this:
"This will close all windows and exit %S."

Since the respond from the user can be either OK or Cancel, it makes more sense
to inform what Mozilla will do, than asking the user what to do.
For a proof that the Quit (Exit?) command is totally counter-intuitive, see
http://www.cnet.com/software/0-3227884-8-20005816-4.html - the second page of
CNET's review of Mozilla 1.0. Quoting paragraph "Some buggy extras": :-)))
[...] Some of these tools behave in unexpected ways. For example, when we ran
File > Quit from the JavaScript debugger, instead of closing just the debugger
window, it closed all of our Mozilla browser windows, as well--definitely not
the behavior we expected or wanted.

To Jonas' comment #74: the second problem you mentioned is a serious one. I
rarely have more than one window open ever since Mozilla has tabs, and Ctrl+Q
gets mistaken for Ctrl+W exactly when closing a tab in the single open window.
In my experience, at least. :-(
Really, I'm astonished that Mozilla 1.0 went gold with this bug ignored.  This
is a SEVERE usability problem, and it's been ignored because there's been no
complete concensus about how to resolve it.  WHY WASN'T THE SHORTCUT REMOVED? 
Many, many people have become VERY upset at the dataloss from accidently hitting
Ctrl-Q, and it's VERY common because it's right next to Ctrl-W.  How many people
start and quit Mozilla so often that they need a shortcut to do it FASTER?  If
they are, chances are good that hitting Ctrl-W once (or maybe a couple times)
will work well enough, and is selecting it from the menu really such a hardship?

I stopped using Mozilla entirely in March (after using it for a year and a
half).  I switch to Galeon, because of the tabbed browsing (which Mozilla now
has), and the crash recovery capability (which Mozilla doesn't).  This bug was
also an annoyance I was tired of dealing with in Mozilla.  Galeon defaults to
assigning Ctrl-Q to quit too (imitating Mozilla), but it's trivial to disable,
and that's one of the first things I did.

The keyboard shortcut for Quit should be removed entirely.  Then power users who
really want the shortcut can add it -- put the instructions in the release notes
for how to enable it.  Don't upset people by subjecting them to unnecessary
dataloss for a shortcut that's of highly questionable value in the first place.

Why is this so hard to see?  If there's disagreement about what's best, don't
leave in a single keystroke that blows away the entire application and dozens of
windows and/or tabs that may be open!

Now that Mozilla 1.0 is out, I'm going to TRY to switch back to Mozilla, but I'm
going to switch back VERY fast if I start getting dataloss from crashes or this
bug.  And despite all the claims of how "easy" it is to change the UI, I've yet
to see an example of how to get rid of this extremely dangerous keybinding.  Am
I going to have to spend hours studying XBL files and documentation, or could
someone please just tell me?
Maybe this bug would best be resolved by removing the Ctrl+Q shortcut entirely,
since that would work around the problem of my patch not giving a warning when
there is only one window but multiple tabs. I now think that this would be a
reasonable thing to do; as Quit is a rarely used feature, not much value is
added by a having keyboard shortcut for it. We'll still need to show a warning
on File|Exit with multiple open windows though, but if we decide to remove the
shortcut, the File|Exit warning should be taken to a separate bug.

So now my question is: Whose decision is it? The default assignee for Keyboard
Navigation is aaronl; is it you who make the calls on these sorts of things, or
is it a module owner? And who would that module owner be?
Component: User Interface Design → Keyboard Navigation
A simple way to disable the shortcut (option 4), would be to change

<!ENTITY quitApplicationCmd.key		"Q"> 
to 
<!ENTITY quitApplicationCmd.key		""> 

in

/xpfe/communicator/resources/locale/en-US/unix|win|os2/platformCommunicatorOverlay.dtd

(or 
\chrome\en-win|unix.jar\locale\en-US\communicator-platform\platformCommunicatorOverlay.dtd
in the compiled version)

for every locale apart from mac, where this command seems to be the norm. At
least as a stopgap solution? 

(Not that important, but it's inconvenient editing the jar file every time)
I came looking for this bug planning to propose removing ctrl-q entirely (after
missing ctrl-w again and losing about 8 tabs of stuff). I see that's already
been done. Ctrl-q is incredibly destructive. I don't think we need such a
convienient hotkey for such a major action.

(reminds me of the birdman commercial on cartoon network... with the big red
self-destruct button right next to the make coffee button.)

Keyboard users still will have alt-f, q, which I can hit just about as quickly
as ctrl-q anyway.
I think ctrl-Q is some (quite rare) times useful. I would vote to either confirm
quit (also on multi-tabbed windows as an extention of bug 108973) but not a
single window, or to remove the shortcut.

The guiding principle should be that if ctrl-Q is pressed when a document other
than the currently active one exists, it should be considered dataloss and
should require conifrmation (or a "power" combination like adding alt or shift).

Consider this: 

1. A user has one window open and chooses File|Quit or ctrl-Q. The user expected
a window to close, and that happened. No problem.

2. A user has more than one window/tab open. Either this is a power user, which
is most likely to have a lot of data to be lost and might be missing ctrl-W (and
thus won't object to a warning), or a simple user which opened "manage
bookmarks" or "mozilla mail" and doesn't expect other things to close. Again, a
warning is in place.

> I think ctrl-Q is some (quite rare) times useful.

"rare"ly "useful" dataloss things don't get easy access hotkeys. Lets ditch it.
No dicking around with dialogs, or harder to hit hotkeys. Alt-f, q is more then
enough.

--- platformCommunicatorOverlay.dtd~    Fri Jul  5 13:04:37 2002
+++ platformCommunicatorOverlay.dtd     Fri Jul  5 13:04:43 2002
@@ -9 +9 @@
-<!ENTITY quitApplicationCmd.key                "Q"> 
+<!ENTITY quitApplicationCmd.key                "">
I would like to vote for option 2 (remove ctrl-q entirely) *and* option 4 (when
quitting, give warning if more than one window open).

Would someone post a comment that walks one through getting rid of ctrl-q
locally until it's available as a patch for everyone?

Thanks a lot!
To disable this feature (until the powers that be deign to check in option 2)

Unzip %mozilladir\chrome\en-win.jar , preserving directories
edit locale\en-US\communicator-platform\platformCommunicatorOverlay.dtd

Change the line 

<!ENTITY quitApplicationCmd.key		"Q"> 

to

<!ENTITY quitApplicationCmd.key		""> 

Zip the whole lot up again, and copy it over the original. (zipmagic is very
helpful in doing this)
It might help to get to a solution if people would state whether more than one
of the potential solutions are acceptable to them. 

I personally would be happy with any of the 5 solutions I outlined in Comment
30. I would like to add a 6th choice that I overlooked previously: 

6) Totally eliminate the Ctrl-Q method of exiting Moz.
   There is already the Alt-F, X method of Exiting Moz with the keyboard. So the
Ctrl-Q method is redundant anyhow.

With these 6 choices in mind here are my preferences in order: 6 (eliminate
it),2 (Ctrl-Alt-Q for Exit),1 (dialog box confirmation for Ctrl-Q),5 (disable
Ctrl-Q in prefs),3 (totally different key mapping for Exit),4 (totally different
key mapping for Close Tab).

Again, any of these are acceptable to me. Even my preference order is not
strongly held. 
I really believe we need to remove Ctrl-Q. TWICE today I meant to close a tab
and ended up closing a lot of windows. Ctrl-Q is not a good option, nor
standard. More importantly it is WAY WAY too close to Ctrl-W which is in common
use. 

Alt-F4 is standard program closing behavior for programs in Windows, but of
course this has to be multiplatform. In linux it seems Alt-F4 is supported in
there (atleast in Gnome.. not sure about KDE, but I would assume so). What about
other platforms? I guess there is no Alt-F4 on Macs?

This is a major annoyance to not have something such that you can't close
Mozilla by the key next to the same shortcut as close tab (or open tab if it
were moved to a key near that).
Ok, guys, it seems almost unanimous that 

option 6 - disable Ctrl-Q entirely on Windows and Linux (not Mac)
(and file a new bug for a warning dialogue on File->Exit, accel-Q on mac)

is the way forward. If an interested person has any objection to this solution
(not necessarily the final one) being checked in, could they please make it
before Jonas gets back (which would be a week from now). I don't think anything
can really happen until he returns, but if we can show that there are no
objections, this would be a start.

Here is a patch for option 6. Could someone with authority either review it, or
add the review keyword. Let's get this moving :)
> option 6 - disable Ctrl-Q entirely on Windows and Linux (not Mac)

Why not Mac?

> (and file a new bug for a warning dialogue on File->Exit, accel-Q on mac)

No. Mpt will not allow a warning dialog; instead File|Exit should be removed
entirely for all platforms except Mac (bug 65121).

> before Jonas gets back (which would be a week from now). I don't think anything
> can really happen until he returns

Actually your patch could have been reviewed, super-reviewed and checked in and
this bug closed by now :-)

> Here is a patch for option 6.

Great, thanks :-) I suggest you mail aaronl@netscape.com for a review.
Jonas: AFAIK: Due to the way that macs deal with multiple windows in one
application (they share the same file menu), the quit command makes more sense
since it is more obvious that all of these browser windows belong to one
application.  Windows doesn't show this bond because each window has its own
menu.  File quit was the standard way of closing an entire application in all of
the applications I've used in my brief stints on macs.
Ben: Yes, as I said, the menu item should not be removed from the Mac. What's
your point?
I'm not certain, but I think that most mac applications use command-q to do the
same as file-->exit, and therefore on mac it should stay
(http://docs.info.apple.com/article.html?artnum=106743) makes reference to it,
for example.)

I don't know about OS/2, however. Does anybody know if ctrl-q is appropriate?
Jonas:  you asked "why not Mac"
Perhaps I should make the final step in my explanation.
A) File>Quit is common on Mac
B) ctrl-q is the common shortcut for quit on macs
This bug was entitled, "too easy to hit ctrl-q instead of ctrl-w", but i have
renamed it to what i believe is a more accurate description, "Disable Ctrl-Q on
non-Mac platforms". 

If this was an inappropriate action, i apologize.
Summary: too easy to hit ctrl-q instead of ctrl-w → Disable Ctrl-Q on non-Mac platforms
i'm not actually actively supporting this patch or any others, so don't expect
me to ask for the review (and i'm not going to give it either), but standard
practices include using cvs diff -u (done). and getting module owner approval.

find blake, jag, hewitt or hyatt and ask them to approve it (by means of sr).
Attachment #37871 - Attachment is obsolete: true
Attachment #91435 - Attachment is obsolete: true
A _real_ fix for the bug would be to remove File|Quit altogether on non-mac
platforms (including its shortcut), and moving Close to the bottom of the menu.
biesi: Yes, that is bug 65121.
No longer depends on: 69954
Reassigning to patch author
Assignee: jonasj → lj
Are Ben Buksch and mpt the only people who *don't* want a confirm dialog?
Comment on attachment 92770 [details] [diff] [review]
os/2 follows windows. beos follows macos

If all we're doing is disabling Accel+Q, then this is not the right fix. If
that's really the best thing to do, then any references to
quitApplicationCmd.key should be removed from the XUL and the DTD.

IMHO, a confirm dialog really is appropriate here, and we shouldn't slavishly
follow the dogma that all confirm dialogs are bad. Yes, they're bad in some
places - but this is one place where it's genuinely useful.

If we're going to have a command that closes all windows and exits, even if
it's from the menu, certainly the user should have a chance to confirm it!
Attachment #92770 - Flags: needs-work+
I wholehartly agree to this!

But I believe there is actually a bug open to achieve exactly that. Perhaps we should make this a duplicate of it?

Cu Martin
I disagree. 

The confirmations should be separate for each window that has unsaved data:
eg. unsent mail, unsubmitted text in the form, unsaved web page, unfinished
download.

This will continue to work fine when the Quit function is ultimately removed.
Please keep this bug focused on removing the shortcut only. This has the least
resistance so far.
I've reconsidered my own stated preferred solution rankings. I do not understand
the reasoning for why removing the Exit command entirely is considered an
acceptable solution while a dialog box warning is not considered acceptable.
Exit is a useful command for some people. At the same time the problem is that
Exit causes dramatic effects and can be done by accident (especially with the
keyboard shortcut). Dialog boxes appear to be some sort of taboo and so that
leaves the removal of the command as the only remaining choice?

I'm leary of simple rules. Just because a technique in UI design gets used
excessively and inappropriately (in this case dialog boxes) is not a reason to
eliminate the technique entirely. Similarly, just because a particular command
is powerful in its effects (in this case Exit) is not a reason to remove it
entirely.

Still, if the only solution that is acceptable to the powers that be is to
remove the command I'll go along with it. However, note that this solution still
leaves Mac users with a problem. So would a dialog box be an acceptable solution
for Mac users?
The reason we're keeping quitApplicationCmd.key in the DTD is that we're not
disabling it on mac platforms (wherre it remains accel-q), whereas we're
explicitly disabling it on windows, os/2.

In my opinion, keeping file-->[close all windows] and adding a warning is the
way to go, but it should not be at the bottom of the file menu. (close tab/close
window should be, but which one?)

Another thing that needs to be considered is that file-->exit gets pressed by
windows when it tries to shut down, and at the moment mozilla displays no
warning. Notepad does. 

Has anyone else seen adobe freehand (admittedly a mac application/port)'s 'there
are unsaved documents: review, cancel, exit' dialogue? Something like that would
be more flexible than 'close this window? How about this one? Or this one?'

(Quite a lot of this is reiterated from bug 65121 , which is concerned with
removing file-->exit (and therefore removing the need for a warning) and bug
39057 , which is the actual warning dialogue one, and has been marked wontfix at
the moment)
I think we should disable accel+Q on the Mac as well. It might be a common
shortcut, but I feel that the dataloss caused by an accidental accel+Q outweighs
the benefit of having the shortcut.

aaronl, what do you think?

Everyone: Please take your discussion about whether Exit should be removed,
moved, renamed, showing a warning dialog, etc. to bug 65121.
I'll leave the decision about Mac to MacDev.
regarding comment 105, command-Q *must* be available on Macintosh; I will veto
any patch I see that removes it (as will other people on macdev).

In my opinion, this bug should be WONTFIX and the real fixes should be in bug
65121 or other similar bugs.  Closing a window (accel-W) also causes dataloss
but I don't see a patch to remove that keybinding so the current strategy seems
very flawed and inconsistent.
> regarding comment 105, command-Q *must* be available on Macintosh

So, Aaron, as we can't remove all references to quitApplicationCmd.key (as you
suggested in comment 99), can we check in attachment 92770 [details] [diff] [review]?
Comment on attachment 92770 [details] [diff] [review]
os/2 follows windows. beos follows macos

I just grepped through the soruce code to look for examples of
<!ENTITY fooCmd.key		"">
but couldn't find any.
How do we know this is intended to work, and won't cause problems?
Comment on attachment 92770 [details] [diff] [review]
os/2 follows windows. beos follows macos

Okay, I don't mean to be difficult. It works, so r=aaronl.
Attachment #92770 - Flags: needs-work+ → review+
regarding comment 107, pressing alt-f4, delete, (ctrl-c when there's a
highlighted selection) causes dataloss. The question is how much. On windows and
unix, the 'maximum acceptable dataloss' a keyboard or mouse shortcut can produce
is one window's worth (alt-f4, ctrl-w, click on the 'x', etc.) If you want to
cause more dataloss on windows or unix, you need a menu or a terminal (or press
the reset switch :).

Ctrl-Q causes an unexpectedly large amount of dataloss for a keyboard shortcut,
and that's why it has to go. That it is exclusive (amongst windows apps) to
netscape 4 and mozilla, and too close to ctrl-w is just the icing on the cake.

It would be nice to see bug 65121, bug 28385, bug 143266, and bug 48333 fixed,
but I feel it is best to stop the bleeding before we operate... :)
Lewis, thanks for the instructions on disabling the Ctrl-Q shortcut -- I've been
wondering about that one for a long time.  I'll try to remember to do it next
time I try to use Mozilla again.  (I switched back to Galeon for its crash
recovery after Mozilla 1.0 crashed on me a couple times...)
Comment on attachment 92770 [details] [diff] [review]
os/2 follows windows. beos follows macos

I really don't like this.

I prefer the ctrl+alt+q solution (keep command+q on mac though) over disabling
it.

With regard to the menu item, I'd like to see the text changed to "Quit
Mozilla" (and "Quit Netscape") to make it more clear what you're quitting.
Attachment #92770 - Flags: needs-work+
Or "Exit Mozilla" (for you Windows people out there ;-).
Setting the summary back to what it was. I believe it more accurately describes
the problem and makes this bug easier to find.
Summary: Disable Ctrl-Q on non-Mac platforms → too easy to hit ctrl-q instead of ctrl-w
> I prefer the ctrl+alt+q solution (keep command+q on mac though) over
> disabling it.

May I ask why?
Control-Alt may be problematic on windows - it conflicts with windows' shortcut
keys for launching applications. Potentially, a user could override it with some
other function
(http://www.techtv.com/callforhelp/answerstips/story/0,24330,2563408,00.html).

Another thing to consider is [alt-gr]
(http://www.microsoft.com/globaldev/europe/altgmsdn.asp), which (on some
keyboards) sends [right-alt]-[ctrl]. [Alt-gr]-q would seem to be the german for
'@'. Can mozilla tell the difference between left-alt and right-alt?
Jonas, I think there should be a command for exiting the Moz process for a
simple reason: Moz is a process. Lots of things go wrong that affect the whole
process that can require the user deal with it as a process. It can start
growing out of control. It can have a thread that starts running continously.
Some nasty site can start opening lots of windows. 

The main problem with Ctrl-Q is that it is too easy to hit. Its a very useful
command when one needs it. It just isn't needed anywhere near as often as one
can hit it by accident. Either put up a warning dialog box (which seems taboo
for reasons that seem like a case of elevating a useful-most-of-the-time rule
into religious dogma) or make the key combination harder to hit. 
rgparker:
> I think there should be a command for exiting the Moz process

There is such a command. It's called File|Exit. Removing the shortcut does not
remove the command.
Jonas, in order to use File|Exit you need the File option. If, for instance, a
mad window making page is popping up windows that don't have a task bar (or
whatever that bar is called) then that way of telling Moz to exit will not be
available. 

Of course, over in http://bugzilla.mozilla.org/show_bug.cgi?id=65121 it is
proposed that File|Exit should be removed as well. Similar arguments are made
for that proposal and for the proposal to remove the shortcut method of exiting. 

There are two questions here:

1) Should there be a way to exit the Moz process? (leaving aside the way each OS
has for killing processes)

2) If the answer to question 1 is Yes then what should be the way(s) of exiting Moz?

> Jonas, in order to use File|Exit you need the File option. If, for instance, a
> mad window making page is popping up windows that don't have a task bar (or
> whatever that bar is called) then that way of telling Moz to exit will not be
> available.

Irrelevant; we have prefs that will prevent mad pages from doing that.
> 1) Should there be a way to exit the Moz process? (leaving aside the way each OS
> has for killing processes)

Simply put the Exit (aka Close All) in another menu, like Tools or Window. And
add a confirmation dialog to it.

This bug is about the ease with which people hit Ctrl+q when trying to type
Ctrl+w; even just changing the key combination is good enough.
Just because there's prefs, that doesn't make the possibility of an endless loop
of popup windows irrelevant.  After all, if you don't happen to have your prefs
set to block that behavior, the existence of the prefs hasn't solved your
problem when the windows start popping up.

That sort of loop is also a good argument for keeping SOME keyboard shortcut for
Quit, but Ctrl-Q is still too easy to type.  Ctrl-Shift-Q or Ctrl-Alt-Q would be
fine, probably.

If Mozilla would save the entire session upon Quit, it wouldn't be as much of an
issue, but I guess that discussion belongs in another bug.
I still believe that file-->'exit mozilla' is the only way that's needed to quit
everything. We shouldn't be concerning ourself with scenarios where the browser
becomes unstable or out of control - chances are we can't predict them all
anyway. Who's to say it would respond to a keypress when the user can't bring up
the file menu? Closing unstable apps is the job of the operating system, not the
app.

Under Windows and UNIX (I'm ignoring mac, because this bug desn't change
anything on it), there's a difference between quitting and killing a process.
Quitting (kill -3, close from the applications tab under NT, end task from the
CTRL-ALT-DELETE menu under 9x, log off under either windows) is functionally
equivalent to file-->'exit mozilla', letting the application quit cleanly and
save any data (Except that windows only gives it a finite time to do it in
before it kills it). Killing (kill -9, close from the processes tab under NT,
wait and confirm after timeout under 9x) the process ends it immediately, and
doesn't let it clean up after itself. 

If mozilla is running away, a quit command from the operating system is what
should be used to close it, rather than relying on a keyboard shortcut.

Most other apps don't have such a shortcut (internet explorer, microsoft office,
freehand, visual basic, etc.) Opera, however, does (CTRL-SHIFT-W). If we have to
have a keyboard shortcut, I vote for CTRL-SHIFT-W instead of CTRL-Q or
CTRL-ALT-Q. (see comment 117 for my issues with CTRL-ALT shortcuts).
Lewis: Ctrl+Shift+W is already taken; it closes the current window (Ctrl+W only
closes the current tab).

I agree that we do not need a keyboard shortcut.
Under NT (and probably W2k and WXP) if you click on the upper right corner then
there is a finite amount of time before it pops up a dialog asking if you want
to kill immediately or to wait more time. You can just not respond to that
dialog and when the app finally exits the dialog goes away. So the OS never
forces the app to close unless you bring up the Task Manager and tell it to kill
the process. 

However, with a keyboard shortcut the OS does not know that the app is trying to
exit itself and so the OS will not pop up that dialog (or it won't do whatever
it does on Win9x either). So its not an equivalent way to exit a process. 

Also, there are conditions where a keyboard shortcut is better than File|Exit:

1) The video driver can go crazy and won't restore itself until the offending
app is exited. In that case (and I've experienced this a number of times) you
can't even see the File option. 

2) The memory can be swapping so hard or the CPU can be so bogged down by an
aberrant app that trying to click open the pop down list takes a very long (even
minutes) time. A keyboard event can get thru a lot more quickly. 

So, yes, a keyboard shortcut has some advantages over the various other approaches. 

This has been a major issue for almost 2 years. Anyone for trying to target this
to 1.2 and getting this resolved? There are other bugs which can deal with more
complex dialogues and prompting about certain data loss of emails, etc. This
happened to be again tonite and really needs to get resolved. Even switching
this to Ctrl-Shift-Q would be a major improvement over the current situation to
prevent this extremely easy to occur dataloss situation.
Keywords: mozilla1.2
It happened to me twice today!

In one case I was in the middle of commenting on another Mozilla bug, the irony...

Prog.
jag, could you reconsider your really not liking this? Ctrl+Alt+Q is not an
option due to bug 69954.
As well as being technically impossible at this point, ctrl-alt shortcuts are A
Bad Thing,  as stated in
http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html .

Having read it through, I'd like to suggest CTRL-Q to quit on mac, and
CTRL-SHIFT-Q to quit on any other platform, where CTRL-Q is less standard. 

Would that be acceptible?
Comment 130 suggests changing Macintosh to Control-Q for quit.  This is
unacceptable.
I still don't see why we need the shortcut in the first place. How often do you
close Mozilla entirely while you have multiple windows opened? And if you do,
how hard can it be to select File|Exit do achieve the task? Or even Alt+F,X if
you really need to use the keyboard for this (rare) command.

I suggest removing the Ctrl+Q shortcut alltogether.
Comment #131
> ...changing Macintosh to Control-Q for quit.  This is unacceptable.

You forgot to explain why, allow me:
The standard on MacOS is CMD-Q, not CTRL-Q. That's all.

David (Comment #132), your suggestion is spot on.
Why is NSCP management against removing the shortcut entirely? Do you really
think your target user group is making proper use of this dangerous command?
Just curious.
Appologies for comment 130 - slip of the keyboard :) 'CTRL' should, of course,
have been 'accel', for

'I'd like to suggest accel-Q to quit on mac, and
accel-SHIFT-Q to quit on any other platform, where accel-Q is less standard.'
And maybe you could also explain why you need the shortcut in the first place,
Lewis?
David, as far as I'm concerned, the reason we need the shortcut (ignoring macs)
is that it doesn't seem likely that a patch removing it completely will get
checked in any time soon. I think it just as pointless as you do (comment 124).
However, there are many people who want _a_ shortcut, at least (comment 126,
comment 113). I'll leave it to them to explain why it's necessary, but in the
meantime, I think a compromise would allow us to progress.

With accel-shift-q, 

- People who want it still have a shortcut
- People who don't are much less likely to press it by accident
- Mac users (who have come to expect accel-Q to do this) see no change
- The shortcut is available (in some form) on all platforms, making life more
consistent for people who use mozilla on many platforms.

So, in summary, I think we need this shortcut because taking it out entirely
would just make a different set of users unhappy. 
> doesn't seem likely that a patch removing it completely will get checked

Seems to me the Keyboard Nav owner, aaronl, would allow a patch to remove it,
based on comment 99 and others.

> With accel-shift-q, People who want it still have a shortcut

Alt f x is much easier to hit, more discoverable, and backwards compatible. I
don't see anyone WHO has a problem with this for UNIX and Windows. Can't we
check that in and let Mac continue to rot and have dataloss, if that's the way
they want it?
It is my impression that if this feature change
http://bugzilla.mozilla.org/show_bug.cgi?id=65121 is implemented then Alt F X
won't work either. The argument for 65121 is that its easy with the mouse to
accidentally click the wrong iten on the File pop-down list. So it sounds like
65121 might get done as and then Alt F X won't work as an alternative. There's a
really basic question: Mozilla acts like a single process. So should it have a
way to be told to exit itself? I think that seems reasonable. The only problem
is that its currently too easy to do by mistake. 

If Moz had a way to start separate processes that would help as well...
Wihle aaronl has reviewed it as acceptible (comment 110), jag (peer XPApps,
XPToolkit) has marked it for superreview as 'needs work' (comment 113), which
means that there are two courses of action - have a huge argument about it
(which will boil down to "I hate ctrl-Q it's evil" vs "I like/need ctrl-Q,
removing it is evil"), or work on the solution to make it more acceptible. I
believe the latter course of action is the most likely to succeed.

The main objection to ctrl-Q isn't that it's stupid or irrational (Anyone who
uses a mac regularly would expect there to be a shortcut to quit the entire
process. That it's survived in MacOS for decades suggests that it's a shortcut
people find useful), but that it's too easy to press by accident. If we accept
that removing it entirely will just antagonize people, what remains is to make
it harder to press by accident. I believe that doing this is likely to get it
checked in without the need for a holy war.

On the subject of alt-f,x it isn't a shortcut. It is merely using the keyboard
to activate file,exit. This only works if there is a file menu on the current
window, and mozilla isn't too broken to display it. (Reasons it might not
include javascript menuless windows, general breakages, system thrash, (win9X)
running out of system resources, etc.)

On moz as a process, there's a way to kill the entire process dirtily, shouldn't
there also be a way to do it cleanly? It's just asking for it if users are
forced to use end task because the Right Way to do it has been taken out. I think.
*** Bug 168646 has been marked as a duplicate of this bug. ***
qa to default
QA Contact: zach → sairuh
Could someone please make a decision about this one.  Would it not be sensible
to add a preference where you can have confirmation of exit or not and then it
is upto the individual user if the feature is used.  This seems fairer than the
issue being decided about by the developers.

?????
Heh. The preferences dialog is also known as the "unsettled arguments dialog"
for just this reason :-)
As far as warning dialogues, when (if?)  bug 28385 and bug 48333 are checked in,
mozilla will give a warning dialogue on closing if it will break downloading or
discard an unsubmitted form, reducing the dataloss significantly. I can see no
advantage to a pref that switches these off.
*** Bug 170325 has been marked as a duplicate of this bug. ***
I'm voting for an option like

  Ask for confirmation on exit...     1) always
                                      2) only if more than one tab is open
                                      3) never (default)


Did I miss the party for the second anniversary of this bug?

Anyway... just adding my vote for any of (roughly in my order of preference):

a) removing Ctrl-Q entirely (ok, so this won't happen, fine)
b) a (configurable) confirmation dialog 
c) changing it to Alt-Shift-Q (or equiv)
d) move closing a window to some further away key.

It would be really nice to have the general "reassign shortcuts" feature, but in
the mean time this is incredibly annoying. I just lost a large pile of context
accidentally for the 5th time in 2 months by trying to close a window. 

Does anyone know if there's another bug/request I can vote for that would save
your context so it could be recovered across sessions (especially after a crash)? 
I agree.  Having Crtl+Q blow away the application is incrediably annoying, and
two years is *way* to long for this bug to have been open.  Please do *something*.
Can we PLEASE PLEASE PLEASE PLEASE change this to add say a shift to this so
Control-Shift-Q. It would be a simple fix and help this HUGE dataloss issue. And
could we try to get it in for 1.2 Beta or at the minimum 1.2 GA. This is a huge
issue with a simple initial solution.
Somehow, IE gets by without a Quit even in its menus, much less a too-convenient
hotkey for it.

Can we just remove the hotkey completely for 1.2 and see how it goes? 1.3 is
only three months away if we decide to change which solution we use.
FYI: This bug is fixed in Beonex Communicator 0.8.1. The Menu item is called
"Quit/Exit Communicator", and there is no shortcut at all (i.e. Ctrl-Q is gone).
Everybody who is complaining, feel free to use Beonex Communicator.
Keywords: patch
I also would like to see it fixed after all this time as it hits me aprox. every
two days!

And I personally think that many users (especially one that use Mozilla) are
"power-users" that never intend to turn off Mozilla.

For anybody who cannot wait any longer, comment #79 describes a nice workaround
that also works for compiled versions (you need to look at /chrome/en-unix.jar
or /chrome/en-win.jar). You will have to change the jar-file while Mozilla is
not running, though.
Hi there!

As I see it, there are more ways to a solution. We could remove the shortcut (not an option on Mac), we could view an OK/Cancel dialog each time someone choose "Quit" (Not an option on windows -> too many dialogs), we could display such a dialog only if some documents where "dirty" (needs to define dirty, perhaps as a pref, so this could be off by default) or we could simply restore everything after a restart of Mozilla.

Well, as I see it the first and second solution has no chance. The third would be acceptable by me, but its still not perfect. Number four on the other hand, seems like the cleanest solution to me (of course you could disable it, see Opera as an example).

So the real remaining question is: Where is the bug for number four and why isn't this one closed as "wontfix"?

Sorry for spamming you so hard.

cu Martin
Martin, removing the shortcut *is* an option.

Jeremy M. Dolan seemed to have phrased it just right in Comment #138:

> Alt f x is much easier to hit, more discoverable, and backwards compatible.
> I don't see anyone WHO has a problem with this for UNIX and Windows.
> Can't we check that in and let Mac continue to rot and have dataloss,
> if that's the way they want it?
Accel-Shift-Q is OS-reserved (for Log Out) on OS X.
You know, in general I think Mozilla's way of development is superior to
anything I've seen, but this single one example is making me doubt that. In a
conventional project, someone would have made a decision long ago. Perhaps not
the best possible decision, but there would be one. This is awful, completely awful.

I, for one, would be satisfied with any of the proposed solutions - remove the
shortcut, remove the menu option, add a warning dialog, change the shortcut into
something less accident-prone... I really don't care, as long as this absurd and
dangerous behaviour is gone, and fast. If I really had to choose, I'd go for
changing the shortcut into something really, really very obscure, like
ctrl+alt+shift+backspace, plus implement state-preservation on crash/quit with
optional restore on next startup. But that's another bug (anyone have the number?).

PLEASE, do SOMETHING!
> PLEASE, do SOMETHING!

PLEASE, SHUT UP!

Please vote for this cug, if you care. Use Beonex Communicator or hack your
chrome, if you can't wait. But don't spam us. Thanks.
Whiteboard: No more comments, please
renominating.
Keywords: nsbeta1-nsbeta1
Sorry for more email, but who has the power to make a decision to get one of
these decided as the correct solution? Once it's been decided what we're doing,
implementing it should be a lot quicker process.
Ben Bucksch wrote:

> PLEASE, SHUT UP!
> ...<snip> But don't spam us.

That's funny, you wrote 17 comments while Vaclav Dvorak wrote merely 3 and *he* 
is the spammer...
Not to mention that for more than two years that this bug has been open, your 
main contribution was to find every possible excuse to go on with this farce.
Vaclav's comments, on the other hand were meaningful and precisely to the point.

So many times have I (and others) lost data just because of this specific UI 
catastrophe and you still think that it's "not a destructive" issue. 
unbelievable.

PLEASE, SHUT UP!
Comment on attachment 102373 [details] [diff] [review]
accel-shift for everyone but macos

Let me go talk to some folks, but this is the one I'm voting for.
Hello? Any news? Are there any serious objections to the last patch (changing
Accel+Q into Accel+Shift+Q except for Mac)?

Wouldn't this be a "must-fix-for-this-milestone" (finally) bug, as mentioned in
the roadmap document? Look at the keywords - says it all. We could still make it
in time for 1.2 if we really tried, couldn't we?

We have a patch that seems trivial enough to be safe. Could someone r&sr it,
please? Also, could someone with the privileges mark the previous patches
obsolete? Then, we could proceed with step 3 of the "get driver approval"
procedure, as outlined in the last Mozilla status update. :-)

Thank you very much.
Keywords: mozilla1.3, review
Flags: blocking1.3a?
Flags: blocking1.3a? → blocking1.3a-
Comment on attachment 102373 [details] [diff] [review]
accel-shift for everyone but macos

Let's try to get things moving on this.
Attachment #102373 - Flags: superreview?
Attachment #102373 - Flags: review?
Comment on attachment 102373 [details] [diff] [review]
accel-shift for everyone but macos

I don't think this is the right fix; it doesn't really fix the problem of
quitting unintentionally.  Often I have quit with the keybinding (or choosing
File > Quit from the menu) and lost bug comments etc because I wasn't prompted
as I believe I should be.  

Another reason to not approve this patch is because it lacks
corrections/changes to documentation/help which may reference the keybinding.
Attachment #102373 - Flags: superreview?
Attachment #102373 - Flags: review?
Attachment #102373 - Flags: review-
Doesn't the switching of control keys from something VERY close to a common
usage of Cntrl-W to a 3 button control key make it much more easier to prevent
data loss. I can't tell you the number of times I've accidentally hit Cntrl-Q
when I meant to hit Cntrl-W. This is a data loss issue and should be addressed
in a reasonable timeframe.
brade:
> I don't think this is the right fix; it doesn't really fix the problem
> of quitting unintentionally.  Often I have quit with the keybinding (or
> choosing File > Quit from the menu) and lost bug comments etc because I
> wasn't prompted as I believe I should be.

I humbly ask you to please read bug 39057 comment 71 and reconsider.

Your case of unwanted quitting would be solved by a fix for bug 48333. The
solution you propose (to be prompted) has been rejected by mpt in the discussion
in bug 39057, which has been WONTFIX'ed, has 153 comments, and is two and a half
years old. To be honest, I still don't quite agree with mpt on this, but I see
little chance of persuading him, and fixing _this_ bug is a good first step to
solving the problem.

The solution that we have a patch for here is a consensus that has been reached
after two years of discussion, with 166 comments so far. You have participated
with exactly three comments, and rejected the solution with the third one. In
the previous two comments, you stated that Ctrl+Q must be preserved on the Mac -
fine, it is. You also said:

> In my opinion, this bug should be WONTFIX and the real fixes
> should be in bug 65121 or other similar bugs.  Closing a window
> (accel-W) also causes dataloss but I don't see a patch to remove
> that keybinding so the current strategy seems very flawed and
> inconsistent.

Obviously, quitting the whole of Mozilla is potentially a much worse dataloss
that closing a single window (or tab, which is what Ctrl+W actually does -
actually, now that I look at it, closing a whole window with multiple tabs has
its shortcut: Ctrl+Shift+W - isn't that nicely consistent with Ctrl+Shift+Q for
quitting the whole Mozilla?). Also, some people would say that you don't see a
patch to remove Ctrl+W simply because it is enough to change/remove ONE of the
two, which are awfully close together on the keyboard.

> Another reason to not approve this patch is because it lacks
> corrections/changes to documentation/help which may reference
> the keybinding.

Could you be more specific, please? I couldn't find any references to the Ctrl+Q
keybinding in the help (searched 1.2b, I hope there wasn't a major help change
before 1.2) nor in the release notes.
This is obviously a critical issue to MANY users.  Many of us have suffered very
significant dataloss from hitting Ctrl-Q by accident.  Most of us never have a
need for a keybinding to quit the whole application, but the Mac UI standards
demand one.  So, many of us would desperately like a confirmation dialog before
actually quitting the application to avoid dataloss.  When we want to exit, the
extra effort to confirm the dialog is minimal.  When we don't want to exit
(which is usually the case), the default should be to cancel the Quit operation,
so we don't suffer unnecessary dataloss.  What's so unreasonable about this dialog?

I've heard complaints about how "too many dialogs" are a bad thing, any how they
condition the user to automatically confirm the dialog, and how annoying they
can be to the user who know what he wants to do.  None of these outweighs the
value of avoiding dataloss.  If these arguments against a dialog are compelling
then there should be a PREFERENCE allowing the dialog to be disabled, but the
user should have to take action to disable the dialog.  (This could be as simple
as checking a "don't show this message again" checkbox in the dialog itself,
which would hardly be a burden on those who don't want it.)

Of course, this leads to the inevitable complaints that we already have too many
preferences, and we should come up with a solution that doesn't require a new
preference to be created.  Guess what?  THIS REALLY IS A MATTER OF PREFERENCE. 
Some people are adamently opposed to a dialog, others desperately crave it.  The
history of this bug demonstrates that neither side will EVER convince the other.
 Therefore, a new preference is entirely appropriate.  Is one more preference,
to resolve such a controversial issue, really such a high price to pay?

Of course, this solution was obvious from the start, but this bug has remained
open for over 2 years now (causing much dataloss) because of the inexplicable
resistance to creating a new dialog and preference in one of the few cases where
it's well-justified.  I don't want a dialog just because a site was down, but
there it is.  I do want this dialog, because this dataloss can be severe, yet
we're told that it's not an option, evidently just for pedantic reasons!

Can we just be done with this issue, and agree that this is ONE case where a new
dialog and an associated preference are justified?  It's obvious that both sides
of the debate are entrenched and will never reach any other consensus...
Flags: blocking1.3b?
Keywords: mozilla1.2, patch, review
Summary: too easy to hit ctrl-q instead of ctrl-w → too easy to hit CTRL+Q instead of CTRL+W
Flags: blocking1.3b? → blocking1.3b-
Why does this keep getting snubbed by the powers that be for getting this
resolved? It's a common dataloss issue. Shouldn't that be enough for getting
this on the radar of resolution?
It seems that the "powers that be" (what kind of grammar is that?) are
determined to set a new record on the longest open, yet very serious,
wanted-fixed and trivial-to-fix bug. ;-)

Because I would like to believe that the above is not true, I propose an
experiment that could move us a step ahead. Would the "powers that be" consider
applying the latest patch in time for 1.3b and waiting for the users' reaction,
so that the patch could be backed out again in time for 1.3 if there is opposition?

In a doomed attempt to draw some attention, I will send an email about this to
brade (who has refused the latest patch and hasn't replied to my comment 168 in
which I ask him to reconsider), asa (who refused to mark this bug as blocking
1.3a and 1.3b), aaronl (who reviewed the previous patch and is the component
owner) and jag (who needs-work'ed it, saying in comment 113 he would prefer
Ctrl+Alt to disabling the shortcut completely) if I don't get some response
tomorrow.
Flags: blocking1.3b- → blocking1.3b?
prognathous@hotmail.com, "blocking1.3b -" means that a driver (Asa) has decided
that he would not hold the release for that bug. Why did you mark it as
"blocking1.3b ?" again?
Sorry, my mistake... :-/

BTW, isn't that a bug? shouldn't Bugzilla prevent non-drivers from changing a
"blocking#.# -"?
Even if bugzilla did have ACLs* for flags, it would be very unlikely that we'd
limit users to nominations [?].  The idea is that you could renominate (in fact,
nominations should almost always have a reason, although in some cases [and
dataloss is not such a case -- the #1 topcrash is] it's obvious and doesn't need
a written explanation) and make a case for *why* the people who manage the flag
should rethink their decission.

The fact is that this bug is waiting for three or more immovable forces to reach
an agreement (well, really there is a solution [and of course it doesn't satisfy
everyone but it does appear to satisfy all of the immovable forces], read the
recap and see if you can figure out what it is). Drivers and really anyone
shipping a product with anything approximating a timetable and no control over
the combatants are unlikely to wait forever before shipping the product.

Now for everyone except our newbie this will be a rehash of this bug's history,
but I feel like adding useless content, so here it goes:

Brade wants confirmation dialogs for dataloss cases.
Jag didn't object to accel-shift w/o any confirmation dialog (brade vetod this
for cause, see comment 166 and others).
Jag didn't want no keybinding for everyone but macos (aaronl didn't mind).
There's another force (blake, mpt, ...) in the blocking bug 39057 which doesn't
want a generic dialog (and especially don't want a dialog plus a preference for it).

note that brade essentially favors bug 48333 (which has a patch that could use
some work) and presumably bug 28385, and possibly bug 108973.

if people like long digested content, they could read bug 39057 comment 102
Appendix 1.

* I'm not opposed to an ACL to restrict people w/o editbugs to nominating or
withdrawing their own nominations (and another to restrict +'ing to the group
which actually owns a flag), but that would first require ACLs to be implemented
and for it to be easily configurable - if you think mozilla development is slow,
you should try praying for a bugzilla feature to be implemented to your liking
without providing the patch.
Assignee: lj → jaggernaut
Flags: blocking1.3b? → blocking1.3b-
Now if we could get Bugzilla to require reasons for marking a bug as not
required for a release, then the powers that be might be forced to tell us why
they don't consider this common dataloss important.
Nav triage team: nsbeta1-
Keywords: nsbeta1nsbeta1-
I don't get this, issues like "Documentation needs a roadmap" and "Printing 
MathML is broken" warrant the Blocker tag and a major dataloss bug does not?

http://snurl.com/mozilla_blockers includes a list of the all 132 open Blocker 
bugs, many of which are far less critical than this one.

Prog.
Ridiculous, isn't it?  The "powers that be" obviously just want this issue to go
away, but somehow it doesn't.  There's a reason for that -- it's IMPORTANT!
*** Bug 189815 has been marked as a duplicate of this bug. ***
Just done it again. Can those who are holding out against a confirmation
dialog on CTRL-Q please confirm that they actually use keyboard shortcuts
whilst driving their browser? Like other keyboard navigation bugs I've
tried to argue for, I get the impression that the ones saying 'no' are
mouse-jockeys.
I've just lost 2 weeks work thanks to that. Please, please, please can we kill
Ctrl-Q. It's evil and vicious. In my view, this is the most serious bug that Moz
posesses and I've been using it for a year and a half now.
To all of the people who have commented here lately about how rediculous this is:

You're right. But the Mozilla drivers obviously don't care. Whining does no
good. Patch your local copy, or use Phoenix. The Phoenix people tend to be
somewhat intelligent about these sorts of UI problems.

It's been two and a half years. Mozilla drivers obviously have no interest in
fixing this problem (and lots of other serious user issues). So deal with it.
One of the Netscapes folks wrote to me: "Finally, I'd like to say that while we
may not prioritize this defect in our list for the next Netscape release, we
strongly welcome code contributions to fix this defect."

THERE is code to fix this one. It's annoying to see it ignored, especially
considering the code is mearly for changing the short cuts for a command.
>But the Mozilla drivers obviously don't care.

mozilla drivers are not the people who decide what code gets in (except
freezes), module owners do.

As for "code IS there", that is not really correct. The last two patches here
have a review-/needs-work+, which means that they need work.  Improve them per
the comments that probably are in a comment above, and ask for review again.
As far as I can tell, the 'work' that needs to be done is to make a patch that
works out when brade@netscape.com is using mozilla, and prompts him with a
dialogue box, despite the fact that in the bug to do this (bug 39057), other
powers-that-be have vetod it. 

It would seem that in his opinion a stopgap solution is worse than no solution
at all, as it would removes the incentive to produce his 'real' solution. So
these review- and needs-work+ flags really mean 'we're not prepared to accept a
patch that solves the problem in this way'.

This is turning into a war between 'worse is better', and 'the right thing'. The
powers-that-be are hopelessly deadlocked, and unless they can agree on how to
proceed, the chances of seeing this patch checked in anytime this decade are
hoplessly slim.
I'd like to know how other people feel about the accel-q issue, so I've enlisted
the help of a freebie web poll thingy. It would be a great help if anyone
interested would go to <a
href="http://www.ihate.freeserve.co.uk/mozillavote.html">http://www.ihate.freeserve.co.uk/mozillavote.html</a>
, and cast their vote. If nothing else, if it shows I'm way in the minority, I
might shut up :)
The more comments here are, the less likely are developers going to invest their
time to read this bug, and the less likely is any action here. Also, you piss
people off who are cced (waiting for any significant action). Same goes for all
bugs above a certain size, btw.
Flags: blocking1.3?
To anyone who will be deciding on the blocking1.3 request: please note that
there is now an increased likelihood that this will be decided/fixed. Quoting
Aaron Leventhal's post in n.p.m.accessibility on 02/04/2003: "I'll revisit this
whole area with the UI team soon. I agree it's too easy to hit Ctrl+Q and quit
the app. Persoanlly, I think a yes/no confimation would be useful." While this
doesn't indicate that anything will be actually done about the keyboard shortcut
itself, we can at least expect that this bug's fate will be decided by the
relevant authority. The blocking1.3 flag may be just the right thing to
encourage "the UI team" to act "soon". ;-) Thank you.
Flags: blocking1.3? → blocking1.3-
No longer depends on: 39057
I've done some more review of this trying to get this resolved. The comment
rejecting the last patch by blade said:

I don't think this is the right fix; it doesn't really fix the problem of
quitting unintentionally.  Often I have quit with the keybinding (or choosing
File > Quit from the menu) and lost bug comments etc because I wasn't prompted
as I believe I should be.  

Another reason to not approve this patch is because it lacks
corrections/changes to documentation/help which may reference the keybinding.

--
Blade's first comment is no longer valid since Bug 39057 has been marked as
WONTFIX. Blade's second commend can easily be rectified. So can we address the
documentation issue with the appropriate patches and then move forward to check
this in? All the screaming and frustation hasn't done much. The way to resolve
this is to address the specific issues that are brought up against patches as
I'm trying to do so here so we can address them and get a patch checked in.
Brade could make this task a lot easier if he were to expand on his statement in
comment 166 and tell us exactly which documentation needs to be changed. As has
already been pointed out in comment 168, CTRL-Q is not documented anywhere in
current shipping mozillas, either in the help or release notes.

I suppose that on the mac it would be expected to be present, but on any other
platform, it's left as a nice surprise. 

Possibly we should add to the release notes 'In violation of expected windows UI
standards, CTRL-Q used to quit your whole entire mozilla. Now it doesn't. Just
so you know.'
Blade is not an account here. We have a blake and a brade.
Brade is not a man...

The windows user interface guidelines say that keystrokes are supposed to be
listed in the menuitem. we do that. quit has a defined meaning, we honor it.
please don't complain about those details.

note that opera has ctrl-q bound to quit and the bork edition didn't prompt me
when i used it.

there's nothing wrong with our documentation and there's no need to release note
this.

as for the rest of your dribble, nowhere in brade's comments did she demand bug
39057. go reread my comments. there's a path that you can walk, it does require
you to think but it is there.

to the claim that the binding isn't documented anywhere, i'm glad to know that
you don't read the supporting links, it's clearly listed in
http://www.mozilla.org/docs/end-user/moz_shortcuts.html
again, that doesn't matter. the windows guidelines only require that the item be
listed next to its menuitem.
That's exactly what I was looking for. Thanks.

Now, how do you propose that a patch should address a web page hosted on
mozilla.org? Is it generated from the source somehow?

The patch as it stands already changes the annotation next to the menu item.
What more is needed?

And would you prefer it if I use a different gender-neutral-pronoun than 'he'
(Which was what was taught when I went to school) to refer to email addresses? 

Maybe we could have a vote?
Actually, I don't remember ever being taught at school about what pronoun I
should use for email addresses of unknown gender. ;-) Anyway, here, you're
expected to just magically "know" who's hiding behind the email... Which is
especially wonderful with people who don't even have their real name set in
Bugzilla preferences, like for example one brade@netscape.com or
timeless@myrealbox.com, who could, for all we know, be a woman, too.

timeless: Though I sometimes enjoy riddles, I don't think this is the right
place for them. Could you, please, be specific as to what viable solution you
see? ("well, really there is a solution, read the recap and see if you can
figure out what it is" - your comment 174)

The path that I've started taking in the hope that someone actually
authoritative in this area will make a decision, is bringing this up on
netscape.public.mozilla.accessibility. Aaron, who is in charge of accessibility
and keyboard shortcuts, has stated there: "I'll revisit this whole area with the
UI team soon. I agree it's too easy to hit Ctrl+Q and quit the app. Persoanlly,
I think a yes/no confimation would be useful." So I recommend not doing anything
hasty now, until we hear more from him. If you want, have your voice hear on
that newsgroup instead. Don't worry, it's very low-volume.
I usually jump in on these when my wife (way not power-user) starts cursing
Mozilla, so here I am. :)

Here's what Apple has to say about this issue:

http://developer.apple.com/techpubs/macosx/Essentials/AquaHIGuidelines/AHIGDialogs/chapter_6_section_8.html#//apple_ref/doc/uid/20000962/TPXREF29

You have two types of apps, "Document-based" and "Not Document-Based". 
Navigator is the latter, though Composer is certainly the former.  Focusing on
Navigator, when you're not document-based, it's assumed you'll be saving state.

Somebody above made a good point - why not confirm cmd-w if you're going to
confirm cmd-q?  It's certainly potential data-loss with no easy way to get back.
 Safari deals with this nicely with its elegant History menu, but Mozilla's
isn't quite so accessible. To rationalize away this problem, one can make the
call that two or more tabs or windows are the criteria, because in the
one-window/one-tab case cmd-Q and cmd-W are equivalent, data-loss wise.

So, for Mac, probably the right thing to do is mark this bug a dup of or depends
on bug 36810.
While composer is a 'document-centric application', the only thing I get from
the HIG is that navigator is not a 'document-centric application'. It may not be
a non-document-centric application, as the guidelines seems to define
'application' as 'something that takes input from the user to make something
that can be saved somewhere'. As far as I can tell, a non-document-centric
application would be something like visual studio ('You have made changes to
your project - would you like to save it?'), or an FTP client ('You have made
changes to the remote files - would you like to save them?'). 

Navigator does not 'create' anything, so I'm not so sure it falls under the
apple definition of application (
http://developer.apple.com/techpubs/macosx/Essentials/AquaHIGuidelines/AppBTerms/chapter_18_section_1.html
, the OS X glossary, was not much help. ) I guess it should behave the same way
as other 'viewer' programs, which just quit when accel-Q is pressed, without
warning the user that they might be closed. Try opening a few things in
SimpleText, and then pressing accel-Q - it will quit no matter how many
documents are open, as long as none of them have been changed. This may not
apply to os X - I haven't used it much. For OS 9, at least, it would seem that
apple don't consider loss of 'state' to be dataloss.

If navigator is a 'non-document-centric' app, it could be argued that the only
thing that needs to be done is to resolve bug 48333 , implementing the kind of
'save' dialogues the HIG is asking for. The HIG makes no mention of prompts like
'you opened this document - are you sure you want to close it?'.

Really, I'd like to see a separate bug for accel-q and the mac, as its interface
is different from expected norms on other platforms in so many ways (one
'application' can have several windows, accel-q is a shortcut normally
associated with closing the whole entire application (An operation rarely
encountered at all on unix/windows), strict HI Guidelines, etc. etc.) that it
would make more sense to treat mac as a special case rather than try to find a
solution which would reconcile two very different views of how a 'program'
should behave.

In my opinion, this bug does not block bug 73812, but bug 48333 should.
Flags: blocking1.4a?
Flags: blocking1.4a? → blocking1.4a-
I'm asking again, why is a major dataloss situation not important enough to be
greatly decreased it's severity through a patch that's already in existance. The
patch got a review and did not get a super-review partially due to the reviewer
wanting a bug to be fixed that is now marked WONTFIX. Can we request a 2nd
opinion on the super-review?
*** Bug 200929 has been marked as a duplicate of this bug. ***
Flags: blocking1.4b?
My opinion: This is the answer:
"patch to make control+q show a warning"
BUT also, 1) Don't include the warning on File|Exit, 
and 2)it is necessary to make the CANCEL button the default, so that a random
mouse click does not close all instances of Mozilla after pressing control-Q.

NOTE: A command to kill all instances of Mozilla browser, email, composer, and
calendar together is of limited usefulness. Such a command is an "I hate
Mozilla" command", and everyone loves Mozilla. Anyone wanting to close multiple
instances of Mozilla can hit control-W several times, or click on the X in the
upper right hand corner.
Somebody please, please, step up to the plate. 
Keywords: mozilla1.3helpwanted
Could someone with the authority to do so please make an official ruling on this?

There is no point in writing yet another patch before it's known whether it
would be an acceptable solution or not.

timeless@myrealbox.com
>there's a path that you can walk, it does require you to think but it is there.

I give up. I can't think what it is bar a patch that works out what your email
address is and does different things depending on which netscape developer you are.

If there really is something that would be acceptable to all parties in
authority (and it's not just a cruel joke :), please could you elighten us as to
what it is?

If you're not willing to tell us, I suggest that we all submit our favorite
solution, on the off-chance it's the right one.
Mozilla goes away after 1.4 and Phoenix has solved this problem ages ago (the
solution being removal of ^Q, which generated 0 complaints, TMK).

Mine as well WONTFIX this.
Can't this be fixed for the final "Mozilla suite" despite its eventual
deprecation? Maybe remove it for 1.4 beta and if no one has complaints, leave it
removed?
I vote also for the solution on comment 202 (and 201). That's a good idea.
Flags: blocking1.4b? → blocking1.4b-
Flags: blocking1.4?
*** Bug 203476 has been marked as a duplicate of this bug. ***
adt: nsbeta1-
Keywords: nsbeta1nsbeta1-
I just fat-fingered Ctrl+q when I meant to just close the current tab (Ctrl+w).

This is really [censored] annoying.  I lost all 20+ tabs I had loaded and there
was no "Are you sure you want to exit Mozilla? (Y/N)" confirmation dialog.

If nothing else, please create this dialog and make it the default.  I'm ****.
 Extremely destructive actions such as this should be confirmed.  Perhaps a
threshold (if > 5 tabs, ask for confirmation?) or something.  But don't let me
destroy everything I've worked for over the past day.

Separately, the tabs should be saved when you hit Ctrl+q.  Doesn't have to be a
(permanent) bookmark, it could be a single "Previous Ctrl+q operation" bookmark
so that if you <b>did</b> hit Ctrl+q by accident, you could easily re-open a
Mozilla window and restore all your tabs.
And GODDAMMIT at the time I was downloading the Unreal 2 demo, which had gotten
97355KB of 157160KB -- and the download manager was killed as well.  Now I have
to wait in line at FilePlanet for at least another hour before the download can
start, and I have to click after that hour so I can't just "start" it and go
watch TV.  This bug SUCKS ASS!!!!!!!!!!!!!!!!!!!!
This bug has been marked "severity=critical" for as long as I can remember. Well
over a year. Yet, each time, it gets put off. No one knows why such a simple bug
(which causes dataloss, and which already has an existing patch) never gets fixed. 

Here's my suggestion. I have started a project called "KillCtrlQ" with the idea
of producing a plugin. This plugin would have one purpose: to bind to Ctrl-Q
with a higher priority than Mozilla's default "exit without checking". It would
then pop up a dialog box to say "Don't panic - not really quitting".
[I know that this is an ugly workaround, but otherwise, this bug will probably
be incrementally ignored indefinitely...]

My programming ability isn't what it might be - does anyone want to help? 
Richard, i think you jinxed me, i just bumped the dreaded ctrl-q about 500 megs
into an 880 meg download, boy am i happy!  i would be very happy if someone
would comeup with a .xpi that overrides this menu item... very happy indeed.
Please don't pollute this bug with comments about quitting when downloading.
That's bug 28385, and is much less contentious than this bug.
Quoted from 
http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html#destructive

--------------------------
Potentially Destructive Keys

      Certain keystroke combinations are reportedly often hit by mistake by
users intending to type something else. Those keys should only invoke undoable
or non-destructive actions

      Here's our current list of easy-to-mistype keystrokes:
          o Modified Enter
          o Modified Space

      Keys that are easily hit by accident should not invoke an immediate,
undoable, destructive action. For example, if Ctrl+Enter was used for immediate
mail send, someone might send a rude email before having the chance to edit it.
To get around this, we will have Ctrl+Enter bring up a dialog "Send mail now?"
with a checkbox that lets the user avoid the extra question in the future.
--------------------------

I think this show us what we should do about this bug.
Hi all,

I got an email response which was very helpful (it solved the problem on my
machine), so in case others would like to solve the problem *now* instead of
waiting for the fix, the instructions are below.

Cheers,
Ken


You can patch your version so ctrl-q does nothing by doing the following:

Unzip %mozilladir%\chrome\en-win.jar , preserving directories

edit locale\en-US\communicator-platform\platformCommunicatorOverlay.dtd

Change the line

<!ENTITY quitApplicationCmd.key		"Q">

to

<!ENTITY quitApplicationCmd.key		"">

Zip the whole lot up again, and copy it over the original. (zipmagic is 
very helpful in doing this)

Hope this is of some help.
Also, if you install TBE (tabbrowser extensions
(http://white.sakura.ne.jp/~piro/xul/_tabextensions.en.html))
you will have an option to get a confirmation dialog for ctrl-Q with multiple
tabs open.
Flags: blocking1.4? → blocking1.4-
I've got tabbrowser extension and have that option enabled, but it only works
for closing a window on the close button or through A4 (Alt-F4), not C-Q (ctrl-Q).
*** Bug 206354 has been marked as a duplicate of this bug. ***
*** Bug 208215 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
Re comment 79/84/212: how can I change the chrome if the application is
installed in a directory in which I have no write permissions? Is there a way to
have something in my profile to override it?
Re for comment #217:
It is possible to map XBL (which would be probable the right way for you in this
case) through userChrome.css or userContent.css, but unfortunately there are at
least two drawbacks I know about:

a) Adding any XBL (with almost none functioning) to builds last week caused
scrollbars not to be visible. Tell me why ^^

b) XBL file can't be located in profile directory (security?), only in "res"
subdirectory in Mozilla install directory so in fact modification of Mozilla
through user XBL is practically unusable. Pity.
I downloaded the latest nightly from the trunk and noticed a new confirmation
dialogue is now there for Control-Q when a browser has multiple tabs open. It
appears as a result of Bug 108973. 

Should this bug be resolved or dropped in severity as a result? Bug 108973 only
seems to catch situations where one of the browser window has more than one tab.
Should this be expanded to also be where the current window is not the only
window? So say I currently have Mail selected and I have a browser window open
(regardless if it has multiple tabs), I should get a confirmation on Control-Q.
Such that only situations where there is only one work area (mail is one or a
browser window would be also one) would not result in a dialogue? Thoughts?

Personally, the resolution of Bug 108973 reduces the severity for me of this bug.
As long as the confirmation dialog is not shown when there are multiple
single-tab windows open, I don't think the solution is fully acceptable. Not
everyone uses a single browser window with lots of tabs.
As seen in bug 39057:

 Status: Bug 52821 (cross-posting this because it is relevant to both bugs). If
a user was comfortable with using Ctrl+Q (each time I reference Ctrl+Q assume I
also mean Ctrl+W along with it) he would not want a confirmation dialog every
time he used it (although I suspect the number of people who actually use Ctrl+Q
are significantly fewer than than the number of people who lose data to Ctrl+Q).
Looking at this from a comment 71 POV I'll assume that we need to prevent
dataloss for a person who is comfortable with Ctrl+Q but is about to lose data
because he hit the key accidentally (the worst-case scenario). Lesser instances
of people who would never use Ctrl+Q would be solved by an optional
confirmation. Having the option to remap Ctrl+Q without any confirmation would
still allow at least one dataloss to occur before the user realizes Ctrl+Q is
dangerous. Possible solutions to the worst-case scenario, however, are more
complex. Here is one solution I propose to this dilemma:

 If 1. user has manually entered data into a form (disregard anything that was a
default value)
    2. that data was less than an accidental stray letter, search string,
login/pass, or other forgettable data
    3. the data is not the site's responsibility (e.g. if I type an e-mail and
hit preview, and the preview is stored server-side, it could be argued it's
e-mail provider's fault for not keeping the message stored in the event of a
Ctrl+Q, crash, or other such catastrophe),

 Then 1. We could save the data in an undo file, so the user can come back soon
and decide he shouldn't have closed the browser. (Privacy/storage issues, see
below.)
      2. We could show a mandatory confirmation in that instance; if later on
someone in their regular use receives the confirmation erroneously and finds it
frustrating they can file a bug so the system can be fine-tuned.
      3. As a remarkably odd third option, we could pioneer a system for
server-side prevention of dataloss; for example if a user quits the developer
could re-route the lost data to the server and it could be automatically
submitted to the server. We could also implement onBeforeUnload (bug 68215).
This approach would create a lot of tedium for both Mozilla and web developers
as well as the evangelism team, and I don't see it working as a solution to this
problem. It would not prevent dataloss on any site that has not implemented such
a safety mechanism.

 A few reasonable assumptions can be made:
 1. If someone accidentally quits and didn't want to, he'll try to get his data
back right away. So if someone quit and their data was stored in an undo file or
something like that, there is no need to retain it for very long. One day or one
closing/reopening/closing again of the browser is more than long enough.
 2. Only the data entered and a mental cue to its origin (URL or title) is
important to a person who has experenced dataloss; no need to store HTML or
anything like that in an undo file.
 3. The disk cache is big so few will care about or even notice an undo file
that is the same amount of data that was entered. However if you have something
very private typed up in an e-mail, again worst-case scenario, you would not
want to accidentally lose your very private e-mail but you would be
uncomfortable with having it stored in the undo file. Users who care about
privacy, though, will educate themselves enough to find out about an option to
flush the undo file, much the same as they will know that they need to empty
their disk cache, history, etc. Therefore both storage and privacy issues are
fixable with an undo file.
This bug is three years old. The patch is 2 years old. Give up. Save your
breath. Go download Firebird, where this has been fixed since the beginning.
Drivers don't care about this bug. jag doesn't care about this bug. Consider it
pseudo-WONTFIXed.
Attached patch extension to #86671 with pref (obsolete) — Splinter Review
To summarize it, this bug is WONTFIX but with the existing patches you can
easily "fix" it yourself.
Personally I like my Ctrl+Q and don't want to have even more keys to hit.
#147 is not a bad idea but could require more work. Currently Window-Close and
Tab-Close are seperate things.
If for some reason Quit confirmation should make it into Mozilla, those who
hate it for whatever reason will only see it once and can then disable it, like
it's done with form submit data and now also for Multiple Tabs.

---------8<--- If you know how to patch or don't care, skip this --->8---------

As long as you have access to your chrome, let me repeat #84
For Windows users, chrome is in C:/Program Files/mozilla.org/Mozilla/chrome
If you'd want to apply my patch, you don't need to compile Mozilla at all!
Use your favourite archiver (WinRAR isn't bad, use google!) and unjar/unzip
toolkit.jar and en-US.jar, preserving directory structure.
Now go to toolkit/content/global and edit globalOverlay.js with your favourite
text editor. Follow the instructions in the patch attachment: lines with + in
front need to be added (without the "+"), lines without anything are already in
the file, you can use them for orientation.
The other file that needs to be edited is
en-US/locale/en-US/global/appstrings.properties
Finally, repack the files (Filetype: ZIP, Compression: Store) and rename to
en-US.jar or toolkit.jar. Make sure that, if you open them, you don't see en-US
or toolkit as first folder inside the archive, but locale (en-US.jar) or
content (toolkit.jar)
I can provide my altered .jar files for Mozilla/5.0 (Windows; U; Windows NT
5.1; en-US; rv:1.5a) Gecko/20030718
---------8<--------------------------------------------------------->8---------


The current patch "conflicts" slightly with the multi-tab window-close
confirmation 1.5 is using. I don't mind the behaviour, change it if you do. If
you have the tab confirmation enabled and do Ctrl+Q with mutliple open windows,
you will first receive the tab confirmation. If you confirm it, the Quit
confirmation will pop up.
Now, if you cancel the Quit confirmation, nothing will be closed, not even the
window where you confirmed the close.
This patch uses the pref general.application.warnOnQuit to store information
about a disabled Quit warning.
This patch adds the locale strings application.quitWarningTitle,
application.quitWarning, application.quitButton and
application.quitWarningPromptMe to global/appstrings.properties
brade@comcast.net wrote in comment #166:

> I don't think this is the right fix; it doesn't really fix the problem of
> quitting unintentionally.  Often I have quit with the keybinding (or choosing
> File > Quit from the menu) and lost bug comments etc because I wasn't prompted
> as I believe I should be.  

Then why is this bug marked as New? shouldn't you close it as INVALID or as WONTFIX?

> Another reason to not approve this patch is because it lacks
> corrections/changes to documentation/help which may reference the keybinding.

If this is only a matter of documentation/help, then please specify what exatly
is missing.

Thanks,

Prog.
> Then why is this bug marked as New? shouldn't you close it as INVALID or as
WONTFIX?

What ??? Isn't this bug fixed. These days when I press CTRL-Q and there are more
than 1 tabs, mozilla asks me before closing all tabs !

I guess thats a good enuff fix :)
bug 108973
got nothing to do with this. Consider not using one-window-multiple-tabs
browsing but multiple-windows browsing. Also having browser (one website), mail
and calendar, Ctrl+Q quits everything although you meant Ctrl+W to close the
browser window only.

Also please let us try to reduce spam and keep unneccessary comments to a minimum =)
I do this all the time too, not more than 15 min. ago.  But it affects every
keyboard.  I am sure there is software out there to remap your keyboard.  This
is not a Moz problem.

I am very proud of myself for not trolling or flaming this post.
I'm not sure I follow comment 227's statement that 'this is not a moz problem'.
On every platform apart from mac (and looking at their desktop market share,
that means 97.2% of mozilla's market
(http://www.macobserver.com/article/2004/01/15.15.shtml) ), the shortcut Accel-Q
is unheard of. The only mainstream windows/linux application to use accel-Q is
mozilla, which inheirits the behaviour from Netscape's attempt to have a
'cross-platform-friendly' user interface. On every platform but the mac, even
having an Accel-Q shortcut to quit the whole entire application is a major
problem, as only MacOS has the concept of an application which owns windows. On
windows and most unices, one window is one application; If closing one window
somehow closes many other applications, this is unexpected. If pressing the
wrong button somehow closes every single web browser, calendar, mail client,
HTML editor and address book application, this is frankly astonishing
(http://www-106.ibm.com/developerworks/usability/library/us-cranky10.html).

You could, of course, remap your keyboard to a dvorak layout, which would solve
the problem, but is probably a bit more drastic a step than blaming mozilla and
patching it with attachment 102373 [details] [diff] [review] . In this new enlightened age of fewer, more
decisive module owners, is there any chance someone could look at this issue and
put their foot down, one way or the other?

Apologies if I've misread your comment.
Lewis Jardine (comment 228) -- the problem with that particular attachment is it
is missing changes to the mozilla documentation.  Those should be trivial for
someone to create and add to the patch you suggest.  I will review / approve
such a patch but I don't know if jag or others (module owners) would signoff on it.

Lastly, it is deceptive to think that the patch in this bug solves all of the
"dataloss" bugs discussed in this bug.  I have lost data many time because I
actually clicked the close box on a window or similar.  Arguing the urgency of
this bug being fixed due to dataloss doesn't really hold for me (and others?). 
I think people should instead be arguing to fix bug 48333 (forms) and bug 28385
(downloading).
I'd be happy to add documentation changes to attachment 102373 [details] [diff] [review] , but could
someone please give me a pointer as to what documentation needs to be changed? I
haven't been able to find any reference to accel-Q anywhere in 'help --> help
contents' or 'help --> release notes'. To my knowledge, changing
platformCommunicatorOverlay.xul automatically changes the shortcut listed in the
file menu. What are the other changes that need to be made?

Personally, (rather than dataloss) I'd argue for this bug on the basis of
predictability, HIG, and risk/reward - it's a trivial change that makes
mozilla's behaviour significantly more predictable for users on the most
commonly used platforms, while not removing any functionality, and not affecting
the platform on which the behaviour is expected. 

That's not to say that bug 48333 and bug 28385 shouldn't be fixed as well, but
in my opinion, if not fixing this bug provided an incentive to fix those two
bugs, surely they'd have been fixed in the past three years?
Comment on attachment 142453 [details] [diff] [review]
accel-shift for everyone but macos; Amend documentation

this request is not an endorsement
Attachment #142453 - Flags: review?(neil.parkwaycc.co.uk)
Comment on attachment 142453 [details] [diff] [review]
accel-shift for everyone but macos; Amend documentation

Before we go with this patch, it would be wise to hear what other BeOS users
think about it. In my personal opinion, it is a good decision to remove a
dataloss-inducing shortcut from Mozilla, including the BeOS build, even if it
is inline with unwritten BeOS UI conventions (no official HIG was ever
published) - BeOS does include Cmd+Q for Quit. Unlike the Mac, where keyboard
mnemonics are not supported, in BeOS we have a good alternative. 

Prog.
Attachment #142453 - Flags: review?(neil.parkwaycc.co.uk) → review+
Certainly on BeOS I would like to see Alt-W and Alt-Q do window open and app quit, as that is what 95% of BeOS applications do.
I haven't reviewed the patch(es), but would it be possible to save state so
that, even if a user confirmed that s/he wanted to exit and close all those
tabs, the next time they started Mozilla they'd have a menu item, "Open Previous
Tabs" so that they could get back to where they were with no dataloss?

In addition, after hitting Ctrl+W there should be a way to "undo" to get that
page back.  I know I've hit Ctrl+W one too many times, countless times, and
would really appreciate such a feature.

An "undo stack" would be even better, so after closing multiple tabs you could
open them all back up again, one at a time.

And (getting ambitious here) having a "closed cache" (separate from the current
page cache -- or perhaps not?  I don't know the internals...), which would allow
a user to instantly get back to the page s/he closed by accident by hitting
perhaps Ctrl+Shift+W, bringing back exactly what was on the screen, i.e. no need
to go out to the Internet and reload anything, just display what was there, with
the scroll bar scrolled down to where the user was (and, while I'm at it, with
the highlight, if any, restored, and any text boxes filled in with whatever was
in them when the page was closed).

I notice that newer builds now ask you to confirm when you hit Ctrl+Q.  Could a
similar confirmation be created (and defaulted to "on") for Ctrl+W?

Finally (and this is probably for a separate bug) it's very annoying when you
hit Back and the text fields revert to empty when you're filling out a form and
you mistype or forget something.  "Back" should ALWAYS be a local operation and
should never contact the server, even if the server is configured to have it
contact it.  This should be a configurable option which should default to
"always act locally."  The first time this is encountered it should ask the user
what to do.  (Let me know if there's already a bug on this or if I should enter
a new one.)
I think you're looking for bug 63904.  
Comment on attachment 142453 [details] [diff] [review]
accel-shift for everyone but macos; Amend documentation

Why not ask for sr?
Attachment #142453 - Flags: superreview?(jag)
I'm in agreement with indolering that this so-called "bug" (meaning the
placement of two command keys side by side) is not a Mozilla problem.  On my
keyboard W and Q are nowhere near each other, so it's impossible to accidentally
hit one when you meant to press the other.  Mozilla shouldn't make assumptions
about the keyboard layouts of its users.

I also disagree with Lewis Jardine that Ctrl+Q is unheard of outside the Mac
world as a shortcut for "Quit".  It seems to be standard on KDE.  Personally I
wouldn't cry, however, if this key combination were removed entirely; a lot of
applications don't bind any shortcut key at all to the Quit function precisely
because they don't want users accidentally pressing it.

Anyway, I think this problem has already been largely solved in 1.6 with the
confirmation dialog when closing windows with multiple tabs.
In windows programs, rarely does a command in one window close more than itself.
I believe the current menu item of Quit is completely inconsistent in Windows,
having a look through my computer, I can not see one program that has this
behaviour.
*** Bug 254256 has been marked as a duplicate of this bug. ***
*** Bug 278100 has been marked as a duplicate of this bug. ***
Disabling or adding a confirmation window is particularly important to me,
because I use ClipMate. The shortcut for invoking ClipMate's QuickPaste feature
is <Ctrl-Shift-Q>. I didn't even know <Ctrl-Q> existed until I accidentally
didn't have <Shift> fully depressed before I hit the <Q> when I wanted to paste
something into Mozilla.

BTW, while there is now a confirmation dialog if multiple *tabs* exist, there is
none if multiple *windows* exist.
No longer blocks: majorbugs
*** Bug 312626 has been marked as a duplicate of this bug. ***
Death to control-q.

#1 it is nonstandard. I know of no other Windows all that even has a single-key quit accelerator, let alone this one.

#2 it is not shown as an accelerator on the Thunderbird file menu, so it arrives without warning.

#3 In Outlook, from which many of us come to Thunderbird, it is 'mark message read'. 

benson@dchbk.us wrote:
> #1 it is nonstandard. I know of no other Windows all that even has a
> single-key quit accelerator, let alone this one.

Don't be ridiculous.  Whether or not Ctrl+Q is "standard" depends on what standards you are using.  In many windowing systems, such as KDE, Ctrl+Q is indeed the default "Quit" shortcut.

And to address the second part of your comment, I don't know what keyboard layout you're using, but on mine Ctrl+Q takes two keypresses, not one.  Two-keypress shortcuts for "Quit" are fairly common across various windowing systems.  (Since you appear to be using Outlook, I might suggest you try pressing Alt+F4 and see what happens.)
Who's being ridiculous.  

"Whether or not Ctrl+Q is "standard" depends on what
standards you are using.  In many windowing systems, such as KDE, Ctrl+Q is
indeed the default "Quit" shortcut."

If mozilla is going to have one set of shortcut keys across all platforms, it would be ridiculous to choose the standards of a minority platform such as KDE over Windows standards.  However, I'm all for splitting it up and letting the Mac and KDE users keep their own platform's standards.  Shouldn't that really be what this bug's about?


(In reply to comment #247)
> benson@dchbk.us wrote:
> > #1 it is nonstandard. I know of no other Windows all that even has a
> > single-key quit accelerator, let alone this one.
> 
> Don't be ridiculous.  Whether or not Ctrl+Q is "standard" depends on what
> standards you are using.  In many windowing systems, such as KDE, Ctrl+Q is
> indeed the default "Quit" shortcut.
> 
> And to address the second part of your comment, I don't know what keyboard
> layout you're using, but on mine Ctrl+Q takes two keypresses, not one. 
> Two-keypress shortcuts for "Quit" are fairly common across various windowing
> systems.  (Since you appear to be using Outlook, I might suggest you try
> pressing Alt+F4 and see what happens.)
> 
(In reply to comment #247)
> benson@dchbk.us wrote:
> Don't be ridiculous.  Whether or not Ctrl+Q is "standard" depends on what
> standards you are using.  In many windowing systems, such as KDE, Ctrl+Q is
> indeed the default "Quit" shortcut.
> 
> And to address the second part of your comment, I don't know what keyboard
> layout you're using, but on mine Ctrl+Q takes two keypresses, not one. 
> Two-keypress shortcuts for "Quit" are fairly common across various windowing
> systems.  (Since you appear to be using Outlook, I might suggest you try
> pressing Alt+F4 and see what happens.)

I think the whole point here is that Ctrl-Q is something you can accidentally hit while trying to type Ctrl-W, Ctrl-A, or Ctrl-S.  I'm not aware of any function that utilizes Alt-F3 or Alt-F5.  This makes the comparison to Alt-F4 irrelevant.  IMHO it should be either be changed to Alt-F4 like pretty much every single Windows product on the market or mitigate the potential damage done when a users fat-finger Ctrl-Q by prompting them before killing the app.

This has been a bug for 6 years now.  Every single Mozilla user I've ever known has listed this as their #1 gripe against Mozilla.  What the hell is taking so long to fix this damned bug?  I know there are a lot more higher-priority bugs but one would think that in 6 years time someone somewhere would have attempted to address this issue.  At the very least the Mozilla Foundation needs to prioritize the bug list and put some effort into fixing bugs that have been known for over half a decade.  Come on people, we're supposed to be better at fixing bugs than our closed-source counterparts Microsoft!
FYI, SessionSaver functionality plus undo close [window,tab] is being worked on for Firefox 2.  That's probably a better solution for most users who are here for the dataloss aspect.  When that's available perhaps this bug will become 'remove ctrl-q from windows keybindings'.  It probably doesn't make sense to violate HIG for the short-term on other platforms when the proper fix is in progress.
Listen gyus, have you ever heard about a country called France? Have you heard about the AZERTY keyboard layout? What do you think happens to a person who alernates QWERTY and AZERTY layouts, with Q and A interchanged? Can you guess? Do all of us really have to wait until you come up with a wonderful new product and keep losing information, when it has become quite clear from this little conversation that you do not suggest how to remove ctrl-Q feature not because it would be difficult for you, but out of God knows what principle? Do we have to abandon Firefox and go Microsoft?
I think this is most thoughtless and stupid attitude on your side.
Boris Velikson, France.

(In reply to comment #250)
> FYI, SessionSaver functionality plus undo close [window,tab] is being worked on
> for Firefox 2.  That's probably a better solution for most users who are here
> for the dataloss aspect.  When that's available perhaps this bug will become
> 'remove ctrl-q from windows keybindings'.  It probably doesn't make sense to
> violate HIG for the short-term on other platforms when the proper fix is in
> progress.
> 
(In reply to comment #251)
> it would be difficult for you, but out of God knows what principle? Do we have
> to abandon Firefox and go Microsoft?

Um, last I checked, Ctrl+Q doesn't do anything in Firefox 1.5.0.1 on Windows. Let me check again ... uh, nope, not a thing!
You are quite right! I downloaded it, and yes, it's OK now. My apologies. But then why not just say so - why all these messages pretending it's just all right to keep that feature that, luckily, has been finally removed? 
Anyway, my personal thanks to you

(In reply to comment #252)
> (In reply to comment #251)
> > it would be difficult for you, but out of God knows what principle? Do we have
> > to abandon Firefox and go Microsoft?
> 
> Um, last I checked, Ctrl+Q doesn't do anything in Firefox 1.5.0.1 on Windows.
> Let me check again ... uh, nope, not a thing!
> 
(In reply to comment #253)
> You are quite right! I downloaded it, and yes, it's OK now. My apologies. But
> then why not just say so - why all these messages pretending it's just all
> right to keep that feature that, luckily, has been finally removed? 
> Anyway, my personal thanks to you
> 

It exists in Thunderbird 1.0.7, and maybe also in Thunderbird 1.5 (I didn't check it). It also exists in Mozilla Suite, and maybe also in Seamonkey 1.0.
Also, Acrobat Reader 7.0.7 on Windows follows the CTRL-W/CTRL-Q idiom.  That's not to say I like it (I don't and I always hack my Mozllia to lose the CTRL-Q keybinding), but it does exist in other very commonly-used programs.
comment #255 : You're supposed to steal the best ideas, not the worst.

Acrobat reader is, like most of Adobe's products, a **** port of a Mac application. It's not to be met with much surprise that it has some keyboard shortcuts that are expected on a Mac, but bizarre on Windows. Its market share is no reason to copy it.
in BeOS "W" has very high precedence on system level to provoke whole window closing. Very inconvinient for tab closing.
We made several attempts via various hacks to prevent this behaviour in Mozilla, but it raises again and again
A similar issue happens often to users with dvorak keyboards - ctrl-w and ctrl-v are next to each other on the keyboard, which means that a miskey when pasting text will often close the tab/window.

Not sure if a separate bug needs to be filed, but it's worth noting anyway.
The best patch for this is BE CAREFUL and stop rushing, i have NOT made this mistake in firefox for 4 years. This is a non-bug.
"The best patch for this is BE CAREFUL and stop rushing, i have NOT made this
mistake in firefox for 4 years. "

Shows well an English-speaker arrogance. Have you heard about AZERTY keyboards? Have you ever thought what exactly kind of typos is typical of people who constantly switch between QWERTY and AZERTY? Why would YOU make that mistake? It's us here in France who have to use both keyboard layouts.
"The best patch for this is BE CAREFUL and stop rushing, i have NOT made this
mistake in firefox for 4 years. This is a non-bug."

How about paying attention?  This is a Mozilla bug, not a Firefox bug.  Mozilla binds Ctrl-Q to Exit by default -- Firefox does NOT.  So it's no surprise that you haven't had this problem in Firefox, since it doesn't exist there.  (Unless maybe you're on a Mac?  It might exist there.)

If Mozilla just removed Ctrl-Q from the default keybindings, this bug would have been fixed years ago -- it's not really a burden to select Exit from the File menu in the rare instances when the user really wants to exit the entire browser.
> The best patch for this is BE CAREFUL ... This is a non-bug

Stop creating flamewars, you troll.
I think the best solution to this bug would simply be to add a warning dialog
if you try to exit Mozilla while more than one window is open, similar to the
warning dialog that intervenes in a browser window if you try to close it while
more than one tab is open. Certainly the same logic applies.

Jim H. (aka CuriousJ)
I regularly use both French and English keyboards. I had to memorise these keys because all i have is qwerty keyboard but the server interprets them as azerty (what that has to do with anything i don't know, does having a french keyboard prevent you from being able to press the right keys?).

And as for flame wars, the only person who did any flaming was you by saying anything. I have I have done is said becareful. People make mistakes every so often, someone making them regularly enough for to warrant a software code change must be grabbing his copy of mozilla for dummies and having a read.

I agree with James though, having a confirmation box is the best solution, even easier (which seems to be the path mozilla are taking....) ignore it, it's not a bug, be more careful when instead of using the mouse you try and use the keyboard. Mozilla could spend forever coding for human stupidity, how about a confirmation on every link you click just in case you didn't mean to click it?

See what i'm getting at?
Guys, the whiteboard says "No more comments, please".

> I agree with James though, having a confirmation box is the best solution

See comment 5 (!). Please read the bug entirely before commenting. Yes, it's a lot. That means you shouldn't comment.
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9-
I've read comment 5
Both ctrl-q and ctrl-w are now protected with prompts.
So this can be closed WFM?  Or am I missing something.
Assignee: jag → nobody
QA Contact: bugzilla → keyboard.navigation
No offence but you are missing something.

I am using windows 3.0.3 version and i pressed CTRL + W and the window immediately closed. No questions asked.
(In reply to comment #266)
> Both ctrl-q and ctrl-w are now protected with prompts.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.3) Gecko/2008092414 Firefox/3.0.3 ID:2008092414 doesn't prompt me when i hit <CMD>-q.  it just quits.
Sorry for commenting, but this hasn't been mentioned:

CTRL-Q still quits immediately on Firefox 9.0.1 for Linux.

I disable it using the keyconfig add-on: http://mozilla.dorando.at/keyconfig.xpi
Depends on: 550559
User Story: (updated)
This bug still exists, and immediately closes ALL TABS without confirmation. I use all-the-time private browsing which means that the damage is doubly severe, as there is no session to restore.

Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.3.0

Standard Firefox installation from the Debian Wheezy (stable at this time) repos.

I did thankfully find this Add-On which disabled the keyboard shortcut: https://addons.mozilla.org/en-US/firefox/addon/disable-ctrl-q-shortcut/ but that is not an ideal solution, of course.

Can this shortcut please be removed, or changed to involve a third key (shift?), or something? This is not a program function that is repeated so often as to require a simple two-key shortcut.
(In reply to unimportantdavidz from comment #272)
> Can this shortcut please be removed, or changed to involve a third key
> (shift?), or something?

I think, for "a third key" the user might use a Space, Enter or Q in the dialog "[Quit]/Cancel" that must be shown after pressing Ctrl+Q. If somebody wants to quit stuff (and for some reason without using the dedicated OS keys, like Alt+F4), pressing Ctrl+Q, Q is not much more burdensome than Ctrl+Q alone, but other people, who accidentally missed Ctrl+Tab or Ctrl+W, would appreciate the warning and could recover easily.

And the data loss occurs not only in private browsing. Even if the session is restored, everything is RELOADED, which means that the data might be gone by that time (not to mention one-time URLs and other stuff sensitive by design), as has been already mentioned.
Keywords: papercut
Whiteboard: No more comments, please → No more comments, please. The "warn-before-quit" addon can help
User Story: (updated)
User Story: (updated)
On windows Thunderbird quits at once on Ctrl+W or Ctrl+F4 with only 1 tab open, these are commands targeted at closing the active tab only, it is not the expected behaviour to close it altogether, when closing multiple tabs I usually use the key combination repeatedly and sometimes hit it too many times by misstake thus closing the last tab and losing the context, on the last tab it ought to ask "Closing the last tab will close <the application>, are you sure?" which I recall some old versions of firefox did, what was the design reasons for removing this outstanding feature, and please reconsider to at least optionally add it back.
At the moment (47) Ctrl+Q still doesn't ask the user whether they want to quit, whereas clicking the X pops up the confirm box (I've checked - the checkbox to be reminded is still checked).
This sounds like this bug (apologies if it isn't) - can it be solved by popping up the dialog on Ctrl+Q?
(In reply to github from comment #277)
> At the moment (47) Ctrl+Q still doesn't ask the user whether they want to
> quit, whereas clicking the X pops up the confirm box (I've checked - the
> checkbox to be reminded is still checked).
> This sounds like this bug (apologies if it isn't) - can it be solved by
> popping up the dialog on Ctrl+Q?

This thread is 6 years old. I guess this bug will be never fixed.
The workaround is to install one of the addons mentioned above.
Note that all the workarounds are going away with Firefox 57. The legacy addons have already been deprecated in Nightly.
> No more comments, please. The "warn-before-quit" addon can help 
Does not work in Nightly.
How do i solve this in Nightly? My firefox version is now going towards 57. I use nightly for testing but I'm missing lots of addons in my nightly test firefox!
Flags: needinfo?(dveditz)
@brunoais: Please ask questions that are unrelated (like third-party workarounds or add-on compatibility) to the specific task topic in a support forum instead, to keep the discussion in this task focused. Thanks.
Flags: needinfo?(dveditz)
Why not close the ticket as WONTFIX?
>Reported:	17 years ago
>Status:	NEW
Please change the whiteboard by removing the recommendation as it is now stopping to work.
I'd do it myself but I don't have permissions
Flags: needinfo?(dveditz)
[offtopic]

(In reply to nick@nijotz.com from comment #283)
> Why not close the ticket as WONTFIX?

@Nick: If you have technical arguments (which have not been brought up in the previous nearly 300 comments) why this issue should not get fixed, feel free to bring them up and elaborate.
Age of an open task or the fact that a proposed patch needs review or rework are not reasons to wontfix a task.
 
(Please discuss any potential generic bug report management questions unrelated to the specific topic of this task in a general Bugzilla forum instead - thanks.)
(In reply to Andre Klapper from comment #282)
> @brunoais: Please ask questions that are unrelated (like third-party
> workarounds or add-on compatibility) to the specific task topic in a support
> forum instead, to keep the discussion in this task focused. Thanks.

These comments are very relevant: This bug's whiteboard comment telling people to use the "warn-before-quit" add-on is no longer helpful. I have removed it.
Flags: needinfo?(dveditz)
Whiteboard: No more comments, please. The "warn-before-quit" addon can help
Whiteboard: Workaround: https://addons.mozilla.org/firefox/addon/disable-ctrl-q-shortcut/
Hello :BenB - strictly disable-ctrl-q-shortcut is no better than warn-before-quit. It's not a proper WebExtension, either, so it won't work with Firefox 57. An issue at disable-ctrl-q-shortcut [1] mentioned another alternative disable-ctrl-q-and-cmd-q. [2] However, it's broken on Linux due to Bug 1325692. Maybe it's better to mark 1325692 as a dependency of this bug so that people can follow how shortcut-customizing extensions work with Firefox 57+. Could you update the whiteboard? (I don't have the permission)

[1] https://github.com/choobin/dcqs/issues/10
[2] https://addons.mozilla.org/en-US/firefox/addon/disable-ctrl-q-and-cmd-q/
Flags: needinfo?(ben.bucksch)
@:BenB, that one also doesn't work with the current nightly.
User Story: (updated)
Depends on: 1325692
Flags: needinfo?(ben.bucksch)
Whiteboard: Workaround: https://addons.mozilla.org/firefox/addon/disable-ctrl-q-shortcut/ → Workaround: https://addons.mozilla.org/firefox/addon/disable-ctrl-q-and-cmd-q/ (WebExtension for Firefox 57+)
As stated on the extension's page:
> This add-on does not work as expected in Linux, until bug 1325692 is fixed. On Mac it works, I'm not sure about Windows. If you use Linux (and maybe Windows too), see this reply for alternatives).

On Linux, you can open the Keyboard application and add a dummy shortcut handled by "Ctrl-Q". This will prevent command from exiting Firefox. There are probably similar solutions for non-Gnome Linux distributions.
Whiteboard: Workaround: https://addons.mozilla.org/firefox/addon/disable-ctrl-q-and-cmd-q/ (WebExtension for Firefox 57+) → Workaround: https://addons.mozilla.org/firefox/addon/disable-ctrl-q-and-cmd-q/ (WebExtension for Firefox 57+) (Gnome/linux - use Keyboard application to add custom shortcut handled by Ctrl-Q) || Workaround Gnome-Linux: Open Keyboard application and add c…
(In reply to nick@nijotz.com from comment #283)
> Why not close the ticket as WONTFIX?
> >Reported:	17 years ago
> >Status:	NEW

He he.
>Reported:	17 years ago
>Importance:	critical

Should be at least evaluated, then probably closed.
Current Firefox warns on closing a window, Ctrl-W closes current tab, if you mistype Ctrl-Q you can restore sessions that weren't in private windows on restart. 

And there are WebExtension-compatible remapping add-ons (see whiteboard.)

I think this is a WONTFIX.
Severity: critical → enhancement
Flags: needinfo?(overholt)
> Current Firefox warns on closing a window

Is it a new feature? I didn't get any warning dialog when I hit Ctrl+Q. I'm using Firefox 56.0.1 on Arch Linux. Tested with a new clean profile.
> Current Firefox warns on closing a window

I have that turned off, as I don't want the warning when explicitly closing Firefox by clicking the X button.

> if you mistype Ctrl-Q you can restore sessions that weren't in private windows on restart. 

That will still result in data loss with some JavaScript web apps (and all the private windows!) and is also a major inconvenience.
This needs a UX call if we're going to WONTFIX it.
Flags: needinfo?(overholt)
Priority: P3 → P5
> > Current Firefox warns on closing a window

> I have that turned off, as I don't want the warning when explicitly closing Firefox by clicking the X button.

Ditto. That warning is excessive. I do *not* want to be warned every time I close a window, I do that dozens of times per day. Such warnings lead to alarm fatigue and are damaging.

I *do* want to be warned when I close the entire application with a single keystoke.

Alternatively, the key stroke for "exit entire app" could be one that's not as close to a common keystoke like "close tab/window". If "exit app" was Ctrl-Alt-Q (similar to Ctrl-Alt-Del), I wouldn't have the problem.

The simplest fix would be to use Ctrl-Alt-Q instead of Ctrl-Q for Exit. Problem solved. And it's a logical key combo.

> > if you mistype Ctrl-Q you can restore sessions that weren't in private windows on restart. 

> That will still result in data loss with some JavaScript web apps (and all the private windows!)
> and is also a major inconvenience.

And I need to re-login to all services with 2FA, which is a major time sink every time.

:emceeaich wrote in comment 291:
> I think this is a WONTFIX.

Given the interest (CCs, number of comments) on this bug, that would be very much misplaced.
Priority: P5 → P3
I also think that WONTFIX this is a really bad move.
We definitely need some way to handle this, even if just the correct event points to allow an extension to provide behavior and UI to the user.
For what it seems, the current WebExtension(s) that does this, can do it due to a bug... Which may be fixed any time in the future.
I am very surprised this issue has not been fixed after so much time.

The time of workarounds has passed. Since there is so much pressure from the users to fix it, it should be prioritized.

Thank you to the great developers of Firefox!
OMG!! I am so frustrated by this BUG (yes BUG, this is a BUG, uppercase BUG)

I used to use an extension for something as simple as disabling a shortcut, that by the way was a very dirty workaround if you ask me. Most applications allow changing shortcuts, but I'm not even asking for editing it, just disable this not useful one. 

Anyway, since firefox 57 in linux all of them stopped working suddenly, so I thought: "maybe they are working on solving this, shouldn't be harder than adding an 'if' clause", let's check the status of this on bugzilla... and I find this bug report from 18 F** YEARS AGO... with even 7 patches with proposed solutions (that I guess don't work anymore, but the fact that the bug is still there is a sign that this is intended)

Why can't you just add this option to at least about:config? I mean, you can check, there are dozens of extensions that thousands of people installed to disable a single shortcut, that should show you that people want this gone. And now they don't even work. So please.. please, pretty please... pretty please with sugar on top and strawberrys all over, could you solve this annoying BUG?

I write this from my preference of firefox over other browsers, but this is really something that bothers me so much.

I guess people told this already, but lets explain why this is really bad shortcut: A web browser is not an application, nowadays could be seen as a little "operating system", because every web is a potential application. Could you imagine how stupid would be for Windows/Linux/MAC to have the "shut down the computer" button next to something as common as "Ctrl-C/Ctrl-V" buttons? well, that's what firefox does..
Hello i strugling with some problems regarding to default hotkeys. Maybe i can contribute and work on this by creating some
settings to disable some anoying keys ? Is there somebody who like to mentor me in it ??
is there somone with nick "horlander" i need to ask info from ?
Flags: needinfo?(shorlander)
In case anyone actually tries to finally fix this, I would like to point out that on many locales on Windows Ctrl+Alt+(whatever) shortcuts are used for text input and there is no other way to access the corresponding characters (a backslash on my locale in the case of Ctrl+Alt+Q), so these shortcuts should not be used.
This bug is old enough to vote and bit me yet again today! :D
The workaround that I've been using is to leave a tab pinned at all times with code that uses the "onbeforeunload" javascript function.

https://github.com/gene1wood/sandbox/blob/master/docs/prevent_browser_quitting.html

With this tab open and pinned it forces the browser to prompt before shutting down giving me a chance to click "Stay on page" and stop Firefox from exiting.
Or same thing as webpage: https://gene1wood.github.io/sandbox/prevent_browser_quitting.html

Cute idea, thanks Gene! That will help the 100 people CCed and voting here.

But it would be good to fix it for the other 200 million users, too, so that it doesn't bite them as it has bitten us.
Bug comments are not the place for "me-too" comments or "why hasn't this been fixed yet!?!" 

The person responsible for making triage decisions for this category of bugs marked it as a P5, so I've moved it back.

I've restricted comments to members of the editbugs group.
Flags: needinfo?(shorlander)
Priority: P3 → P5
Restrict Comments: true
See Also: → 1438499
Bug 550559 was fixed, which should help here.
Component: Keyboard: Navigation → User events and focus handling
See Also: → 1690902

browser.quitShortcut.disabled=true will disable the Ctrl + Q shortcut on all platforms.

Depends on D103695

Assignee: nobody → evilpies
Status: NEW → ASSIGNED
Attachment #92770 - Attachment is obsolete: true
Attachment #45212 - Attachment is obsolete: true
Attachment #142452 - Attachment is obsolete: true
See Also: 1690902
Attachment #142453 - Attachment is obsolete: true
Attachment #142453 - Flags: superreview?(jag+mozilla)
Attachment #86671 - Attachment is obsolete: true
Attachment #129832 - Attachment is obsolete: true
Attachment #102373 - Attachment filename: 0 → patch
Attachment #102373 - Attachment is obsolete: true
Pushed by evilpies@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/4ffa8b3b68e8
Add a pref to disable the quit application shortcut. r=Gijs

pref("browser.quitShortcut.disabled", false);

Can we please make it so that new users aren't affected by this?

This is a problem for all users, not just power users. This patch fixes the bug for the people subscribed to this bug, but not for anybody else.

On Windows, I keep seeing a confirmation dialog when I close a window with tabs open. The dialog has a "[ ] Don't show this again" option. I think such a confirmation would be warranted in case of Ctrl-Q much more than when closing a window with the mouse.

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 87 Branch
Component: DOM: UI Events & Focus Handling → Keyboard Navigation
Flags: blocking1.9-
Flags: blocking1.4b-
Flags: blocking1.4a-
Flags: blocking1.4-
Flags: blocking1.3b-
Flags: blocking1.3a-
Flags: blocking1.3-
Product: Core → Firefox

Please don't re-open the bug. Maybe it's possible to enable this pref by default in new profiles. Feel free to open a new bug.

Status: REOPENED → RESOLVED
Closed: 3 years ago3 years ago
Resolution: --- → FIXED
Blocks: 1692205
Blocks: 1692716
No longer depends on: 1325692
QA Whiteboard: [qa-87b-p2]
Duplicate of this bug: 1799825
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: