Closed Bug 158679 Opened 22 years ago Closed 16 years ago

Single character capital shortcut (N, F, P, B, T, M, R, C, I, J, W, S, K - star, watch, mark, next, previous, backward, unread,kill/ignore to name a few) fail in mail when caps lock (shift lock) is on, but command menu shows keys as upper case

Categories

(SeaMonkey :: MailNews: Message Display, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 295228

People

(Reporter: darren.fuller, Unassigned)

References

Details

(Keywords: access)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721
BuildID:    2002072108

Shortcut keys 
       N - Next Unread Message
       F - Next Message
       B - Previous Message
       P - Previous Unread Message
do not work if caps lock on

Reproducible: Always
Steps to Reproduce:
1. Open Mozilla mail
2. Turn CAPS LOCK on 
3. Hit shortcut key N, B, P, F

Actual Results:  nothing

Expected Results:  move to Next/Previous (Unread) message
Capital N isn't an Lowercase N.
Case sensitivity in code.

Confirming on 2002081813 [ Windows XP + Service Pack 1 ]
Status: UNCONFIRMED → NEW
Ever confirmed: true
This is definitively a "bug" that is happening often since the release of NS 7
final release. I heard it often in netscape.netscape7.windows newsgroup. I
believe this bug should be fixed before the next version/release of NS .

The shortcut key letters in the menus are uppercased. Access keys in the menus
work for uppercase letters and lowercase letters.

I suggest to add nsbranch+ keyword for this bug.
How about the situation of Linux and Mac, or windows only?
os->all, seeing this on linux current trunk cvs
OS: Windows 2000 → All
Perhaps this should be a separate bug, but on XP at least, the shortcut keys are
shown as uppercase but only work as lower case.  It should either show the
lowercase keys as the shortcut, or simply work for both.  It doesn't appear that
the uppercase versions are used for anything else, so I'd suggest just making
both work unless this produces havoc for international versions that have no
concept of uppercase/lowercase.
Severity: minor → normal
Keywords: access
*** Bug 199287 has been marked as a duplicate of this bug. ***
*** Bug 182354 has been marked as a duplicate of this bug. ***
My problem in this case is further expanded because I have alternative language
keyboard input installed. If I have switched to the alternative language (which
is often the case) I get the same result even with no caps lock on. I would like
to see this working more like [N], [F], etc. as keyboard position codes and not
character codes - just like Ctrl+N, Ctrl+U work no matter if I have caps lock on
and whatever input language is chosen for the keyboard... my platform is WinXP.
Problem seems to be intermittent on 2003070708 (Mac OS X) for both bare letter
and Cmd+letter keys.  But the cut/copy/paste keys seem to be consistently
failing at the moment.
Hardware: PC → All
*** Bug 227299 has been marked as a duplicate of this bug. ***
*** Bug 230143 has been marked as a duplicate of this bug. ***
*** Bug 243970 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20040910
Thunderbird version 1.0 (20041206)

With respect to Comment #9, I can reproduce this bug consistently in the Mozilla
1.7.3 and Thunderbird 1.0 releases on Mac OS X 10.3.5.
Assignee: sspitzer → mail
This is also a problem with Firefox, eg CMD-V to paste on OS X.
mod summary.
also fails for the addition of Go > Next > Unread Thread=t
comment 5 makes a good point about what's shown on the menu
Severity: normal → minor
QA Contact: olgam
Summary: Shortcut keys do not work if caps lock on → Single character shortcut keys (N, F, P, B, T) do not work in mail if caps lock (shift lock) is on
also impacts M, R, C, I, J
Summary: Single character shortcut keys (N, F, P, B, T) do not work in mail if caps lock (shift lock) is on → Single character shortcut keys (N, F, P, B, T, M, R, C, I, J) do not work in mail if caps lock (shift lock) is on, but command menu shows keys as upper case
Appears on latest Thunderbird nightly build, 20060119. Grumble!
*** Bug 327601 has been marked as a duplicate of this bug. ***
(In reply to comment #16)
> also impacts M, R, C, I, J
> 

Be careful here: shift can be used for similar or toggle function, for example 
(upper)shift J does mark 'non-junk'!
Folks, this bug is pretty much WONTFIX.

Traditionally, shortcut keys are shown in Upper Case in menuitems, with _all_ the needed modifier keys prepended. The case shown there simply has nothing to do with the case of a character shown when hit eg. a text processor! 
After all, do you whine at your keyboard manufacturer because all the keys labelled in upper case unsually generate lower case characters?

And caps lock is just an "always-on" shift key, so the the shortcuts MUST NOT work in this case! Disabling the caps lock = shift will create accessibility issues.
What about comment 8?


(In reply to comment #19)
> (In reply to comment #16)
> > also impacts M, R, C, I, J
> 
> Be careful here: shift can be used for similar or toggle function, for example 
> (upper)shift J does mark 'non-junk'!

That seems needless ... two keys where one would do.
Is that the only example?
(In reply to comment #20)
> And caps lock is just an "always-on" shift key, so the the shortcuts MUST NOT
> work in this case! Disabling the caps lock = shift will create accessibility
> issues.

Please be specific.  What are these accessibility problems?

(In reply to comment #21)
> > Be careful here: shift can be used for similar or toggle function, for
> > example (upper)shift J does mark 'non-junk'!
> 
> That seems needless ... two keys where one would do.

Wrong. Junk state is tri-state.

(In reply to comment #22)
> > Disabling the caps lock = shift will create accessibility issues.
> 
> Please be specific.  What are these accessibility problems?

Lamed people, for example, who can't hit more than one key at a time.

Blaming caps lock of locking caps is just so ridiculous...


 

(In reply to comment #23)
>>> Disabling the caps lock = shift will create accessibility issues.
>> 
>> Please be specific.  What are these accessibility problems?
> 
> Lamed people, for example, who can't hit more than one key at a time.

But:
- Without StickyKeys, they will not even be able to press Ctrl+C, etc, nor even type many characters.  So why should these shortcuts be any different?
- Somebody who can't use a certain keyboard shortcut can still access the command through the menus.
- Anybody who can't hit more than one key at a time is likely to have StickyKeys anyway (especially now that it's part of the accessibility support built into many OSs) and will therefore have no trouble whatsoever.
> - Somebody who can't use a certain keyboard shortcut can still access the
> command through the menus.

Well, that one speaks _against_ this bug...

> - Anybody who can't hit more than one key at a time is likely to have
> StickyKeys anyway

Okay, valid point.

You're carefully avoiding to answer my other point:
Why should the shift locking key (aka caps lock) NOT work as a shift key?
What would you tell people saying "my caps lock key doesn't do shift anymore!"?
(In reply to comment #25)
<snip>
> You're carefully avoiding to answer my other point:
> Why should the shift locking key (aka caps lock) NOT work as a shift key?
> What would you tell people saying "my caps lock key doesn't do shift anymore!"?

Because most of us are used to it having no effect on non-alphabetic characters.

It's also a common expectation that caps lock has no effect on shortcut keys.  What would the average person prefer: to be consistently able to press the shortcut key and be done with it, or to press the key, find it doesn't work, and ponder before discovering that caps lock has to be switched off?  I'd think the former.
(In reply to comment #25)
> 
> You're carefully avoiding to answer my other point:
> Why should the shift locking key (aka caps lock) NOT work as a shift key?

Caps lock has _never_ been equivalent to "shift lock."

> What would you tell people saying "my caps lock key doesn't do shift 
> anymore!"? 

That's just dumb. What happens in your keyboard when you have capslock on and you type digits or puntuation symbols? 
Okay, folks, you got me. :)
Even our browser part does it "right", as do other programs.
The Caps Lock issue is a MailNews bug then we should fix (but not the upper case letters in the menuitems).
Severity: minor → normal
Hm, these keys work for me in a Win2k SeaMonkey trunk debug build [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060304 SeaMonkey/1.5a], regardless of caps lock state!?!

Can someone of the plaintiffs ;-) confirm this?
*** Bug 333749 has been marked as a duplicate of this bug. ***
Thunderbird version 1.5.0.7 (20060909) on Mac OS X does occasionally accept keyboard shortcuts when caps lock is on, but most of the time it's a no-go. Single key commands like in the first message, and shortcuts using the Command key, like Command-W to close the active window, are affected. Very annoying.
Hm... this behavior has changed on the trunk -- SM1.5a-1209 and TB3a1-1215, under Windows 2000, both ignore CapsLock when processing the single-letter shortcuts.  CapsLock+J acts like J, not like Shift+J.
mod summary for searchability
Summary: Single character shortcut keys (N, F, P, B, T, M, R, C, I, J) do not work in mail if caps lock (shift lock) is on, but command menu shows keys as upper case → Single character capital shortcut (N, F, P, B, T, M, R, C, I, J, W, S, K - star, watch, mark, next, previous, backward, unread,kill/ignore to name a few) fail in mail when caps lock (shift lock) is on, but command menu shows keys as upper case
Marking fixed per Comment #32 and my own test of Thunderbird 3.0a1pre (2008042403) on Windows (at least J, Shift+J, S, and K work).
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Rimas, FIXED is not appropriate resolution unless you know the fixing bug, in which case duping to fixing bug might be good. see https://bugzilla.mozilla.org/page.cgi?id=fields.html#resolution  

Plus, even though Mike commented it works for him on windows, that was 1.5 yr ago. So someone should have tested tested SM again including Mac and linux. ajschult says WFM linux.  And SM windows trunk is still WFM. Think I saw some Mac bugs today that says it works there. So lacking a bug#, changing resolution to WORKSFORME.

[Unfortunately I can't find a fixing bug of mid to late 2006. Perhaps the fixing bug's summary isn't great - though bug 295228, bug 295095 are interesting.]
Resolution: FIXED → WORKSFORME
According to Comment #29 (which slipped through my eyes earlier), it was already working in trunk in March 2006. Hence, it seems you have to look at bugs fixed in early 2006 or even earlier, not in mid-to-late 2006.
It seems like bug 295228 could be the fixer. See bug 295228 comment 26. Bug 295228 comment 34 notes the fix was committed to trunk, but not to branch. Everything seems to fit. Wayne, what do you think?
Rimas, nice research. So this would have been fixed on trunk 2005-08-30 13:42:12 PDT.  And I'm inclined to agree, even though comment 17 would indicate otherwise. And comment 14 I think is a different bug. So duping. 
Resolution: WORKSFORME → DUPLICATE
The author of comment #17 doesn't specify if it's a branch nightly or trunk nightly, so if we assume it was branch, there's no conflict. :)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.