User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 This is very similar to bug 189093 and probably just another instance of the same thing. This probably only affects Macs. Under certain circumstances, you cannot type certain letters (f, n, t, b, p) in the quick search box in the mail/news 3-pane window. The letters do not appear, and instead you trigger menu item that has the corresponding keystroke shortcut. This only relates to the items in the "Go" menu, which do not require a modifier key (usually the command/apple key on a Mac) to be held down. Reproducible: Always Steps to Reproduce: 1. Open mail/news, and click on a message in the three-pane view. Focus must not be in the quick search box. 2. Tap on the "Go" --> "Next" menu, but do not select an item 3. Click in the quick search box and try to type the letter "n" Actual Results: The letter "n" does not get typed in the quick search box. The "Go --> Next --> Unread Message" menu item gets triggered.

Confirmed using FizzillaMach/2003032013.

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

This seems to be a duplicate report to bug 194147 ?

Guess so, though the two bug reports seem to give different stories. When I try (2003090303) W and R are among the letters that fail, but they seem to vary a bit.

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

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

See also bug 243958 -- same problem, different input field.

Confirmed with Thunderbird 1.0 Release NL and EN-US. Typing 'k' in the search box issues 'ignore thread' command. The same happens with all one key commands. (Workaround: always use command key modifier. That would also make TB more Aqua HIG compliant.)

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

Since this bug affects Communicator and Thunderbird identically, should it belong to Core:MailNews (Backend)? If not, either this or bug 194147 should be switched to target Thunderbird, so that both are covered.

Agreed on Core, but this problem is apparently Mac-only. Perhaps the right component is: Widget: Mac Is there any similar behavior in Firefox on the Mac? Or maybe in something like the JavaScript Debugger? Bug 194147 comment 4 states that the problem is the unmodified shortcuts -- K W M R J N P F B etc. I guess the browsers don't have any of those...?

Yes, Core:Widget:Mac does sound like the right place. And yes, every shortcut in Firefox Mac uses the Command (aka Apple) key. If shortcut keys need to be overloaded, the typical Apple method is to use the chord of Command-Option (aka Alt) keystroke. Assigning commands to unmodified alphabet keys is never done in standard desktop apps, only in fullscreen games and the like.

I dunno. I like having unmodified keys, particularly "n" for just going to the next message. N, n, n, n, ... There's got to be some way to disable matching of the menu key shortcuts while a text field has the highlight.

Oops, I was mistaken. One app that I use regularly has unmodified alpha shortcuts: Simon Fraser's MT NewsWatcher, which nicely enables/disables them depending on context and focus (and a pref to turn them on/off). Don't suppose Simon would like to take this bug? :)

(In reply to comment #13) > There's got to be some way to disable matching of the menu key shortcuts while a > text field has the highlight. Of course there is. It works most of the time in just about every build I've used. What's needed is a way to get it working all of the time.

Just thinking about it, one possibility to stop implementing these keys as shortcuts. Instead, we would process them in the regular keyboard handling of the MailNews window panes. Does this make sense to the way the panes/controls work?

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

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

I'm currently running OS X 10.3.9 and Thunderbird 1.0+ (20050719) and did not have any problems until I enabled "Sort by->Grouped by Sort" manually from the menu to test it out. After doing so, my "G" key became a hot-key when I'm in the searh box, so, I can't search by G (totally annoying!!!). I can use M without any trouble. I'm gonna try a new nightly build... Thanks!

Scott - this bug has a long history of dupes (of bugs with dupes, even). See bug 287000 for a simpler explanation of why this is a big problem. It can be really problematic on Macs, and it'd be too bad if 1.5 shipped with it. All you need to do is open a mailbox with a few messages in it, sort by Date (or anything that can be "Grouped by Sort"), select a message, then search in the search bar for a word with a "g" in it, like "urgent".

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

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

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

Is there some work-around for this? My wife is going nuts because she can't search her email effectively. :-)

This is also a problem in 1.5 beta 1, although it seems that an attempt has been made to deal with it. When Thunderbird is first booted, typing 'g' in the search box works as expected -- it types a 'g' in the search box. But, while the search box is empty, open the View -> Sort By menu (without clicking anything in there -- just run the mouse over it). After closing the menu, typing a 'g' in the search box will sort by group instead of typing a 'g'. This is on the Mac version of 1.5 beta 1.

I think this is a symptom of an underlying toolkit problem on Mac OS X. If I open up any menupopup that contains a menu item with a key binding on it (like mark read by date, go to next message, sort by grouped) then all non modified key bindings get messed up. What's even more bizzare is that the problem is only when the menu item references the actual key. If the menu looks like: <menuitem id="groupBySort" type="radio" name="group" key="key_groupBySort"...." You'll have the problem after opening that menu. If you just take out the key: <menuitem id="groupBySort" type="radio" name="group" everything works fine. Of course you don't see the key letter next to the menu item in the UI anymore. But the key still works. Totally bizzare.

One hack we could do to work around this for 1.5 is to #ifdef out the key commands on Mac OS X in the menus. The keys would still *work*, but you wouldn't see them in the menu. We'd sacrifice discoverability of the single key short cuts for allowing users to open up menus that reference these keys while still being able to type those keys into text fields. Not ideal, but it's unlikely that we would get approval for a toolkit level change to event handling / key binding.

I was able to reproduce this in the mozilla suite as well (10/21 trunk seamonkey build). The suite doesn't actually have a key for grouped by sort, but opening the Go menu keeps you from typing the characters FNBTP in the quick search bar. The principle is still the same. Oddly enough * and \ (expand all threads, collapse all threads) are the only two key commands which work even if you've opened the menu that cites them. For grins, I actually re-wrote a couple of these single key commands to go through the default mail 3 pane command upater (http://lxr.mozilla.org/seamonkey/source/mailnews/base/resources/content/mail3PaneWindowCommands.js#140) instead of acting on their own but to no avail. I wonder why * and \ still work but the rest don't. Very strange.

Had I followed all the various bugs closely enough I would have seen that simon commented in another bug saying: "The menus on Mac always get first crack at events." https://bugzilla.mozilla.org/show_bug.cgi?id=194147#c4 Bug 194147 has some more interesting comments.

this was 'fixed' in the browser a long time ago by implementing what I just suggested in comment 27. Bug 195830.

Not ideal. You won't have an easy way to discover that G puts you in grouped mode or that F goes to the next message, etc on the Mac. But by not showing the key in the menu, you won't get in a state where you can't type these characters into the quick search box which is pretty bad.

Hmm, just a thought: there's no way of disabling the relevant menus when the searchbox gets focus?

I forgot to say that this work around was in the trunk and the 1.8 branch. I'll leave the bug open in the hopes that we eventually figure out a way to fix this for fx and tb that doesn't involve removing the key from the menu item.

This problem is not restricted to the quick search box, but also happens when creating a new folder, specifying a password etc. I would vote for *any* solution as the current situation stops me from using TB on the Mac.

(In reply to comment #34) > This problem is not restricted to the quick search box, but also happens when > creating a new folder, specifying a password etc. I would vote for *any* > solution as the current situation stops me from using TB on the Mac. > The attachment in comment #31 should have fixed this as well (it's a work-around, though - that is why the bug is still open). Have you tried a recent build (a build made after the 27th of September)?

(In reply to comment #35) > ... Have you tried a > recent build (a build made after the 27th of September)? Yes I did, I tried version 1.0.7 which I downloaded 1 or 2 weeks ago.

piotr, this isn't a recent build. 1.5 or a nightly is a better choice.

Ah! Sorry for the confusion, I'll try it out...

I tried version 1.5 RC 1 (20051025) and yes, indeed the workaround does its job: I tried all scenario's I knew and it all works now. Thanks Stefan and Ray, for the fast responses.

Bug 194147 was fixed today, does that fix this also?

(In reply to comment #40) > Bug 194147 was fixed today, does that fix this also? > No, bug 194147 was worked-around with, basically, a seamonkey version of attachment #200406 [details] [diff] [review] in this bug. This bug is fixed in the way that the issue has been worked-around. But niether bug 194147 or this bug will be properly fixed until bug 195979 is fixed. Or, rather, when bug 195979 is fixed we can display single command-key characters in the mac menus (those are removed in order to work-around the issue).

I also have the problem with the J key in both the new folder creation dialog and in the address book notes field with the 2.0.0.6 (20070728) version.

(In reply to comment #43) > I also have the problem with the J key in both the new folder creation dialog > and in the address book notes field with the 2.0.0.6 (20070728) version. > See bug 333821.

And around we go again: as stefanh noted in bug 333821 comment 8 in September (and as I failed to note when I first looked at that bug in April), Widget:Cocoa redid menu key handling in a way that no longer triggers this, and between how long it's been working and the way that Josh didn't seem to imagine the current behavior as a possible problem when I asked whether it was likely to stay this way, I think it's safe (enough ;)) to put them back in.

Though I have to admit it's not too comforting that I went straight from claiming it will continue to work to reading bug 382138 comment 17.

Comment on attachment 294625 [details] [diff] [review] unremove single key access keys from the menu on mac os x it's great to finally fix this :)

mail/base/content/mailWindowOverlay.xul 1.229 Now to cross our fingers while chanting "stay fixed, stay fixed, stay fixed..."

Removing cc...