User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Build Identifier: version 0.6 (20040502) My experience with other mail clients is that if you hit escape while composing an email in other programs, the windows is prepared to close and you are prompted as to what you want to do with the message. Thunderbird requires hitting Alt-F4 or the like to close the window. Reproducible: Always Steps to Reproduce: 1. Start a new message. 2. Hit Escape. 3. Nothing happens. Actual Results: Email stays open. If you want to close it, you must either use Alt-F4 or engage in mouse movements. Expected Results: Closed the email compose window and prompted to save a Draft or what have you.

This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/

I still think this is a valid request, and it isn't fixed in Thunderbird 1.5 beta 1.

At this moment ctrl+w close window or tab. It is pending a request for implementing in Tb 3.x also ctrl-f4 (see bug #511375). I don't think that pressing escape key is a natural way to close window: for example in Windows escape not close window. I think that this bug should be closed as wontfix because is a request that requires an unnatural behavior ... and then begin to be too many buttons that close a window or tab ( "key Hell's" ;-) )

Please DO keep this bug open and implement. Can anyone enlighten why this is such a trial to include as a feature?? It's far FAR easier to close an email window by pressing escape than a combo of keystrokes and moving the mouse.

What are the other email clients close the compose window when the user hits escape? I'm not aware of that but I don't have my windows machine here to test.

Outlook 2000 will close opened emails AND composed emails using Esc key. I'll try it on my other Outlook 2003 machine later. FWIW Irfanview also can be closed using Esc key.

Outlook 2000 will close opened emails AND composed emails using Esc key. I'll try it on my other Outlook 2003 machine later. FWIW Irfanview also can be closed using Esc key.

(In reply to comment #6) > Outlook 2000 will close opened emails AND composed emails using Esc key. I'll > try it on my other Outlook 2003 machine later. FWIW Irfanview also can be > closed using Esc key. Will it do this for emails you've started composing? I can easily see it if you opened a new compose window and hit escape that we could just close it right away. In the case of having a draft composed it seems somewhat prone to error, even with a dialog. But it's worth looking into if the Outlook's are doing it.

Yes, it will close new composed emails with no changes (text); as well as composed emails with text (drafts) and regular Inbox email as well.

(In reply to comment #6) >*FWIW* Irfanview also can be closed using Esc key. But Irfanview isn't a mail client.

Yes, hence the FWIW. My point is that others programs also carry the ability to close windows using Esc.

Comment on attachment 422048 [details] [diff] [review] This will handle the Escape key to exit the compose window I meant to try this on Windows when I last had it running but forgot. Either way I'm not a code reviewer so I moved myself to ui-review. I'd be interested in what a broader audience like the newsgroups would say about a change like this. So far it seems Windows only so we should mark the bug as such. Mac or Linux programs I've tested don't seem to have this behavior.

Thomas, what do you think?

Actually, I'd love it. I'm a heavy user of IrfanView, and IMO it's really comfortable, speedy, and intuitive to just use ESC to close windows that are of a more temporary / light-weight nature (like most email msgs). It's interesting that I'd never think of closing Word documents with ESC. Maybe it's just habit formation; otherwise it might be the perceived "weight" of the UI, where viewing images and composing emails feels more like a light-weight interactive dialogue (which are always closed with ESC), whereas a full-fledged Word Document with all its toolbars feels more like a heavy window (requiring Ctrl+F4 for closing). More systematic thoughts: Checking for problems - could this affect any other actions that require ESC? (I think not) - is it likely to be hit accidentally? (not really) - if hit accidentally, does it cause trouble? (no, as long as we ask for unsaved changes as we currently do) - does it hurt if some people don't know, or if it's perhaps officially non-standard? (I think not; it's definitely plausible and it's de-facto standard for some wide-spread apps like IrfanView). Comparing benefits - comfortable (avoids having to stretch your fingers to reach that double key combo, while carefully trying not to miss it) - precise, fast and efficient (single-key, easy target in upper-right corner of keyboard) - intuitive (known from other programs, including Outlook, IrfanView, MetaPad, WinMerge...; maybe not intuitive for everyone, but it'll be most beneficial for those who need it most: keyboard users) Conclusion: IMO, benefits clearly win. Please implement this. Things to consider 1) do we want this for other tabs / windows too? - viewed mail windows (imo yes, as in outlook per comment 7 and comment 9) - viewed mail tabs (why not?) - compose mail *tabs* (bug 449299; imo yes) - other tabs, like search results etc. (needs thinking; maybe yes; might actually be a cool way of getting unused search results tabs out of the way?) 2) do we need a way to switch this off? a) via pref (yes) b) via options UI (maybe yes) 3) do we want to disable this depending on focus, in some spots where ESC is used? a) e.g. when focus is in font picker dropdown: ESC will close the dropdown; should another ESC close the window or do nothing? b) same for address autocomplete: first ESC will cancel the completion; should another ESC close the window or do nothing? Notwithstanding those nits and details, this would be a cool feature to have.

Side note (in reply to comment 15): > intuitive (known from other programs, including Outlook, IrfanView, MetaPad, > WinMerge...) What do these have in common (except M$ Outlook, of course ;))? They're all *cool tools* to get your everyday computing tasks done efficiently. Thunderbird would definitely fit well into that category. :)

Comment on attachment 422048 [details] [diff] [review] This will handle the Escape key to exit the compose window In general this seems fine. I'm a bit worried about the interaction with other uses of ESC as Thomas pointed out. Also lets do this as Windows only unless we have some evidence of this as a common behavior on the Mac or Linux.

confirming rfe based on Bryan's comment 17.

Comment on attachment 422048 [details] [diff] [review] This will handle the Escape key to exit the compose window muhammad, thanks for providing the first patch. Based on Bryan's comment 17 and my comment 15, we need to watch interaction with other uses of ESC. Unfortunately, there's a problem with your patch: STR compose, type xy in to field, autocomplete matches xy@asdf.com, press ESC Actual result (with patch1) - tb asks to close msg Expected result - should only exit from autocomplete -> obsoletes patch1 muhammad, could you provide updated patch where first click on ESC during address autocomplete first exits from autocomplete, then the second ESC closes msg? Can you implement hidden pref to switch this off for people who don't want it?

Related Bug 543365 - ESCape key should close message read tab

1. Outlook 2003 asks you what to do with a message you are composing if you hit ESC. I am not sure how it works (if at all) in 2007 and 2010. 2. IrfanView is a prime example of poorly designed application -- having key shortcuts (Home/End) that do different things (horizontal scroll or go to first/last image in the directory) depending on the image width is a monstruosity. 3. IrfanView is a SDI application. Email client is MDI application. They are uncomparable. Whoever is asking for this, doesn't have a clue about Windows UI -- ESC should dismiss dialog boxes, not application windows. The only exception to this rule are image viewers.

(In reply to comment #21) > 1. Outlook 2003 asks you what to do with a message you are composing if you > hit ESC. Which shows there is other major windows-based email applications out there that use ESC for closing a message composition. Of course we, too, will ask the user if he presses ESC to close the window (or tab, in the future) and there are unsaved changes, if he wants to save them as a draft. Don't worry, Igor, even if you hit one ESC too much by mistake, you'll not loose any of your data. Just hit ESC again to dismiss the "Save Message" dialogue box and you'll be back to composition. No problem here. > I am not sure how it works (if at all) in 2007 and 2010. I am not sure if that helps for this bug? > 2. IrfanView is a prime example of poorly designed application -- having key > shortcuts (Home/End) that do different things (horizontal scroll or go to > first/last image in the directory) depending on the image width is a > monstruosity. IrfanView is certainly not standards-conform, but it was designed with keyboard efficiency in mind. Poorly designed Home/End function in IV has nothing to do with this bug. > 3. IrfanView is a SDI application. Email client is MDI application. They are > uncomparable. What I see is that we currently compose messages in standalone windows that are closed with Alt+F4 (not Ctrl+F4) on windows, which looks very much like SDI to me (notwithstanding that we have tabbed MDI elsewhere). But it's rather irrelevant for this bug if we compose in SDI windows or MDI tabs (bug 449299): Evidence from MoMo getsatisfaction shows that many users don't care if it's single document windows or multiple document tabs. They want the comfort and efficiency of closing their message reading tab with ESC anyway. That's because they are used to that shortcut from the current behaviour in TB 2 and TB 3.1, where we can close message windows with ESC (hence bug 543365, and http://getsatisfaction.com/mozilla_messaging/tags/bug_543365, therein http://gsfn.us/t/nr9t with currently 33 votes). > Whoever is asking for this, doesn't have a clue about Windows UI Please be friendly and civil! Nobody ever said that ESC is 100% standards-conform but that doesn't automatically mean it's useless or unintuitive. Of course we will keep the existing standard shortcuts of Ctrl+W or Alt+F4 for closing composition windows, or Ctrl+W and Ctrl+F4 (bug 511375) for composition tabs lateron. Btw, note how Ctrl+W on Firefox will first close all the child tabs and then close the main window, effectively ignoring the difference between SDI and MDI (I think they have a setting for different behaviour, though). > ESC should dismiss dialog boxes, not application windows. After implementing this bug, hitting ESC will still dismiss any dialogue boxes, dropdowns, autocompletes or whatever needs ESC *before* closing the window. In other words, we are not changing the existing behaviour for closing dialogues etc. Only when there is nothing left to ESCape from, and the user deliberately presses ESC *once again*, that is when we will close the window (after asking, if there's unsaved changes). Even when you just hit ESC unconsciously more often than needed (without intending to close the tab or window), there will be *no risk* of losing data, as explained above. So honestly, where's the problem? > The only exception to this rule are image viewers. In theory, maybe yes. In real life, no: Comment 15 has several other examples that use ESC for closing windows: Outlook, MetaPad, WinMerge. Plus Thunderbird 2, 3 and 3.1. Igor, rather than just emotionally rejecting what others find useful, let's try and find a way that works for everyone. I have already mentioned in previous comments that we might want a pref to switch off ESC behaviour for those who don't want it (although I am still failing to see any significant problem here). Otherwise, if you don't like closing windows or tabs with ESC, just don't press ESC again if there is nothing else to escape from...

I am concerned about you guys considering adding less standard ESC before adding more standard Ctrl+F4 for close tab. >So honestly, where's the problem? Ok, tell me what happens if: 1. I compose large message (has > 1MB of attachments) 2. I have slow upload (say 512 Kbps) 3. Thunderbird is copying the message to Drafts on IMAP server as a part of autosave operation 4. I accidentally hit ESC wanting to exit autocomplete one time too many 5. I accidentally click yes because I wanted to give focus to compose part of the window and dialog box popped up as a result of that erroneous ESC keypress?

If that scenario occurs, it's on you, buddy.

(In reply to comment #23) > I am concerned about you guys considering adding less standard ESC before > adding more standard Ctrl+F4 for close tab. It's not my decision to take (I'm just a volunteer), but don't worry: If anything, I'm sure that Ctrl+F4 gets added first (and you are right, it's more important). > > So honestly, where's the problem? > Ok, tell me what happens if: > 1. I compose large message (has > 1MB of attachments) > 2. I have slow upload (say 512 Kbps) > 3. Thunderbird is copying the message to Drafts on IMAP server as a part of > autosave operation > 4. I accidentally hit ESC wanting to exit autocomplete one time too many > 5. I accidentally click yes because I wanted to give focus to compose part of > the window and dialog box popped up as a result of that erroneous ESC > keypress? *lol* Please let me watch when you perform that trick! Apart from getting all the coincidental conditions, pressing ESC exactly *one* time too much with the left hand, while virtually at the *same* time clicking your mouse with the right hand, without really looking at the screen, and hitting exactly those 4 cm² of the "Don't Save" button in the exact middle of the screen, probably for starting to type on the *left*... Well, > if that scenario occurs, it's on you, buddy... Jokes aside, what I take home from Igor's comments is that (anticipating Bryan's line of thought) we should carefully consider if there's a potential for confusion for those who *unintentionally* press ESC one time too much, and how to counter that. I don't know if first-time-questions are still legitimate UI? E.g., we could have a non-intrusive information bar at the bottom when user presses ESC although there is no dialogue etc. to escape from, something like "You have just pressed ESC again: Do you want to use ESC for closing the current tab in the future? [Yes, use ESC to close tabs] [No, thank you] [Ask me again later]" This would require a visible setting, perhaps in Tools > Options > Reading & Display: Below [ ] Close Message Window on Delete, we could have something like [ ] Close Message Windows/Tabs on ESC" Alternatively, just implement the feature and wait if there are any negative responses before doing more sophisticated things. Some setting would be good, though; customisability is a high value.

Ups, that's Tools > Options > *Advanced* > Reading & Display I wonder if we have to differentiate... We've proposed ESC for composition and reading so far, what about search and folder tabs? Should they be closable with ESC, too? If yes, we might need a bit more distinction in the settings (smart and compact ui wanted!). But we can limit to message windows, for a start.

Guys, seriously, keyboard shortcuts have to be thought out very carefully. What if: 1. I press Esc one time too many like in previous example 2. I press Tab to change focus to Subject from Address field which then changes focus to "Don't save" on the dialog, and I press Space? Those scenarios are not so impossible as you might think for people like me who don't look at the keyboard while typing.

Igor, I think we all understand your point, even though we might differ on the likelihood, and in several of my comments in this bug, lastly in comment 26, I have proposed ways of addressing your problem (with a user-configurable setting to disable close-on-ESC behaviour). So there is no need for you to provide further examples as it doesn't add information to this bug. (In reply to comment #27) > Guys, seriously, keyboard shortcuts have to be thought out very carefully. > What if: > 1. I press Esc one time too many like in previous example If you press any key too many, that's always *your fault*, and we can't code TB to guard against any possible user error. But I agree with you it can happen quite easily with ESC that you press it one time too many, and ux-error-prevention is indeed a design goal that's part of good UI design. > 2. I press Tab to change focus to Subject from Address field which then > changes focus to "Don't save" on the dialog, and I press Space? > Those scenarios are not so impossible as you might think for people like me > who don't look at the keyboard while typing. Not looking at the *keyboard* is OK if you can touch-type, but not looking at the *screen* is your problem! If you do look at the screen, I don't think it's very likely to run into problems. It is certainly *possible* to run into problems, but not very likely for most users. I am a fast keyboard user myself, and again I doubt your sample case will occur easily: - you press ESC with your left hand - you then have to move down your left hand to press TAB (again with your left hand), which will cause a little delay - that delay is exactly when the Save dialogue will pop up, and if you are looking at your screen, you will see it - Email Subjects don't usually start with spaces, but I agree they might start with the letter "d" which would also trigger "Don't save" on en-EN version quite easily Bottom line: Yes, Igor is right, there *might* be problems if all of the following conditions co-occur: - user presses ESC exactly *one* time too much (user's fault) - user is very fast in using keyboard - user ignores screen feedback (basically user's fault again) - user happens to press/click in exactly the way required to trigger "Don't save" (Igor is right, it's possible). Implementing a user-configurable setting to disable close-on-ESC will avoid even this unlikely possibility of error.

Ok, just please keep in mind that the user is not necessarily "ignoring screen feedback" -- screen feedback can be delayed because of a slow or temporarily slowed down computer (for example, antivirus starts scheduled scan in the background, user is running some other task such as video encoding or archiving, etc), but the keystroke will be buffered, read and acted upon when it is too late. Many developers seem to assume that the user (or user's computer) are performing only a single task at a time and they design UI with that in mind resulting in endless frustration. My personal opinion is that single key shortcuts should be reserved only for non-destructive or totally reversible operations. At least a config option to disable such shortcuts would be nice.

Thomas D is echoing all of the sentiments I have regarding adding the Esc functionality to Thunderbird message compose window. As a long time Outlook user, this feature makes complete sense. Esc will close an empty window, no questions asked; or close a window with changes made with a "Do you want to save changes" notification. Igor, significants problems are not present with this feature - Outlook would have rectified 10 yrs ago if so. Who can implement this?

Out of curiosity: 1. If you are a long time Outlook user why have you switched to TB? 2. Where did you get the idea that Microsoft would rectify such problem?

Igor; If memory serves correct, I started to used TB out of thriftiness. :) But am required to use Outlook for work. Considering MS's giant Outlook user base (>100 million?), my hunch is any bugs would have been fixed regarding closing windows using Esc.

FTR: Situation for this bug has changed somewhat, because we've introduced two new uses of ESC if used from inside the text body of a composition: Bug 521158 - ESC from inside msg body or with focus on automatical attachment reminder bar will close that bar (assuming there's no other reason to press ESC in body after all ESC keypresses on menus and such have been consumed orderly). Same behaviour for subject field has been requested (Bug 994655) because automatical attachment reminder now also checks changes of subject (Bug 944643). Bug 530629 - ESC from inside msg body or with focus on composition's new Find bar will close that bar. So there are two new prominent possibilities of using ESC from msg body to do other things. Which increases the potential for accidental extra ESC keypresses which would unexpectedly trigger closing compose window (after confirmation, if changes have been made). I conclude: - imo it's still a nice idea to add this comfortable and efficient way of closing compose windows; also externally ux-consistent with Outlook and appreciated by users per anecdotal evidence here - however, given that it's non-standard way of closing big windows, this definitely needs an option in preferences UI where users can switch this off. - in view of other uses of ESC, we still need to discuss if this should be made default behaviour or not (I'm leaning towards yes, make it default behaviour, but not sure.). - we also need to decide if we want ESC to trigger closing of compose window only if focus is in main msg body or on which other UI elements we'll allow ESC for that purpose or not (after all other uses of ESC have been consumed).