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)

Product:
Thunderbird
Component:
Mail Window Front End
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: jpd, Assigned: philor)

References

(Blocks 1 open bug)

Details

(Keywords: fixed1.8)

Attachments

(2 files)

remove single key access keys from the menu on mac os x
6.31 KB, patch
Bienvenu
: superreview+
Details | Diff | Splinter Review
unremove single key access keys from the menu on mac os x
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
*** 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.
Blocks: 106943
*** 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.
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.)
*** 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.
Depends on: 195979
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?
Assignee: sspitzer → mail
*** 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!
Assignee: mail → mscott
Component: MailNews: Main Mail Window → Mail Window Front End
Product: Mozilla Application Suite → Thunderbird
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.
Status: NEW → ASSIGNED
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.
Attachment #200406 - Flags: superreview?(bienvenu)
Attachment #200406 - Flags: superreview?(bienvenu) → superreview+
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.
Keywords: fixed1.8
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).
Blocks: 323276
Blocks: 333821
Blocks: 353583
QA Contact: esther → front-end
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.
Assignee: mscott → philringnalda
Attachment #294625 - Flags: superreview?(mscott)
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 :)
Attachment #294625 - Flags: superreview?(mscott) → superreview+
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
Removing cc...
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: