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.

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...

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.

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.

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.

Why are there two sets of these files?

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.

§$!@½%&!!! 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.

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.

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?

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)

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?

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.

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).

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.

Reassigning to patch author

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!

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.

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.

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.

> 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.

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

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.

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.

renominating.

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.

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

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.

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...

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.

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.

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-

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.

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.

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.

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. ***

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.

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.

*** Bug 203476 has been marked as a duplicate of this bug. ***

adt: nsbeta1-

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.

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. ***

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.

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?

There you go: http://lxr.mozilla.org/seamonkey/source/extensions/help/resources/locale/en-US/shortcuts.xhtml#203 http://lxr.mozilla.org/seamonkey/source/extensions/help/resources/locale/en-US/shortcuts.xhtml#205 http://lxr.mozilla.org/seamonkey/source/extensions/help/resources/locale/en-US/shortcuts-navigator.xhtml#143 http://lxr.mozilla.org/seamonkey/source/extensions/help/resources/locale/en-US/shortcuts-navigator.xhtml#146 Prog.

Comment on attachment 142453 [details] [diff] [review] accel-shift for everyone but macos; Amend documentation this request is not an endorsement

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.

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.)