Closed Bug 186789 Opened 22 years ago Closed 20 years ago

Ctrl+Shift+[0-9a-f] Shortcuts in Mozilla conflict with ISO 14755 Input methods (shift+ctrl keys don't work) [mark all read]

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: yinbolian, Assigned: pkwarren)

References

Details

(Keywords: intl)

Attachments

(2 files, 2 obsolete files)

XPFE Patch v1
5.42 KB, patch
neil
: review+
alecf
: superreview+
Details | Diff | Splinter Review
Mailnews Patch v1
9.17 KB, patch
neil
: review+
mscott
: superreview+
Details | Diff | Splinter Review 
ISO 14755 use Ctrl+Shift+hex-digit to input unicode.
for example: Ctrl+Shift+c is used to mark all emails in a folder as "read", but
you can not use it with mozilla+gtk2, because gtk2 implemented ISO 14755 input
method.
What does ISO 14755 say for Mac -- Ctrl or Cmd?

Anyway, here's a chart for all of our accel+shift commands through A-F
(ctrl+shift on Unix/Win, Cmd+shift on mac). Composer doesn't appear to use any
of these bindings.

                 Browser content    Composer    Mail folder/thread panes

Accel+shift+A                                   Select folder
Accel+shift+C                                   Mark all messages read
Accel+shift+D    File bookmark
Accel+shift+f    Open search page               Search messages

We are using mozilla+gtk2 version. Robin found ctrl+shift+c cannot work.
I traced to find it is filtered out by gtk, in it comments ISO 14775 was
mentioned like this:

------------
/* In addition to the table-driven sequences, we allow Unicode hex
 * codes entered with Ctrl-Shift held down as specified in ISO
 * 14755. 14755 actually allows a different set of modifiers to be
 * used at our discretion, but for now using Ctrl-Shift as in their
 * examples. While holding Ctrl-Shift, pressing space commits the
 * character, and pressing a non-hex-digit is an error.
 */
------------

And I found the text about ISO 14755 at:
http://www-rocq.inria.fr/qui/Philippe.Deschamp/divers/ALB-CD.html
Summary: Ctrl+Shift Shortcuts in Mozilla conflit with ISO 14755 Input methods → Ctrl+Shift Shortcuts in Mozilla conflict with ISO 14755 Input methods
it is gtk2 related bug.
Blocks: gtk2
Seeing this on Mandrake gtk2 mozilla package
http://qa.mandrakesoft.com/show_bug.cgi?id=3139 which is XIM enabled..
Adding people who would have to change this.
Just do add more noise to this bug, we're also going to have to make sure that
shift-space isn't used for anything since that's the key that's used to activate
the IM to start doing preediting.
Don't even think of removing Shift+Space! the fix for Bug 79047 was the turning
point that made many long-time IE users (including myself) switch to Mozilla
full time. Well, this and Alt+D (Bug 157669)

Prog.
Relax.  We can leave it as shift-space on win32.
I also find Shift+Space useful on other platforms. steven-bugzilla@haryan.to
explained it very well:

"Shift-space for scrolling up is very convenient to me, where two
fingers of my left hand would stay at the Shift and the Spacebar to scroll a
page up and down, while my right hand stays at the mouse. No more lifting my
right hand to reach PgUp/PgDn keys"

See Bug 79047, Comment 35

Prog.

Yeah, I agree that it's convenient but it conflicts with a system keybinding. 
NN 4.x had delete as the page up key, I would suggest that we do the same.
I'm not sure that Shift+Space is a compulsory "beginning sequence". Here are a
couple of excerpts from ISO 14755:

"...If, with this method, an option for successive multiple character entry is
provided by a conforming system or application, then it is recommended that the
SPACE BAR should be used..."
-and-
"...In the following examples, it is assumed here that the beginning sequence
consists in the combined use of keys Level 2 Select and Control...."

If I'm getting this right, both Shift (Level 2) *and* Control are required,
while "SPACE BAR" is merely a recommendation. Now that doesn't look like
something that must collide with Shift+Space, does it?

> "NN 4.x had delete as the page up key, I would suggest that we do the same."

For a moment I almost thought that you were serious... please use a winkie next
time ;-)

Prog.
BTW, the above excerpts were taken from this link:

ISO/IEC JTC1/SC18/WG9 N1651 (13 December 1996)
http://www.cl.cam.ac.uk/~mgk25/volatile/ISO-14755.pdf

This copy is newer than the version linked in Comment 2:
ISO/IEC JTC1/SC18/WG9 N1522 (16 October 1995)

Prog.
I'm totally serious.
Actually, it occurs to me that you can probably leave the binding for
shift-space in.  People using kinput2 in ja_JP will just never see it, that's all.
*** Bug 204425 has been marked as a duplicate of this bug. ***
Any movement here?  We need to come up with new keybindings here.
Chris, I don't think we t need new keybindings for all of items I listed in
comment 1.

ALl of those items are also available in menus, which makes it a two key sequence.
For example, file bookmark can also accomplished by hitting Alt+B F. This is
still only 3 keys, just like Ctrl+Shift+F.

I don't know why the keys aren't working for unicode entry in Mozilla, but
Bolian says in comment #3 that it is a gtk2 related bug. Bolian, are you saying
that the bug is not in Mozilla at all?
*** Bug 189190 has been marked as a duplicate of this bug. ***
Gtk2's default input method grabs alt-[0-9] and alt-[a-f] so you can input
unicode characters using their code.
Summary: Ctrl+Shift Shortcuts in Mozilla conflict with ISO 14755 Input methods → Ctrl+Shift Shortcuts in Mozilla conflict with ISO 14755 Input methods (shift+ctrl keys don't work)
On this very page, if I type Alt-B F it doesn't open the Bookmarks menu, it
jumps to the "Bug 186789 blocks" text widget near the top of the page and
highlights the "92033" text in it.

Maybe an alternative would be having programmable keyboard shortcuts.
> On this very page, if I type Alt-B F it doesn't open the Bookmarks menu, it
> jumps to the "Bug 186789 blocks" text widget near the top of the page and
> highlights the "92033" text in it.

Bugzilla pages use HTML accesskeys, which allow a webpage to create Alt+letter
shortcuts to fields. On pages like Bugzilla, you will have to type Alt or F10 by
itself first, to get to the menu bar, then B then F.
*** Bug 211575 has been marked as a duplicate of this bug. ***
*** Bug 212749 has been marked as a duplicate of this bug. ***
If the solution proposed in #17 (let them use alt-B F) is to be
adopted, the advertised shortcuts in the menus will need to be 
changed or removed (eg "File Bookmark...  Ctrl+Shift+D").

I would not be happy with that however, conflicting as it does 
with years of finger learning and the HTML accesskeys (comments #20 
and #21).  

Should I be raising this with the GTK people?

What about having user defined keyboard shortcuts? 

There are a lot more collisions then anybody really thinks, since usually your
window manager also has keyboard accelerators and anything a person hard codes
in is bound to collide with someone else's user preferences.

I think you should have defaults and let the users redefined them. 

There's already more than enough code base for this. Even lightweights like
Metacity or Gnome-Terminal allow user defined keyboard accelerators.
*** Bug 216677 has been marked as a duplicate of this bug. ***
adding [mark all read] to summary to catch a few ctrl+shift+c-dupes.
Summary: Ctrl+Shift Shortcuts in Mozilla conflict with ISO 14755 Input methods (shift+ctrl keys don't work) → Ctrl+Shift Shortcuts in Mozilla conflict with ISO 14755 Input methods (shift+ctrl keys don't work) [mark all read]
*** Bug 213732 has been marked as a duplicate of this bug. ***
*** Bug 212974 has been marked as a duplicate of this bug. ***
*** Bug 220078 has been marked as a duplicate of this bug. ***
*** Bug 223010 has been marked as a duplicate of this bug. ***
btw, this bug makes crtl+shift+c not work in linux thunderbird v0.3
*** Bug 227892 has been marked as a duplicate of this bug. ***
*** Bug 216874 has been marked as a duplicate of this bug. ***
*** Bug 223455 has been marked as a duplicate of this bug. ***
*** Bug 172130 has been marked as a duplicate of this bug. ***
*** Bug 229245 has been marked as a duplicate of this bug. ***
Given the number of duplicate, I would suggest to make something about this and
at least :
1) Provide alternative bindings for vital CTRL-ALT-[A..Z] functions,
2) When compiling with GTK2, fix the menu to describe the actual correct bindings

