Closed
Bug 199019
Opened 22 years ago
Closed 17 years ago
Typing some letters in quick-search box triggers menu selection
Categories
(Thunderbird :: Mail Window Front End, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: jpd, Assigned: philor)
References
(Blocks 1 open bug)
Details
(Keywords: fixed1.8)
Attachments
(2 files)
6.31 KB,
patch
|
Bienvenu
:
superreview+
|
Details | Diff | Splinter Review |
9.30 KB,
patch
|
mscott
:
superreview+
|
Details | Diff | Splinter Review |
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 4•21 years ago
|
||
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.
Blocks: 106943
Updated•20 years ago
|
Product: Browser → Seamonkey
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.)
Comment 10•20 years ago
|
||
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.
Depends on: 195979
Comment 11•20 years ago
|
||
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...?
Comment 12•20 years ago
|
||
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.
Comment 13•20 years ago
|
||
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.
Comment 14•20 years ago
|
||
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? :)
Comment 15•20 years ago
|
||
(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.
Comment 16•20 years ago
|
||
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?
Updated•20 years ago
|
Assignee: sspitzer → mail
Comment 19•19 years ago
|
||
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!
Assignee: mail → mscott
Component: MailNews: Main Mail Window → Mail Window Front End
Product: Mozilla Application Suite → Thunderbird
Comment 20•19 years ago
|
||
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".
Comment 24•19 years ago
|
||
Is there some work-around for this? My wife is going nuts because she can't search her email effectively. :-)
Comment 25•19 years ago
|
||
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.
Comment 26•19 years ago
|
||
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.
Comment 27•19 years ago
|
||
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.
Status: NEW → ASSIGNED
Comment 28•19 years ago
|
||
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.
Comment 29•19 years ago
|
||
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.
Comment 30•19 years ago
|
||
this was 'fixed' in the browser a long time ago by implementing what I just suggested in comment 27. Bug 195830.
Comment 31•19 years ago
|
||
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.
Attachment #200406 -
Flags: superreview?(bienvenu)
Updated•19 years ago
|
Attachment #200406 -
Flags: superreview?(bienvenu) → superreview+
Comment 32•19 years ago
|
||
Hmm, just a thought: there's no way of disabling the relevant menus when the searchbox gets focus?
Comment 33•19 years ago
|
||
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.
Keywords: fixed1.8
Comment 34•19 years ago
|
||
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.
Comment 35•19 years ago
|
||
(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)?
Comment 36•19 years ago
|
||
(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.
Comment 39•19 years ago
|
||
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.
Comment 41•19 years ago
|
||
(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).
Assignee | ||
Updated•18 years ago
|
QA Contact: esther → front-end
Comment 43•17 years ago
|
||
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.
Comment 44•17 years ago
|
||
(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.
Assignee | ||
Comment 45•17 years ago
|
||
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.
Assignee: mscott → philringnalda
Attachment #294625 -
Flags: superreview?(mscott)
Assignee | ||
Comment 46•17 years ago
|
||
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 47•17 years ago
|
||
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 :)
Attachment #294625 -
Flags: superreview?(mscott) → superreview+
Assignee | ||
Comment 48•17 years ago
|
||
mail/base/content/mailWindowOverlay.xul 1.229 Now to cross our fingers while chanting "stay fixed, stay fixed, stay fixed..."
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•