Shredder has the ability to open messages in a new tab. In Windows it's a default keyboard combination to close a tab by pressing Ctrl-F4. This doesn't work for Shredder's tabs at the moment. Please add this keyboard shortcut (at least to Windows platform, don't know about Unix or Mac).

You can use ctrl-w. I think this issue should be closed as WFM.

Aureliano let's ask Bryan. Bryan - your thoughts ?

In Firefox both Ctrl-W and Ctrl-F4 work...

wow, i never knew of that combo before and it's quite a stretch for my fingers :) That is a windows default keybinding so we should pick it up as well. This should be an easy one for someone to add

Hi, yes, this is default for ALL windows applications... So, please consider it! Thanks.

I can't help wondering if there's been more time spent managing this bug than it would take to fix it...

Jay, furia, enthusiasm and and eagerness does not exempt us from the need to observe https://bugzilla.mozilla.org/page.cgi?id=etiquette.html However, comments which help develop a patch are welcome.

Apologies, that was out of line. This is a daily annoyance for me, and it seems like it must be a pretty minor change. I'd be happy to jump in and fix it, but I haven't worked in C++ for ages and I'm not familiar with the Thunderbird codebase at all, so it would probably take significantly more time for someone to get me pointed in the right direction than for them to just do it.

Me too for C++ development but it will be helpful to search source for Ctrl-W shortcut definition and add patch for Ctrl-F4 support. :-)

No idea if I'm on the right path, but: suite/browser/tabbrowser.xml has this in it: <field name="_keyEventHandler" readonly="true"> <![CDATA[({ tabbrowser: this, handleEvent: function handleEvent(aEvent) { if (aEvent.ctrlKey && aEvent.keyCode == KeyEvent.DOM_VK_F4 && this.tabbrowser.mTabBox.handleCtrlPageUpDown && this.tabbrowser.getStripVisibility()) this.tabbrowser.removeCurrentTab(); } })]]> </field> however there's no mention of DOM_VK_F4 in the rest of the app at all, everything else seems to use VK_F4. Not positive if this is the right piece of code because I don't see any handling here for CTRL-W which I know works, so I expect to see that handled somewhere....

I couldn't agree more on most comments - tab behaviour in TB is inconsistent with Firefox. Ctrl-F4 is a Windows "legacy" most users are used to (we may like it or not). ***What I'm really missing*** is a button to close all open tabs, since TB preserves the actual open tabs upon closing and restores them next time TB is started. I also observed an "interesting" side effect with regard to tabs for IMAP based email but haven't been able to reproduce the behaviour.

stuff in suite/ are for seamonkey only. You wan't to be looking in mail (and mailnews) Ctrl+W is actually here: http://mxr.mozilla.org/comm-central/source/mail/base/content/utilityOverlay.xul#59 ... but note those lines that it's only there for show :/

We're used to CTRL-F4 in Firefox. All of a sudden tabs are added in Thunderbird and we go "CTRL-F4" and nothing happens! I think the whole tabbed browsing thing is shaky as I often open a message from a search and at first what shows up in the tab is the last thing I was previewing. Very weird.

2009-08-19 <- date this bug was submitted 2010-06-21 <- today Forget the etiquette, tell us whether it really takes 11 months to add a keyboard shortcut?!? By the way, why do you folks expect Average Joe users to tinker around the source code? I am a software engineer and I know the following: 1. It takes a lot of time to understand the organization of such a big codebase. That means someone who started looking at it today might be able to do something usefull in a month or so provided that they are already fluent with C++, XML, Java, XHTML, DOM and Javascript as well as with the toolchain used for building the application. That's a lot of stuff to swallow even for a seasoned developer. 2. It is error-prone. Even after spending some time with the codebase there is a chance that the proposed patch will be made in a wrong place. Someone will have to waste time reviewing the patch and it will be rejected thus further postponing bug resolution. If that someone already knows where the patch should be made, they could at least share that here if not submitting the patch themselves. Finally, if you asked someone for help, wouldn't you snap if it took almost a year for them to come back to you, and if all they said after that much time was "go help yourself"? Jay's comment hits the spot because it is not the first time that more time is being spent on marking dupplicates than on actually fixing things or at least pointing others in the right direction. IMO, you are the ones who should learn some etiquette. Too bad that you are too arrogant to see it.