I guess the firebird and thunderbird best will suffer from the very same problem
as they use GTK2...
*** Bug 230631 has been marked as a duplicate of this bug. ***
You should be aware this bug isn't always related to the code.  On my Toshiba
Tecra S1 laptop, pressing Ctrl-Right shift-A will select all emails in the
current thread, but using the left shift is ignored.  If I plug in an external
keyboard both right- and left-shift work with Ctrl-A.  And if I use xev (under
Linux) pressing, in order, right shift + ctrl + A gives me output as each key is
pressed, but doing so with the left shift key gives me output upon pressing
shift and ctrl, but no output when pressing the A.
*** Bug 232414 has been marked as a duplicate of this bug. ***
Keywords: intl
*** Bug 233269 has been marked as a duplicate of this bug. ***
Does this limitation also prevent Ctrl+Shift+D from being used for "File
Bookmark..."?

I can't test this myself at the moment, but if indeed it doesn't work, then it's
a big limitation and a very good reason to bind this function to Ctrl+D instead
(after all, the current promptless "Bookmark This Page" is quite useless for
most people.)

Prog.
re: comment 38
I agree that the best short-term solution for this is to allow user remappings
of the affected keys, at least those ones that are defined. Not it is only
Ctrl-A-F, not A-Z. The list of keys is in Comment 1.
Then a default prefs file for gtk2 builds could override those keys...
*** Bug 233938 has been marked as a duplicate of this bug. ***
Will the XUL front-end even get to see the Ctrl+Shift+letter keystrokes? Will it
only see them when the user's not entering text, but in another widget?

Looking back at comment 1 where the actual 5 conflicts are listed.

1. Ctrl+Shift+D in browser (file bookmark): I agree with Comment 43 -- in the
Seamonkey browser we can get rid of the promptless add bookmark and replace it
with file bookmark. That makes Seamonkey more consistent with Firefox anyway.
2. Ctrl+Shift+F in browser (open search page) -- I think we can just get rid of
that.
3. Ctrl+Shift+A in mail (select thread): we can leave Ctrl+Shift+A as it is
since there is no text input context where it does anything.
4. Ctrl+Shift+C in mail (mark all as read). There is a conflict when this is
used in the quick search text entry field. We could change this one to Ctrl+Shift+M.
5. Ctrl+Shift+F in mail (search messages): there is a conflict when in quick
search. We could disable this keystroke in quick search or change the key. If
Mozilla doesn't even see the keystroke when the user's in a textfield, we don't
have to do anything for this key. If Mozilla doesn't ever see the keystroke
we'll have to choose a different shortcut. I suggest Ctrl+Shift+S.

The next part of the fix would be to update docs here:
http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html
and 
http://www.mozilla.org/projects/ui/accessibility/accessible-xul-authoring.html

Finally, perhaps think we'd need a way to assert or warn authors who try to use
these keys in XUL apps.
Blocks: aix-access
(In reply to comment #46)
> Will the XUL front-end even get to see the Ctrl+Shift+letter keystrokes? Will it
> only see them when the user's not entering text, but in another widget?
> 

It looks like (based on bug 239483) we'll never see these keystrokes, no matter
where the input focus is.

ctrl-shift-[a-f] are used as part of the default character input method in gtk2.
 So, no.  You won't see them.  (a-f are part of unicode sequences.)
Since we'll never see the keystrokes, I am advocating this set of fixes:

Browser:
1. Accel+Shift+D (file bookmark): make Accel+D file bookmark, to be consistent
with firefox. The current promptless Accel+D goes away.
2. Accel+Shift+F (open search page): don't do anything to this. If it doesn't
work under Linux/UNIX, no real loss.

Mail:
3. Accel+Shift+A (select thread): change to Accel+Shift+H
4. Accel+Shift+C (mark all as read). change to Accel+Shift+M.
5. Accel+Shift+F (search messages): change to Accel+Shift+S.

Note, I'm using the word "Accel" instead of "Ctrl" because it indicates that Cmd
is used on OS X.
Assignee: aaronleventhal → hhoetzel
Attached patch Patch v1 (obsolete) — — Splinter Review 
Implements Aaron's suggestions from comment 49.
Assignee: hhoetzel → pkw
Status: NEW → ASSIGNED
Attachment #146211 - Flags: review?(neil.parkwaycc.co.uk)
Surely changing Search from Ctrl+Shift+F to Ctrl+Shift+S but only for mail, will
only confuse users?

Also, how about simply swapping Ctrl+D and Ctrl+Shift+D so that non-gtk2 users
will still get the benefit of add bookmark immediately?
> Surely changing Search from Ctrl+Shift+F to Ctrl+Shift+S but only for 
> mail, will only confuse users?
The Ctrl+Shift+F advanced search command is only used in mail. I don't
understand how users would be confused.

> Also, how about simply swapping Ctrl+D and Ctrl+Shift+D so that non-gtk2 
> users will still get the benefit of add bookmark immediately?
I like that, good idea.
I would like to earnesty lobby for soft keybindings as 
advocated by Josh in comment #25:

> What about having user defined keyboard shortcuts? 
> I think you should have defaults and let the users redefined them. 

There are probably many different ways to do this, but given the
flexibity in the Mozilla platform with XUL it is difficult
to imagine justifying hardcoding anything related to the UI.

Given the complexity of interaction between X and input methods, 
Window Managers and applications, especially in an international
context, soft bindings are likely the only way to truly resolve this
problem.  All shortcuts should be soft.  For extra credit the 
"shortcut editor" should display all bindings and
let user's try key combinations (to see if they are received by
Mozilla) before clicking OK or Cancel. It should be easy to
find out if a key is bound, and if so to which function (like the emacs 
function C-H k = describe-key).  It should also be easy to find out
which shortcut(s) are bound to a given function (like the emacs function
C-H w = where-is).

Menus should always reflect current shortcut bindings.
Comment on attachment 146211 [details] [diff] [review]
Patch v1

