Closed Bug 186789 Opened 17 years ago Closed 16 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]
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.
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. firstname.lastname@example.org 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. ***
*** 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.
(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
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.
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.
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+
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+
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: 16 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?
*** 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.