(In reply to comment #18) > 2009-08-19 <- date this bug was submitted > 2010-06-21 <- today > > Forget the etiquette, tell us whether it really takes 11 months to add a > keyboard shortcut?!? > > By the way, why do you folks expect Average Joe users to tinker around the > source code? > > I am a software engineer and I know the following: >... > IMO, you are the ones who should learn some etiquette. Too bad that you are too > arrogant to see it. uhmm, no sir, let's not "forget" https://bugzilla.mozilla.org/page.cgi?id=etiquette.html and civility - it's a basic operating principal. Your comments are more appropriate in one of the forums http://www.mozilla.org/community/forums/

The etiquette you keep linking to is broken. For example: "The only person who has any obligation to fix the bugs you want fixed is you." Tell me, how does that make any sense unless you start with a patently false assumption that everyone using open-source applications is a seasoned software developer? I can understand the "no obligation" part, but it is simply rude to leave things open for so long without giving any feedback, much less help/guidance to those who attempted to solve it. It completely defeats the purpose of having public bug-tracking system. Tip of the day: If you don't want people to depend on you, then don't provide a service.

I just moved to Thunderbird from Eudora 7, where Ctrl-F4 worked. I agree with Igor. I have also written C and C++ code in my past, and I really do not have the time to learn everything that is needed in order to make this simple change. Actually, I have a number of other complaints, like the order in which windows are created, which is restricted compared to what Firefox allows. If every small fix will take a year to fulfill, this is not going to be fun.

Is there some sort of uberforum where Moz philosophy and future planning is discussed. Because I want to endorse that Adherence to Standards isn't being observed as a priority (which I think is how Moz came into being). How is it that simple errors (such as this) are left to drift in the wind (because nobody wants to stoop so low I assume), and what can be done to attract attention to them. I also want to understand how it is that somehow the beta test community don't seem to notice the continued erosion of real estate. Steve

Related bugs: Bug 543365 - ESCape key should close message read tab Bug 242636 - ESCape key should exit a compose/write window for new email

@Thomas D.: 1. I don't see how ESC key is related to this in any way, and I disagree that ESC should close windows unless it is full-screen image viewer.

@Igor L.: I think there is the obvious relation that they are all shortcuts (existing or proposed) for closing windows or tabs. I am not sure if your opinion about ESC shortcut for closing windows is helpful for this bug about Ctrl+F4.

Open-source -- an opinion (if you are not interested in opinions don't read) After a year of not fixing such a simple issue, and after seeing how this has become yet another bug which other bug reports will link to with status RESOLVED:DUPLICATE (as if that somehow magically resolves the problem as well), it is now obvious that Mozilla developers do not care about making consistent user interface among their own products, let alone consistent with other applications. I'd even dare to say that by letting people report so many duplicates (by not fixing some of the long-standing bugs), they are intentionally skewing the Bugzilla statistics to make both them and the code look better -- after all there is much more RESOLVED than OPEN bugs when you keep "resolving" duplicates, right? In my eyes, open-source developers are much like those irresponsible males who get some girl pregnant, and then run away from responsibility -- open-source software is their bastard child, left to the user (read: mother) to tinker and toy with. It may grow up to be ok, but it will never be mature like those children who had normal, caring family with both parents involved in its upbringing. Screw open-source. I'd rather pay for software and get timely support than get it for free, and depend on someone's mercy to fix a problem which I don't have time and/or expertise to deal with on my own. Best regards, Igor Levicki

Thats a top class rant, and tells it like it is Praise

this is an enhancement bug, so there is zero urgency to fixing this bug. and even if it wasn't an ENH bug, this is not the place for rants or promises of "i'm taking my business elsewhere. such postings and support of them have no place here. please pay attention to https://bugzilla.mozilla.org/page.cgi?id=etiquette.html - these were written for a reason. disclaimers don't give you immunity. of course, patches and technical postings are welcome. thanks

This is a used to work and now doesn't bug a failure to conform to standards bug a (one assumes) mighty easy to fix bug a boring to fix bug no doubt your reply is not helping

Correction, it isn't strictly true to say it >>used to work (in TB) and now doesnt<< sorry I think what I had in mind is that there wasn't a problem until TB3. FF has always worked properly but tell me Did somebody in TB development say - I don't like Cntrl-F4 - lets not implement it or did they say - I think I remember most of the keyboard shortcuts, if I forget any they can't be worth keeping It's plainly a bug not an enhancement

if this is indeed a regression (which hasn't been stated before as far as I can tell) then it shouldn't be hard for someone with minimal skills to find what bug caused the regression. bug 533513 is a good example of a reporter helping move a bug forward. instructions at http://www.rumblingedge.com/2009/02/24/howto-find-regression-windows-through-manual-binary-search/ and pointers to the nightly builds alpha, beta nd final release builds can be found at ftp://ftp.mozilla.org/pub/thunderbird/releases/

(In reply to comment #29) > this is an enhancement bug, so there is zero urgency to fixing this bug. Even if it was an enhancement bug (which it isn't), "zero urgency" should not translate into "infinite amount of time" to fix something as trivial as this. > this is not the place for rants or promises of > "i'm taking my business elsewhere. A whole year to address a trivial keyboard shortcut issue without *any* progress whatsoever (unless marking duplicates is a progress for you?), and without even a remote sign of an intention of fixing it in my opinion deserves much more than a simple rant. Lucky for you, you keep hiding behind "free, no obligations, no warranty" shield. Even being downright honest and saying "WON'T FIX" and thus admitting you don't give a rats ass would be better than this. I wasn't promising to take my business elsewhere, I was just pointing out a simple fact -- the value of a free product without support is equal to its price (zero). > please pay attention to > https://bugzilla.mozilla.org/page.cgi?id=etiquette.html - these were written > for a reason. disclaimers don't give you immunity. Disclaimers don't give me immunity? Can you look in my eyes and tell me with a straight face that the flawed etiquette you keep boring people with is not a disclaimer written to give *you* immunity? If there is anything I hate in this world, that would be double standards and hypocrisy. > a good example of a reporter > helping move a bug forward You can check two bug reports I submitted (you even commented on one). I answered all the questions that were asked in an effort to move them forward. It has been 3 months, one is still unconfirmed even though there is a reproducible test case, and another one is obviously secretly classified as an "enhancement" since nobody is looking into it just like nobody is looking at this one. Those bugs are not showstoppers, but they aren't irrelevant either. I wonder how many duplicates of those will be marked before someone takes notice.

Gerv, could we get some assistance here?

>>if this is indeed a regression (which hasn't been stated before as far as I can tell) then it shouldn't be hard for someone with minimal skills to find what bug caused the regression.<< I retract what i said about it used to work in TB, which I guess is what "regression" means Nonetheless it must surely be dead easy to fix- CntrlW (non standard) is implemented, and CntrlF4 should do the exactly same thing. I asked here some time ago how one could contribute to Mozilla, >>Is there some sort of uberforum where Moz philosophy and future planning is discussed. < Because, yes my programming skills are 1 not great, 2 well out of date and 3 not in this language, but I do know something about responding to customers, and I have debt to TB from a long time back where decent IMAP handling enabled a real improvement to my business. So I'd like to contribute where I can. Unlike Igor I don't imagine for a moment that one would get anywhere asking Microsoft to sort out a similar error, but then I had imagined that Moz didn't want to be "as bad as Microsoft." Igor seems to share my suspicion (and this does happen) that the structural problem with pro-bono is that it allows people only to do what seems like fun and glorious and creative, and doesn't ensure that the humdrum also gets sorted.

(In reply to comment #35) > I asked here some time ago how one could contribute to Mozilla, > >>Is there some sort of uberforum where Moz philosophy and future planning is > discussed. < > Because, yes my programming skills are 1 not great, 2 well out of date and 3 > not in this language, but I do know something about responding to customers, > and I have debt to TB from a long time back where decent IMAP handling enabled > a real improvement to my business. So I'd like to contribute where I can. An excellent question, easily answered. The last link at http://www.mozillamessaging.com/en-US/about/get-involved/ leads one to https://developer.mozilla.org/En/Developer_Guide And volunteers are always welcome. Thanks! > Unlike Igor I don't imagine for a moment that one would get anywhere asking > Microsoft to sort out a similar error, but then I had imagined that Moz didn't > want to be "as bad as Microsoft." Igor seems to share my suspicion (and this > does happen) that the structural problem with pro-bono is that it allows people > only to do what seems like fun and glorious and creative, and doesn't ensure > that the humdrum also gets sorted. There is no fun vs value factor here. The MAIN structural issue is there are flat out too few bodies (volunteers + others) to handle too many bugs (see the list [1] and consider the fact that it takes many man hours to implement anything that includes reviews, QA, ongoing testing, etc). When we (and I mean that collectively as in everyone who uses Thunderbird) solve the issue of not enough help, then we will have made huge progress toward addressing concerns that "no one is paying attention to my bug". [1] open bugs: https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced;short_desc_type=allwordssubstr;resolution=---;type0-0-0=nowords;value0-0-0=count%20counts;product=MailNews%20Core;product=Thunderbird;short_desc=

Wayne, The list of bugs you provided further confirms my suspicions regarding management issues here. Not only are most (if not all?) of the bugs unconfirmed, but many of them are open for long periods of time. Furthermore, some of them have been reopened after being "auto-resolved", and then again nobody touched them for, in some cases, several years. Finally, a lot of those bug reports are requests for improvements or new features. If I understand development correctly, highest priority should have the bugs that affect a lot of people (showstoppers, chrashing, data corruption, etc). Following those should be user interface bugs (such as this one), accessibility bugs, cosmetic bugs, and new features and improvements should come at the very end. So, what I said before still stands. Something is seriously rotten here -- the body count seems not to be the only problem.

Igor and steve, I understand that you're frustrated with a number of things here, both in terms of the turnaround time to fix bugs and the fact that Thunderbird, like many software projects, is imperfectly managed. These are entirely valid feelings, and many of us involved in the project share those same feelings from time to time. As an open source project, Mozilla depends heavily on volunteers being motivated to contribute their time and expertise. Over the years, it's become clear that one key situation when volunteers lose motivation and leave the project is when they start to feel that it is a hostile place to get things done. The etiquette rules exist specifically to help avoid this situation. I understand that you don't agree with the etiquette rules, and you're entirely welcome to that opinion. After that policy was mentioned multiple times in this bug, you've both posted comments violating it. If I'm forced to choose between enforcing the guidelines in order to make Bugzilla a more enjoyable place to work, and keeping your Bugzilla account enabled, I will choose the former every time. To be clear, if you violate the etiquette rules again, I will disable your account. Please direct any response to this directly to me via email, and allow this bug to revert to its intended use: technical work. If you have specific constructive improvements to our process to suggest, you're welcome to propose them on tb-planning: <https://wiki.mozilla.org/Thunderbird/tb-planning>.

Dead messenger signing off

This bug is mis-classified -- it should be minor or normal, not an enhancement. Rationale: Making application UI compliant with one of the target platforms (Windows in this case) should be a requirement, not enhancement. This is the last thing I am going to say here.

requested in http://getsatisfaction.com/mozilla_messaging/topics/why_ctrl_w and other topics which I have merged together.

(In reply to comment #41) > requested in http://getsatisfaction.com/mozilla_messaging/topics/why_ctrl_w and > other topics which I have merged together. It appears that you did not merge the votes.

(In reply to comment #42) > It appears that you did not merge the votes. getsatisfaction completely controls the counts, but in my experience it correctly increments the interested parties count from merged topics. Perhaps you are looking at the 35 votes at http://getsatisfaction.com/mozilla_messaging/topics/esc_ape_doesnt_close_message_window_anymore - but I did not merge that topic because it's principal issue is not about ctrl+F4. I only added it as a reference to this bug

No, I am looking at this one that I started: http://getsatisfaction.com/mozilla_messaging/topics/wheres_my_ctrl_f4 At that report: 2 people have this problem 6 people participating And at this one: http://getsatisfaction.com/mozilla_messaging/topics/why_ctrl_w 11 people like this idea 3 people participating So: 1. Number of people participating was not merged. 2. Because you reclasified it as an IDEA (as opposed to PROBLEM) you seem to have lost two votes and although I cannot prove it I suspect it, because number of participants wasn't added up either. Finally, I dislike your change because I believe that non-working Ctrl+F4 should be classified as a PROBLEM, not as a feature request -- if it wasn't a standard shortcut in other Windows applications (including Firefox), and if Thunderbird users were first to request it, then it would be a feature request.

This is more-or-less a direct port of the Firefox code[1], which is a little bit oddly structured, but when in Rome... [1] http://mxr.mozilla.org/mozilla-central/source/browser/base/content/tabbrowser.xml#2370

I cannot see the Control_W in that code. (Not that I can write C++) > > This is more-or-less a direct port of the Firefox code[1], which is a little > bit oddly structured, but when in Rome... > > [1] > http://mxr.mozilla.org/mozilla-central/source/browser/base/content/tabbrowser.xml#2370

(In reply to comment #46) > I cannot see the Control_W in that code. (Not that I can write C++) The Ctrl-W shortcut is handled elsewhere. Like I said, it's oddly structured.

Comment on attachment 503335 [details] [diff] [review] Support Ctrl-F4 on non-Mac platforms Unless there's a technical reason we can't use the standard XUL command/key infrastructure, I think we should be using the command/key infrastructure. If there is a technical reason we can't, we we should have big comments around the adding of the event listener and probably still try and shunt the handling through the command infrastructure. If we start adding event listeners across the code-base, it is going to be harder to figure out what is going on. I agree the firefox implementation is extra unusual in this case. Additionally, while I really appreciate you trying to pick up bugs that are not getting any love, this is definitely something that really requires ui-review sign-off and should probably get that first before any coding happens. Especially in a thread with as much discussion and meta-discussion as this one, whoever makes the ui-review request should explain in concise detail the current configuration and what the desired new configuration would be. Unless you have some skin in the game, this is not on you unless you want to pursue it.

Surely what needs doing is finding Control_W in the code and replacing it with (Control_W .or. Control_F4) As simple as that (Not that I have any authority or background knowledge of this code) A ui-review request sounds far too heavyweight a process, this isn't an innovation which might upset something else or need lots of documentation or anything like that. The simple fact is that ControlF4 is a windows shortcut going back to at least Win3.1, still in the spec, and for whatever reason it got forgot in TB. It just wants to be unforgotten, please. Pretty please. (whimper).

I hope that perhaps after reading the comment #48 some people from the Bugzilla and TB/FF community will understand that even though they believe they are encouraging contribution with current etiquette it is actually impossible to start contributing without tutorship from experienced developers who are already working on the project for a long time. Things really need to change around here.

(In reply to comment #50) > it is actually impossible to > start contributing without tutorship from experienced developers who are > already working on the project for a long time. Tutorship is what I see going on in comment 48, it wasn't a rejection. However if you disagree with that please feel free to discuss further with me by direct email rather than this bug where we're already off-topic.

Although I almost fell off my African chair in disbelief when reading the second part of Andrew's comment 48, you never know what we (or they) might overlook, so let's try to be co-operative and push this bug a little further by requesting UI-review as required by procedure, with detailed definition of and reasons for the requested behaviour. Jim, since you said "non-Mac", does Unix have Ctrl+F4 for closing tabs? Andrew, would you know where the code for Ctrl+W shortcut for closing tabs is currently hidden in the standard XUL command/key infrastructure? Looking at Magnus' comment 15, it doesn't seem easy to locate: > Ctrl+W is actually here: > http://mxr.mozilla.org/comm-central/source/mail/base/content > /utilityOverlay.xul#59 > ... but note those lines that it's only there for show :/ Tyler, did Gerv actually have a chance to hear your comment 34 (as I don't see him CC'ed)?

See how easy it is to overlook things (my bad), we actually already have an implicit UI-review+ in Bryan's comment #4: > wow, i never knew of that combo before and it's quite a stretch for my fingers > :) > That is a windows default keybinding *so we should pick it up as well*. This > should be an easy one for someone to add Gerv, as per Bryan's comment 15 ("This should be an easy one for someone to add"), and Tyler's comment 34: > could we get some assistance here?

(In reply to comment #51) > (In reply to comment #50) > > it is actually impossible to > > start contributing without tutorship from experienced developers who are > > already working on the project for a long time. > > Tutorship is what I see going on in comment 48, it wasn't a rejection. However > if you disagree with that please feel free to discuss further with me by direct > email rather than this bug where we're already off-topic. I appologize in advance for the off-topic then, but I really feel that everyone participating should read this, not just you. The problem I see from an angle of potential contributor is that the tutorship has happened 17 months after the bug has been reported, and we would probably not see it yet if it did not get the attention because of an ongoing debate. I did not say that comment #48 was a rejection -- what I am saying is that it is a further bureaucratization of a trivial issue that should have been resolved fixed long time ago. You should see that something is wrong when you are spending more time managing bugs, their duplicates, and "misbehaving" bugzilla users than you are spending actually fixing the damn thing.

@Thomas, yes I cc'ed him, he took it off two days later. Everything had calmed down a bit after I cc'ed him.

What about this way? It's about the easiest way possible, I suppose. Note that I didn't use goDoCommand('cmd_close') because that didn't work for some reason. I'm not actually entirely clear on how all these <key>s and <command>s interact with the platform bindings in core...

Comment on attachment 503486 [details] Request for UI-review for Ctrl+F4 to close an active tab Marking ui-review+ based on comment 4 for tracking purposes.

Comment on attachment 503643 [details] [diff] [review] The easy way It works if you do command="cmd_close". You'll find a command with id="cmd_close" in messenger.xul. By doing the command="cmd_close" the XUL thing links up with the command and so the key causes the JS associated with the command in its oncommand to be run. It so happens that the oncommand is also "CloseTabOrWindow();". goDoCommand would do something if the logic was in our JS file in our giant switch statement. I have to confess I'm not entirely clear on how it all works either, but I like to keep all the confusion clustered together which is why I was avoiding the event listener stuff :) r=asuth if you are cool with changing it to: <key id="key_close2" keycode="VK_F4" modifiers="accel" command="cmd_close"/> (the rationale again being, better to have only one spot where we are calling CloseTabOrWindow() rather than multiple spots.) Please double check that it works for you... I am going to give this a mozmill testing pass because this is a secret keybinding (not mentioned in the UI), is likely to quickly have a bug filed against it again if it regresses, and I fear the amount of effort required to get such a test working that does not intermittently orange.

This patch does what comment 58 says. r=asuth

Adding checkin-needed, since we don't need tests for this (see comment 58 again).

Checked in: http://hg.mozilla.org/comm-central/rev/fc10d866eed5

Can I just ask as an impudent outsider why I can't see ControlW in the fix, because all this is is an alternative keyboard shortcut to achieve the identical action?

(In reply to comment #62) > Can I just ask as an impudent outsider why I can't see ControlW in the fix, > because all this is is an alternative keyboard shortcut to achieve the > identical action? Because that's handled by platform code. It gets indirectly included by way of the "<key id="key_close"/>" line.