User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_7; en-US) AppleWebKit/531.3 (KHTML, like Gecko) Chrome/3.0.192 Safari/531.3 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090223 Lightning/1.0pre Thunderbird/3.0b2 While composing an email, I can't use Control+A to go to the beginning of the line (in either the To: field, Subject, or body of the email. Mac OS X uses, by default, some emacs-style keybindings and many users are used to these keybingings. Worse: When I press Control+A it performs the "Add to To:" action, which adds any selected contact in the address book to the To: field (as usually happens). Reproducible: Always Steps to Reproduce: 1.click Write. 2.start writing an email address. 3.press Control+A to correct some mistake in the email. Actual Results: If there was any contact selected in the address book, it gets added Expected Results: The cursor should go to the beginning of the line. This is a security problem. Some emails may go to addresses they shouldn't go! A major feature (OS integration) is completely broken!
This isn't a security issue that needs to be kept confidential - presumably you want more people looking at this problem, not just the restricted group with security clearance.
WFM Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:188.8.131.52pre) Gecko/20090715 Shredder/3.0b3pre
It probably works for you because you missed the invisible "Step 1.5: View - Contacts Sidebar"
(In reply to comment #3) > It probably works for you because you missed the invisible "Step 1.5: View - > Contacts Sidebar" Indeed. How did you figure that out ?
(In reply to comment #3) > It probably works for you because you missed the invisible "Step 1.5: View - > Contacts Sidebar" Indeed, I didn't write that... Because after I set it once it always appears... And I forgot to warn you :-)
Typically, and virtually since day one on the Mac, Command-A as meant "Select All", and has nothing to do with the Emacs key binding for going to start of line. Of Much more relevance in many Mac apps is the inconsistent use of the Home and End buttons on larger Mac and USB keyboards for PC's, I can only suppose because Command (left/right arrow) are traditional bindings for start<->end line, etc. Use Aquamacs for good Mac integration with Emacs bindings, IMHO Home and End should not be abandoned altogether by Mac developers, or other useful PC conventions, even if they are redundant of the Mac traditions as there is a lot of hardware mixing today and Mac could use more PC-familiar users, too.
(In reply to comment #6) > Typically, and virtually since day one on the Mac, Command-A as meant "Select > All", and has nothing to do with the Emacs key binding for going to start of > line. Why are you talking about Command-A? The bug mentions the keybinding Control-A, which, by default, does the same as in emacs, when used in any Cocoa text field. Several emacs keybindings are available like this: http://www.hcs.harvard.edu/~jrus/Site/System%20Bindings.html (look near the end of the page, before the keyboard pictures), including moving, deleting, and yanking shortcuts. > Of Much more relevance in many Mac apps is the inconsistent use of the Home and > End buttons on larger Mac and USB keyboards for PC's, I can only suppose > because Command (left/right arrow) are traditional bindings for start<->end > line, etc. Use Aquamacs for good Mac integration with Emacs bindings, IMHO Home > and End should not be abandoned altogether by Mac developers, or other useful > PC conventions, even if they are redundant of the Mac traditions as there is a > lot of hardware mixing today and Mac could use more PC-familiar users, too. Yes, the home/end inconsistency is not very good (although, on the mac platform, þe home/end keys should go to the beginning/end of the text (not the line)), but it doesn't bother me much… I'm using C-a and C-e to move in a line… Also, Aquamacs is NOT a good integration… unless you only type in English and use an English/US keyboard… Aquamacs either: Hijacks my command key and I don't get Apple shortcuts (or don't get some emacs shortcuts), by using command as meta; or it hijacks my Alt key and I can't type some characters or diacritics when writing in a language other than English… That's not very good… At least Cocoa Emacs can use only emacs shortcuts (plus any Apple shortcut I configure in my .emacs file).
This bug should be retitled "Contacts Sidebar hijacks Ctrl-A keybinding in Compose window" - and that's certainly a bug in my book, FWIW.
This should be evaluated, and then fixed or closed as required. wfm on WinXP/Trunk, but is reported against MAC OS. For STR, remember to open sidebar AND select some contact(s), then refocus body editor and press Ctrl+A on MAC OS. On windows, it works as designed that ALT+A works as an accesskey to add recipients from sidebar, even with focus in composition. I think reporter is complaining that the same should NOT happen when hitting Control+A on MAC, because Control+A should delete characters from body or such (whatever the keys are there, and what they are supposed to do, I don't know).
Complete, reduced STR On MAC OS only: 1.1 Click Write to compose a new message 1.2 View Contacts Side bar 1.3 Select at least one contact in Contacts Sidebar. 2. Type "foo" into message body (cursor now after "foo"); applies to any text input fields (recipients, subject, body, etc). 3. Press Control+A (Ctrl+A) (Pls note the difference between "Control" and "Command" keys on MAC OS keyboards!) Actual Results: - Any contact selected in Contacts Sidebar unexpectedly gets added, violating user privacy! Expected Results: - Cursor should move to the beginning of the line (before "foo") (platform ux-consistency, ux-error-prevention) :Dossy, can you reproduce this on MAC OS?
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 Confirming that I can reproduce using documented STR. It appears the issue is that the accesskey scope appears to be the entire parent messengercompose.xul window, not just the abContactsPanel.xul pane. Per https://dxr.mozilla.org/comm-central/source/mail/components/addrbook/content/abContactsPanel.xul#143-165, this bug is larger than just the documented Ctrl-A triggering the "Add to To:" button event, but Ctrl-C will trigger the "Add to Cc:" button, and Ctrl-B will trigger the "Add to Bcc:" button. Interestingly, I found this document, https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/XUL_Accesskey_FAQ_and_Policies which even mentions: > Are there any crucial bugs I should know about? > > bug 143065 - Scope of accesskeys is not limited to the current tab panel. Now, that bug is marked RESOLVED/FIXED. I did a quick search of Bugzilla and couldn't find any related bugs about accesskey scope being too broad (window level vs. restricted to the embedded XUL pane) -- I apologize if I failed to search hard enough. I feel this bug is much larger than the specific functionality being complained about here, in that there should (must) be a way to specify the scope of an accesskey, whether it's window-level, tabpane level, or even inside of vbox#sidebar-box. I don't know if having addSelectedAddresses() in https://dxr.mozilla.org/comm-central/source/mail/components/addrbook/content/abContactsPanel.js#56-63 returning false will trigger a "bubbling up" of the accesskey to the parent window's accesskey or not, but if it does, then I suppose you could try and test for keyboard focus inside that function and if the focus isn't within the vbox#sidebar-box, let it bubble up?