ok, so can you swap ctrl+d and ctrl+shift+d instead and for a bonus change
browser's ctrl+shift+f to ctrl+shift+s too.
Attachment #146211 - Flags: review?(neil.parkwaycc.co.uk) → review-
(In reply to comment #53)
> I would like to earnesty lobby for soft keybindings as 
> advocated by Josh in comment #25:
Different bug -- bug 57805
A lot of people want that, but no one seems to be willing to do the work.

I will support you if you decide to tackle it.
Attached patch Patch v2 (obsolete) — — Splinter Review 

        Attachment #146211 -
        Attachment is obsolete: true

    
  

        Attachment #146850 -
        Flags: review?(neil.parkwaycc.co.uk)

    
    

    
  
I think if we want to keep the Ctrl+Shift+D shortcut for "Bookmark this Page",
we should think about removing it from GTK2 builds, or reassigning it to a
shortcut which will work with GTK2. Since "Bookmark this Page" is a silent
operation, I'm sure people will be surprised when typing it does not actually
bookmark the page.

    
    

    
  
(In reply to comment #57)
> Since "Bookmark this Page" is a silent
> operation, I'm sure people will be surprised when typing it does not actually
> bookmark the page.

How about notifying them that the shortcut was changed, the first time this
keybinding is pressed? as much as dialog boxes are frequently ignored, they're
still much more likely to be read than readme files.

Prog.

    
    

    
  
(In reply to comment #58)
> How about notifying them that the shortcut was changed, the first time this
> keybinding is pressed?

uh, isn't the problem that mozilla never sees a ctrl+shift+d key, so it can't do
anything in response to it?

    
    

    
  
I've had second thoughts on select thread. Notice that on Linux Ctrl+A is used
for beginning of line and therefore unavailable for select all, which gets
bumped to Alt+A. I would therefore like to suggest that select thread be made
Alt+Shift+A on linux. It would appear that we could define the keybinding in the
existing platformMailnewsOverlay.xul to achieve this.

As for Ctrl+Shift+D we could just not support this keybinding on unix, this time
by defining it in platformNavigationBindings.xul.

Of course in each case the original xul file would still contain a stub
reference to the keybinding to pull it in from the overlay.

    
  

        Attachment #146850 -
        Flags: review?(neil.parkwaycc.co.uk)

    
  

        Attachment #146850 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        XPFE Patch v1
        — 
          — Splinter Review
      

    


  
I have split this patch up into mailnews/xpfe versions so they can be reviewed
by the appropriate people.

    
  

        Attachment #149857 -
        Flags: review?(neil.parkwaycc.co.uk)

    
    

    
  


  
This patch does the following:

- Changes select thread from Ctrl+Shift+A to Alt+Shift+A on Unix platforms.
- Changes mark all read from Ctrl+Shift+C to Ctrl+Shift+M on all platforms.
- Changes search messages from Ctrl+Shift+F to Ctrl+Shift+S on all platforms.
- Updates the Makefiles to allow building the a separate
platformMailnewsOverlay.xul file for Unix. Previously all non-Mac platforms
used the Windows platformMailnewsOverlay.xul file.

    
  

        Attachment #149870 -
        Flags: review?(neil.parkwaycc.co.uk)

    
    

    
  
Comment on attachment 149870 [details] [diff] [review]
Mailnews Patch v1

Just scanned this quickly but I think it might be an idea to remove the
existing references to platformMailnewsOverlay.xul

    
    

    
  
Comment on attachment 149870 [details] [diff] [review]
Mailnews Patch v1

>-  <key id="key_selectThread" key="&selectThreadCmd.key;"             oncommand="goDoCommand('cmd_selectThread');" modifiers="accel, shift"/>
>+  <key id="key_selectThread" key="&selectThreadCmd.key;" oncommand="goDoCommand('cmd_selectThread');" modifiers="accel, shift"/>
r=me if you omit this whitepsace change and remove the existing overlay
references to platformMailnewsOverlay.xul

        Attachment #149870 -
        Flags: review?(neil.parkwaycc.co.uk) → review+

    
  

        Attachment #149857 -
        Flags: review?(neil.parkwaycc.co.uk) → review+

    
  

        Attachment #149870 -
        Flags: superreview?(mscott)

    
  

        Attachment #149857 -
        Flags: superreview?(alecf)

    
    

    
  
Philip, I tested this on Windows at it looks good.

    
    

    
  
Comment on attachment 149870 [details] [diff] [review]
Mailnews Patch v1

sr=mscott assuming you address Neil's requests.

        Attachment #149870 -
        Flags: superreview?(mscott) → superreview+

    
    

    
  
Comment on attachment 149857 [details] [diff] [review]
XPFE Patch v1

sr=alecf

        Attachment #149857 -
        Flags: superreview?(alecf) → superreview+

    
    

    
  
Comment on attachment 149857 [details] [diff] [review]
XPFE Patch v1

sr=alecf

    
    

    
  
Fixed (with Neil's comments addressed). Thanks for the reviews.

Checking in mailnews/jar.mn;
/cvsroot/mozilla/mailnews/jar.mn,v  <--  jar.mn
new revision: 1.74; previous revision: 1.73
done
Checking in mailnews/base/Makefile.in;
/cvsroot/mozilla/mailnews/base/Makefile.in,v  <--  Makefile.in
new revision: 1.18; previous revision: 1.17
done
Checking in mailnews/base/resources/content/Makefile.in;
/cvsroot/mozilla/mailnews/base/resources/content/Makefile.in,v  <--  Makefile.in
new revision: 1.35; previous revision: 1.34
done
Checking in mailnews/base/resources/content/mail3PaneWindowVertLayout.xul;
/cvsroot/mozilla/mailnews/base/resources/content/mail3PaneWindowVertLayout.xul,v
 <--  mail3PaneWindowVertLayout.xul
new revision: 1.100; previous revision: 1.99
done
Checking in mailnews/base/resources/content/mailWindowOverlay.xul;
/cvsroot/mozilla/mailnews/base/resources/content/mailWindowOverlay.xul,v  <-- 
mailWindowOverlay.xul
new revision: 1.274; previous revision: 1.273
done
Checking in mailnews/base/resources/content/messageWindow.xul;
/cvsroot/mozilla/mailnews/base/resources/content/messageWindow.xul,v  <-- 
messageWindow.xul
new revision: 1.76; previous revision: 1.75
done
Checking in mailnews/base/resources/content/messenger.xul;
/cvsroot/mozilla/mailnews/base/resources/content/messenger.xul,v  <--  messenger.xul
new revision: 1.252; previous revision: 1.251
done
Checking in mailnews/base/resources/content/mac/jar.mn;
/cvsroot/mozilla/mailnews/base/resources/content/mac/jar.mn,v  <--  jar.mn
new revision: 1.4; previous revision: 1.3
done
RCS file: /cvsroot/mozilla/mailnews/base/resources/content/unix/jar.mn,v
done
Checking in mailnews/base/resources/content/unix/jar.mn;
/cvsroot/mozilla/mailnews/base/resources/content/unix/jar.mn,v  <--  jar.mn
initial revision: 1.1
done
Checking in mailnews/base/resources/content/unix/platformMailnewsOverlay.xul;
/cvsroot/mozilla/mailnews/base/resources/content/unix/platformMailnewsOverlay.xul,v
 <--  platformMailnewsOverlay.xul
new revision: 1.5; previous revision: 1.4
done
RCS file: /cvsroot/mozilla/mailnews/base/resources/content/win/Makefile.in,v
done
Checking in mailnews/base/resources/content/win/Makefile.in;
/cvsroot/mozilla/mailnews/base/resources/content/win/Makefile.in,v  <--  Makefile.in
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/mailnews/base/resources/content/win/jar.mn,v
done
Checking in mailnews/base/resources/content/win/jar.mn;
/cvsroot/mozilla/mailnews/base/resources/content/win/jar.mn,v  <--  jar.mn
initial revision: 1.1
done
Checking in mailnews/base/resources/locale/en-US/messenger.dtd;
/cvsroot/mozilla/mailnews/base/resources/locale/en-US/messenger.dtd,v  <-- 
messenger.dtd
new revision: 1.188; previous revision: 1.187
done
Checking in xpfe/browser/resources/content/navigatorOverlay.xul;
/cvsroot/mozilla/xpfe/browser/resources/content/navigatorOverlay.xul,v  <-- 
navigatorOverlay.xul
new revision: 1.296; previous revision: 1.295
done
Checking in xpfe/browser/resources/content/mac/platformNavigationBindings.xul;
/cvsroot/mozilla/xpfe/browser/resources/content/mac/platformNavigationBindings.xul,v
 <--  platformNavigationBindings.xul
new revision: 1.12; previous revision: 1.11
done
Checking in xpfe/browser/resources/content/win/platformNavigationBindings.xul;
/cvsroot/mozilla/xpfe/browser/resources/content/win/platformNavigationBindings.xul,v
 <--  platformNavigationBindings.xul
new revision: 1.17; previous revision: 1.16
done
Checking in xpfe/browser/resources/locale/en-US/navigator.dtd;
/cvsroot/mozilla/xpfe/browser/resources/locale/en-US/navigator.dtd,v  <-- 
navigator.dtd
new revision: 1.174; previous revision: 1.173
done
Checking in xpfe/browser/resources/locale/en-US/mac/platformNavigationBindings.dtd;
/cvsroot/mozilla/xpfe/browser/resources/locale/en-US/mac/platformNavigationBindings.dtd,v
 <--  platformNavigationBindings.dtd
new revision: 1.2; previous revision: 1.1
done
Checking in xpfe/browser/resources/locale/en-US/win/platformNavigationBindings.dtd;
/cvsroot/mozilla/xpfe/browser/resources/locale/en-US/win/platformNavigationBindings.dtd,v
 <--  platformNavigationBindings.dtd
new revision: 1.2; previous revision: 1.1
done
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED

    
    

    
  
Cmd-Shift-M used to be the New-Mail-Shortcut on Mac. What will be the new one?
Cmd-M, as on other platforms would be awkward, as Cmd-M is Minimze in
OS-X-Applications. So far no Mozilla-App except Camino is implementing Cmd-M and
Thunderbird even maps Cmd-M to New Mail, but this is what's bug 137523 is for.

    
    

    
  
mmm. should I expect these changes to have had any effect on Thunderbird? It
seems they haven't.

    
    

    
  
I don't understand why you replaced only the character. When reading this bug,
the prob seems to be related to the Ctrl-Shift, not to the characters

and.. the idea to use "m" instead of "c".... bad idea.. 

now it's not possible for me to mark groups easily as read. with "c" it was "a
dream" ;-)
and...

n = next message
ctrl-shift-n = composer
ctrl-m = new message

sorry.. now I see a lot of things I wont to see. I'm hitting the wrong keys.. 
e.g. going through a NG with "n".. then hitting Ctrl-shift.. I often use "n" as
third key, instead of "m"

Don't know...but on the right side of the keyboard I find a lot of key
combinations near the changed combination

and why to use "s" instead of "f"... every tool I know uses "f" for searching
(=find). IIRC it was the same under linux (at the moment I have no linux installed).

about key combinations of other systems I can't say anything. So please tell me,
what are the standards on them. but I asume the were same in some cases

    
    

    
  
Frank, comment 0 says what the problem is (was):
> ISO 14755 use Ctrl+Shift+hex-digit to input unicode.

(Tweaking summary.)
Summary: Ctrl+Shift Shortcuts in Mozilla conflict with ISO 14755 Input methods (shift+ctrl keys don't work) [mark all read] → Ctrl+Shift+[0-9a-f] Shortcuts in Mozilla conflict with ISO 14755 Input methods (shift+ctrl keys don't work) [mark all read]

    
    

    
  
aahh.. now, sory.. I was standing on the wire ;-) A-F are HexCodes. I was only
thinking about Strg-Alt-[0-9][0-9][0-9]. Sorry

But...
Understanding this won't change my opinion about the chosing of the new letters
;-) Something near the olders I would have preferred... or if I remember
correctly.. Strg-Shift-"m" was long ago "Ctrl-c". Ok... It'is past.  One must
accustom himself at it

    
    

    
  
is there any way the old shortcuts can be put into place as alternate bindings?
(so both will map to the same actions). That way users who have trained
themselves on shortcuts like ctrl+shift+c and ctrl+shift+d, etc. will not be
thinking that their system is just lagging before they realize that the
keybindings have silently changed on them. This should not cause any breakage.
For those where the keybindings didn't work, they won't be received by Moz, so
no harm done. For those where the keybindings did work, they'll continue to work
just finw

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
It should be noted that there still seems to be a lot of code in the codebase to
make it possible to change the accel key to be alt instead of ctrl also in the
Unix environment. The MS-Windows choice of using ctrl has always been pretty
stupid, as it makes it difficult to enter characters like ctrl+c from terminal
programs etc. for no good reason at all.

The magic invocation in prefs.js is of course:
user_pref("ui.key.accelKey", 18);
user_pref("ui.key.menuAccessKey", 0);

Unfortunately in some spots coders seem to have been a bit careless with these,
and for example in message composition both alt+v and ctrl+v seem to be mostly
usable. Seems the browser branches no longer support this at all. Either clean
up bits like this, and make the thing well-documented and customizable from the
user preferences, or then get rid of the whole mess once and for all!

    
    

    
  
Is this the bug that changed the browser's "Search the Web" hot key from
CTRL+SHIFT+F in Moz 1.7.3 and earlier to CTRL+SHIFT+S in 1.8a?

    
    

    
  
exactly. :-(

    
    

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

    
    

    
  
Unless I'm missing something, there is still a bug here.  I'm running the binary
Thunderbird 0.9 build from www.getfirefox.com and pressing Alt-Shift-A does not
select a thread as suggested below, nor does Ctrl-Shift-S bring up the search
box (neither does anything).

    
    

    
  
Yup, this bug has only fixed things in mozilla - this is a mozilla bug. There
needs to be a separate bug for the fix in Thunderbird. Not sure if there is one.

    
    

    
  
Re: comment #87

Note that bug 269228 has now been filed on the analogous issue for Thunderbird
(where it apparently affects only Ctrl+Shift+A "Select Thread").

    
    

    
  
(Answer to comment #51:)

By all means: leave the accellerator Ctrl-D for "Bookmark This Page" (without
Dialog!)

When making lots bookmarks, pressing "ok" for every new bookmark is very annoying.


I don't know who made the change in Mozilla 1.8 alpha 6 (or earlier) but that
has to be changed to the _original behaviour_ (or at least with a
configure-option in about:config) 
(Mozilla 1.8alpha6 has Ctrl-D as File Bookmark and Ctrl-Shift-D as Bookmark this
Page)

Related bugs:

bug 160461

    
    

    
  
*** Bug 306174 has been marked as a duplicate of this bug. ***
Component: Keyboard: Navigation → User events and focus handling

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: