Problem description: Steps to reproduce: 1. File|Save As 2. Command A 3. Current behavior: Nothing happens. After the initial shock, the user has to manually press the Backspace key multiple times to erase the old file name Expected behavior: The current (i.e., wrong) file name is selected, ready to be typed over Platform (if different from the browser): Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.89 Safari/537.1
Thank you very much for your bug report! Test results ------------ This issue is not limited to Writer, but shared by all LibreOffice components (therefore set Component to “UI”). REPRODUCIBLE on Mac OS X 10.6.8 (Intel) with * LibreOffice 3.3.0 * LibreOffice 3.5.7.1 * LibreOffice 3.6.2.2 * AOO 3.4.0 So this is an old issue, inherited from OOo (therefore set Version to oldest available version, as usual here). Why is this minor glitch of some importance? -------------------------------------------- Many (long-time) Mac OS X users are used to the convention that Command-A works even in the edit field of the file save as dialog which contains the intented file name, so they are irritated by this behaviour (cf. Ambrose Li’s comment mentioning an “initial shock”). It is indeed strange that LibreOffice, using the generic Mac OS X file save dialog, does not support the Command-A shortcut in the edit field containing the intented file name, while all other Mac OS X applications which I have tested (Apple’s TextEdit, BBEdit, XPress, ... but also some not-so-native applications like Firefox and Thunderbird) support the shortcut here. The general problem could be that, while the file save dialog window is open and has got the focus, the whole menu bar is still enabled like when we are editing a document. In most applications, nearly all menu items are greyed out (disabled) when a dialog window is open, but not in LibreOffice (cf. bug 31915).
We can make the summary clearer.
*** This bug has been marked as a duplicate of bug 62054 ***