The character ` is inserted while cycling through the windows with the command-`shortcut on Mac. Windows are cycling correctly, but the character is printed in the previous document.
Steps to reproduce:
1. Open two open office documents
2. press command-` to cycle through windows
3. observe the ` character inserted in the previous document
The character ` is inserted while cycling through the windows with the command-`shortcut
The character ` should NOT be inserted while cycling through the windows with the command-` shortcut
Platform (if different from the browser):
Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_0) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.82 Safari/537.1
Thank you very much for your bug report!
I remember that we had a similar bug report some time ago, and that this issue depends on locale settings. Therefore, in order to solve the problem (or to confirm it as a bug), I first need to ask you:
-- Which MacOS X version do you use (probably 10.8)?
-- Which User Interface language for MacOS X do you use
(see System Preferences > Language and Text > Languages:
which one is the topmost language)?
-- Which keyboard layout do you use? The default one for that language,
or some special one (see System Preferences > Language and Text >
Input Sources: which "input methods" are selected?)
-- Which User Interface language do you use for LibreOffice?
(The UI language for LibreOffice is set in menu
LibreOffice > Preferences... > Language Settings > Languages >
Given these pieces of information, I may be able to solve the issue.
Thank you in advance!
Thanks for you fast answer!
Please find below answers to your questions
> -- Which MacOS X version do you use (probably 10.8)?
Yes, 10.8, but as far as i can remember, i had the same issue with 10.7
> -- Which User Interface language for MacOS X do you use
> (see System Preferences > Language and Text > Languages:
> which one is the topmost language)?
> -- Which keyboard layout do you use? The default one for that language,
> or some special one (see System Preferences > Language and Text >
> Input Sources: which "input methods" are selected?)
Spanish - ISO
> -- Which User Interface language do you use for LibreOffice?
> (The UI language for LibreOffice is set in menu
> LibreOffice > Preferences... > Language Settings > Languages >
> User Interface).
Default - English (USA)
Thanks for your concern!
Thank you very much for your fast answers!
I spent some time searching for the similar issue we had some time ago -- just as a hint for myself (or other bugwranglers), here it is: bug 50428.
Now I need to investigate if the present issue is really related ...
Please be patient, there are so many bug reports to handle ;-)
Setting Status back to UNCONFIRMED for now, this will change soon, I hope.
Created attachment 66272 [details]
Graphics: Keys to press to cycle through windows on keyboard with Spanish ISO layout
Sorry for the long delay!
In between I have tried to reproduce the issue on my MacBook Pro, just configuring everything according to your settings reported in comment #2 (MacOS UI language English, keyboard layout Spanish ISO, LibreOffice UI language US English. The only two things I can’t change are
* the MacOS X version (10.6.8 in my case) and
* my physical (hardware) keyboard which has German layout (this is very similar
to Spanish ISO; at least the same number and arrangement of keys, and
identical position of all the main keys 'A' to 'Z' and '0' to '9').
My first observation is that, using this configuration, there are two possibilities to cycle through windows:
1) I can press Command + ` (this key is at the top right of the keyboard,
right of 'P', left of '+') or
2) I can press Command + '<' (this key is at the bottom left,
right of the shift key, left of 'Z', below 'A').
Both ways work, but when I press Command + `, an additional ` accent is inserted into the text of the active document, just as you have reported, while, when I press Command + '<', everything works fine (windows are exchanged, but no character is inserted into the main text). The latter works with all applications I have tested (LibreOffice, TextEdit, BBEdit, and others).
Because a textual description of keys is a bit difficult, I attach a screenshot/graphics which shows a Spanish ISO keyboard layout and the two keys which I can press to cycle through the open windows.
Now a simple question:
Could you please try if using the second shortcut, i.e. pressing Command + '<' (or whatever lable may have that key on your physical keyboard) instead of Command + `, works for you without problems, just like for me? And report the results here, please! Thank you very much!
Thanks a lot Roman for your detailed answer.
Indeed command + '<' works fine as well for me. However it is not in line with other mac applications (especially the finder). And command + '`' should, in my opinion, cycle the windows in libre office without printing the character.
I do agree that it is a really minor bug, especially if there is an alternative solution. But if it can be addressed in a future release, it would be nice. Maybe a menu item "cycle through windows" could also be added in the window menu.
In the meanwhile, i am fine using command+'<', I've just learned something useful :)
Created attachment 66716 [details]
Screenshot of "Keyboard Shortcuts" settings (Mac OS X 10.6.8, UI language English, Spanish ISO keyboard)
Sorry again for the long delay!
(In reply to comment #5)
> Indeed command + '<' works fine as well for me. However it is not in line
> with other mac applications (especially the finder). And command + '`'
> should, in my opinion, cycle the windows in libre office without printing
> the character.
This is interesting. If I configure everything according to your settings reported in comment #2, my result is slightly different: for me, Command + '<' works in all applications (including Finder, Apple’s TextEdit, and others), while Command + '`' does not work in many applications.
I would be very interested about what default setting do you see for these keyboard shortcuts in System Preferences > Keyboard, tab "Keyboard Shortcuts". For me, these settings look like the attached screenshot shows: the default screenshots for cycling through windows are Command + '<' and Command + Shift + '<'. Could you create a screenshot of the same preferences section on your system and attach it to this bug report?
This would be very interesting ... so thank you in advance!
> Maybe a menu item "cycle through windows" could also be added in the window
IMHO this woild be the best solution, as this menu item could also show the recommended keyboard shortcut (which would eliminate any doubts ;-).
Created attachment 66726 [details]
Screenshot of "Keyboard Shortcuts" settings (Mac OS X 10.8.1, UI language English, Spanish ISO keyboard)
(In reply to comment #7)
> Created attachment 66726 [details]
> Screenshot of "Keyboard Shortcuts" settings (Mac OS X 10.8.1, UI language
> English, Spanish ISO keyboard)
Thank you! So Command + '`' is really the default keyboard shortcut for "Move focus to next window" on your system. This is interesting; it means that Apple varies even the default keyboard shortcuts for these standard actions -- Command + '<' on my System, even if I set the UI language to English, but Command + '`' on your System.
Now I can answer profoundly to your previous post:
(In reply to comment #5)
> Indeed command + '<' works fine as well for me. However it is not in line with
> other mac applications (especially the finder).
Given the fact that Command + '`' is really the default keyboard shortcut on your system, I agree with you: this shortcut should work in LibreOffice, too.
> And command + '`' should, in my opinion, cycle the windows in libre office
> without printing the character.
Agree -- when Command is down, '`' should not be considered as a dead key, but just as a ordinary key, so that no '`' is inserted into the text, but the shortcut is handled.
> I do agree that it is a really minor bug, especially if there is an
> alternative solution. But if it can be addressed in a future release,
> it would be nice.
Yes. I am afraid that it may take a long time until this issue is addressed (there are so many important issues which should get fixed first), but let us hope the best.
→ Changing bug report state to NEW (confirmed).
*** Bug 82988 has been marked as a duplicate of this bug. ***
*** Bug 91398 has been marked as a duplicate of this bug. ***
** 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.1.5 or 5.2.1 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)
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!
For me the document shows the ` about to be entered, but even if type an "a" immediately after cycling the ` character is not included in the document
Funnily LibreOffice actually shows ´, while the shortcut is cmd+` which means I actually press cmd+shift+´
This shortcut is horrible though, so I recommend people switch to a saner combination (e.g., ' - the button above the tab)
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
*** Bug 73586 has been marked as a duplicate of this bug. ***
I can reproduce a problem even with a Swedish/Finnish keyboard on macOS 10.13. Although on this keyboard I need to use Cmd-Shift-` to switch between LibreOffice windows. (The ` key is a dead key on this keyboard, it is normally used to add a grave accent to the following letter, like pressing ` and a gives à.) And the character inserted in the Writer document is the dead acute accent, ´ , and it is in the state of waiting for the following character to be applied to, but doesn't actually apply, but is ignored...
When the initial comment talks about the ` character, do you mean the freestanding grave accent (U+0060, plain old ASCII backquote), or what?
OK, with a "Spanish - ISO" keyboard layout (as the original bug reporter) I see the same as with "Finnish". The character inserted is a "dead" accent ` on a blue background, which means it is "waiting" for another letter to be applied to. But as soon as you have switched back to that window, and do anything at all in LibreOffice, it disappears. Is this what you are seeing, too?
Yes, using Spanish ISO layout
Set up three windows
Cycle through with cmd+`
First window you started from has input the ` and waiting on next letter
It does not disappear when coming back or clicking anywhere (unless pressing Esc)
This does not happen on US keyboard layout
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
*** Bug 136586 has been marked as a duplicate of this bug. ***