Background: In OS X, command+Tab switches to the next application while command+` switches to the next window of an application. Adding shift to the commands causes them to switch to the previous application or window, respectively. Problem: In OpenOffice (and now continuing into LibreOffice), command+` correctly switches to the next LibreOffice window, but command+shift+` does too, when it should switch to the previous window. In other words, if you have several documents open but are only working on documents 3 and 4 at the moment, you can go from 3 to 4 using keyboard shortcuts, but you can only get back to 3 by either using the Window menu or repeatedly hitting the keyboard shortcut. To Reproduce: Open 3 documents. Cycle through them using command+`, and then cycle through using command+shift+`. It will only cycle forward, never back.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Dear bug submitter! Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs. To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem. Yours! Florian
Hi, Just checked in Version 3.6.0.4 (Build ID: 932b512), and this bug is still present. The method to reproduce still works exactly as originally stated. Thanks!
Please always use the oldest version in version field..
Bug was never confirmed by an independent reviewer, therefore reset Status to UNCONFIRMED. (No offence -- this does not mean that I doubt the existence of this bug -- when status is UNCONFIRMED, the chance is even better that a bugwrangler will try to reproduce this issue or search for duplicates, while with Status NEW the bug will probably just be overlooked.)
Tested in 3.5.6.2 and 3.6.2.2 in US- and german keyboard layout > works for me. The ` key is the one right from the left shift key (in between shift and z).
Hi Uwe, Thanks for checking that. Couple things: 1) I just tested in 3.6.2.2 and the bug is still present. Sounds like we're using different keyboards, which might be contributing to the problem. I have a US keyboard where the ` is immediately above tab and left of 1. There's nothing between shift and Z. 2) This does appear to be a problem with keyboard layout. For the heck of it I tried Greek Polytonic and the bug disappears. The bug is present in US, US Extended, and US International - PC. 3) When you tested the US layout, did you try CMD + Shift + `? Cmd + ` works fine, but Cmd + Shift + ` doesn't. They should go in opposite orders. 4) I just downloaded and tried all major releases starting with OpenOffice 3.0.0, the first to officially support Mac OS X. 3.0.0: Bug not present! Both Cmd+` and Cmd+Shift+` work, but there's a different bug causing their order to periodically reverse. Nonetheless, I can flip through windows both forwards and backwards, which is more than what the current version does. 3.0.1: Nothing changed. 3.1.0: Nothing changed. 3.1.1: Nothing changed. 3.2.0: Bug present! This was the release where some key bindings were changed to finally allow Cmd + ` to work in Calc. I can't find a particular bug that was fixed for this, but in earlier versions Cmd + ` enables formula view in calc. In 3.2.0 Cmd + ` starts switching windows instead. Here's the closest reference I can find (from 2009): https://issues.apache.org/ooo/show_bug.cgi?id=100730. That might be related. Anyways, thanks for looking into this!
Thanks for your additional comments - that could help a lot. Yes, I'm using a german keyboard (hardware). Using LO 3.5.6 and 3.6.2 with german keyboard input layout (system pref pane) everything worked perfect - shift reverts the order of windows. But changing to US international PC input layout (system pref pane), shift doesn't revert the order of windows any more! btw - the order with US layout is always backwards (previous window) compared to german layout (same as using shift-cmd-'>').
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (4.3.5 or later): https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) Thank you for your help! -- The LibreOffice QA Team
Confirming also on Version: 4.4.1.2 Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432 Locale : fr_ OSX 10.10.2 using Macbook Pro with FR locale keyboard layout.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.5 or 5.1.2 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT - Update the version field - Reply via email (please reply directly on the bug tracker) - Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-04-16
Just confirmed again using version 5.1.2.2 on Mac OS X 10.9.5.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.2.7 or 5.3.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170522
I had a look at this bug To press cmd+` on the Norwegian keyboard layout, I actually have to press shift+´ to send the ` button. That means the actual shortcut I have to press cmd+shift+´ to cycle windows. As described then it doesn't work to cycle backwards. However, when testing in TextEdit I get the exact same behaviour as in LibreOffice, I can't cycle backwards either, so this would indicate an upstream bug Switching to a saner key such as cmd+' (' is above tab) does let me cycle through the windows both ways when pressing shift However, I also wanted to check how this was on US keyboard layouts, as cmd+` is supposedly the default there as well, and has a much saner position right next to the left shift button. Then it doesn't work in LibreOffice, while TextEdit works, so there still seems to be a bug here Version: 5.4.0.3 Build ID: 7556cbc6811c9d992f4064ab9287069087d7f62c CPU threads: 2; OS: Mac OS X 10.12.6; UI render: default; Locale: en-US (en_US.UTF-8); Calc: group
I have the "bug" too, with: Version: 5.4.4.2 Build ID: 2524958677847fb3bb44820e40380acbe820f960 Threads CPU : 8; OS : Mac OS X 10.13.4; UI Render : par défaut; Locale : fr-FR (fr_FR.UTF-8); Calc: group I'm using a fully french mac (french keyboard, french system, french locale, french software...). In all applications, "`" is a dead key. Pressing the "`" key and then "a" key produces "à", which is very common in french (but is usually obtained by pressing the "à" key itself (the "0" key without "shift")). To get a "`" character alone (useful in lisp macros), we have to press once the "`" key and then the space bar. In many applications, pressing cmd-` switches to the next window and cmd-shift-` to the previous window. In LibreOffice, the behaviour of cmd-` depends on the document type. = In a Writer document, it's almost the same with or without keeping "cmd" down: - press "`" (without "cmd") -> insert a "`" dead character, with the same background as a selected character, but without any border. - click menu "Fenêtre" > some other window ("Fenêtre" means "Window") - click menu "Fenêtre" > the previous window -> the "`" is still highlighted - press "a" -> the "`" is replaced by a "a" (not a "à") - press "cmd-`" -> it switches to the next window - click menu "Fenêtre" > the previous window -> there is a "`" highlighted character - press "a" -> the "`" is replaced by a "a" (not a "à") = In a Calc document, it's more complexe. - double click a cell - press "l" and then "`" -> insert a "l" and a "`" dead character, with the a lighter background than a selected character. - click menu "Fenêtre" > some other window ("Fenêtre" means "Window") - click menu "Fenêtre" > the previous window -> the cell itself is highlighted (and contains "l`") if you: - press "a" -> the whole contents of the cell is replaced by a "a". but if you: - double click the cell to edit its contents -> it contains "l`" - press "a" -> nothing happens: no "a", no "à", the "`" remains When pressing "cmd-`", we have the same behaviour (plus the window switching).
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This is still present cmd+´ does not work, while cmd+shift+´ does work If I set a different shortcut, cmd+<, both works I think the problem is that ` is the shortcut key, which only LO capture if you press shift Norwegian keyboard layout Version: 6.4.0.0.alpha0+ Build ID: 54028dc503fc08eb12e287919d5e2850cff05b73 CPU threads: 4; OS: Mac OS X 10.14.6; UI render: default; VCL: osx; TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2019-07-31_01:48:19 Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded
This now works fine on: US keyboard layout Spanish ISO keyboard layout I can cycle back and forth On Norwegian keyboard layout I can only cycle one way, because I have to hold the shift key to produce the default ` key. But that is also the case in e.g., TextEdit, so that would be an upstream bug on choosing the default keyboard selections. The bug on inserting the ` mark is covered in bug 53965 which remains Version: 6.4.0.0.alpha0+ Build ID: 54028dc503fc08eb12e287919d5e2850cff05b73 CPU threads: 4; OS: Mac OS X 10.14.6; UI render: default; VCL: osx; TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2019-07-31_01:48:19 Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded