User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/601.6.17 (KHTML, like Gecko) Version/9.1.1 Safari/601.6.17 Build Identifier: LibreOffice 5.1.4.2 The following shortcuts work OK in windowed mode (normal and maximised) but fail to work in Full Screen Mode: Cmd+<Number> (Heading and Text Body styles) Cmd+B (Bold) Cmd+I (Italic) Reproducible: Always Steps to Reproduce: A (New Document version) 1. Start LO by double clicking the application icon in the Finder 2. Select Create → Writer Document 3. Type the word “Test” 4. Select View Menu → Full Screen OR Press Shift+Cmd+J to enter Full Screen Mode 5. Highlight the word “Test” and press Cmd+1 (or any shortcut listed in Details) B (Recent Document version) 1. Start LO by double clicking the application icon, then open a Recent Document by tapping its thumbnail. Or just double click an existing .odt file in the Finder. 2. Press Shift+Cmd+J to enter Full Screen Mode (do NOT use View Menu → Full Screen) 3. Highlight some text and press Cmd+1 (or any shortcut listed in Details) Actual Results: The style or formatting doesn't get applied. Expected Results: If pressing Cmd+1, the Heading 1 style should be applied to the highlighted text, and the format should change (the text should become bold and the font size should increase). [Information automatically included from LibreOffice] Locale: en-US Module: StartModule [Information guessed from browser] OS: Mac OS X (All) OS is 64bit: no Model Name: MacBook Pro Model Identifier: MacBookPro6,1 Processor Name: Intel Core i5 Processor Speed: 2.53 GHz Number of Processors: 1 Total Number of Cores: 2 L2 Cache (per Core): 256 KB L3 Cache: 3 MB Memory: 8 GB Reset User Profile?No
In the case of B (Recent Document version) there is some additional behaviour which may or may not be useful: The formatting operation only fails when I use Shift+Cmd+J in step 2. And thereafter the problem persists until I restart LO - no matter how often I toggle between windowed and Full Screen mode, and whichever method I use to go Full Screen (shortcut or menu clicks). If, on the other hand, I use the menu option View Menu → Full Screen in step 2, the heading style will be applied as expected. And thereafter it will continue to work properly – whichever method I subsequently use to go Full Screen (shortcut or menu clicks). So, when editing an existing document, this is a possible workaround. However, in the case of A (creating a new document), it doesn't matter whether I use the shortcut or the menu clicks to go Full Screen initially - the formatting fails either way. The way forward here is to save the document early, then reopen it and use the workaround for case B above.
@Steve-- one for your QA...
With Version: 5.3.0.0.alpha0+ Build ID: 33d58de8c05d7a3591ac81164c1786d183a09991 CPU Threads: 2; OS Version: Mac OS X 10.11.5; UI Render: default; Locale: fr-FR (fr.UTF-8) Shift+Cmd+J does nothing, the app window remains unchanged. The keyboard shortcut has been changed to Ctrl+Cmd+F which is the OSX default fullscreen keyboard shortcut. Pressing Cmd+1 in a fullscreened Writer document applies the style, so this is WFM in master 5.3alpha
Also WFM in Version: 5.2.0.0.beta2 Build ID: ae12e6f168ba39f137fc110174a37c482ce68fa4 CPU Threads: 2; OS Version: Mac OS X 10.11.5; UI Render: default; Locale: fr-FR (fr.UTF-8)
Thanks Stuart and Alex, Great to know this is fixed in version 5.2
Sadly still not WFM in LO 5.2.0.4, on a fresh installation of OS X 10.11.5. Same with OS X 10.11.6. Version: 5.2.0.4 Build ID: 066b007f5ebcc236395c7d282ba488bca6720265 CPU Threads: 4; OS Version: Mac OS X 10.11.6; UI Render: default; Locale: en-US (en.UTF-8)
@paperdog: which shortcut is not working for you? can you give precise examples so this can be tested please.
Hi Steve, thanks for your quick response. The shortcuts which don't work are: Cmd+<Number> (Heading and Text Body styles) Cmd+B (Bold) Cmd+I (Italic) Please see the original bug description for examples.
Confirming → NEW
Already broken in Version: 5.1.4.2 likely earlier or always.
existing in 3.3.0.4 so inherited from OOo
** 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
I can confirm that this bug is still present in: Version: 5.4.3.2 Build ID: 92a7159f7e4af62137622921e809f8546db437e5 CPU threads: 4; OS: Mac OS X 10.11.6; UI render: default; Locale: en-US (en.UTF-8); Calc: group The Full Screen shortcut keys have changed from Shift+Cmd+J to Ctrl+Cmd+F, but the bug remains the same. This has been a showstopper for me - I haven't used LO on OSX because of it. Hope it can be resolved soon.
Still present in: Version: 6.0.0.3 Build ID: 64a0f66915f38c6217de274f0aa8e15618924765 CPU threads: 4; OS: Mac OS X 10.11.6; UI render: default; Locale: en-US (en.UTF-8); Calc: group @steve -_- : is anyone working on this? It surely can't be that difficult to fix...
Telesto, Xisco, Tor: are any of you guys able to repo this on a Mac, as Steve repos it and Alex doesnt.
Repro. However depending on the order Version: 6.1.0.0.alpha0+ Build ID: d1bc14b318c9a412a761d243085da0895a1aed4a CPU threads: 4; OS: Mac OS X 10.13.3; UI render: default; Locale: nl-NL (nl_US.UTF-8); Calc: group threaded No issue in scenario A 1. Type TEST to a document 2. View Menu → Full Screen 3. Select text (CTRL+A) and CTRL+B However broken in: Scenario B 1. Type test to a document 2. Press CTRL CMD F 3. Select text (CTRL+A) 4. CTRL+B Scenario C 1. Type test to a document 2. Select text (CTRL+A) 3. View Menu → Full Screen 4. CTRL+B It's permanent in all cases. So it keeps working if you follow the steps of scenario A. It will break when following B or C (and LibO needs a restart to undo the effect). So, pressing a key combo before entering Full screen mode seems to break things
Created attachment 139614 [details] Bibisect Bisected to: author Yousuf Philips <philipz85@hotmail.com> 2015-05-31 21:19:50 +0400 committer Yousuf Philips <philipz85@hotmail.com> 2015-05-31 22:20:44 +0000 commit 6c189a1eb90012789692344aa7dc418c7ec7f032 (patch) tree 9c0a5d2a7cf059fc6dd494174a1fa9a4d3e97a3e parent 778d5508f5be8d9e31e1634110137f8afdf0065e (diff) tdf#91781 Reorganize writer's menu bar
The description given here bug 49853 comment 142 seems to fit perfectly
(In reply to Telesto from comment #18) > The description given here bug 49853 comment 142 seems to fit perfectly Yep that seems to be the problem, as when i removed Bold from the menu, the shortcut worked fine in full screen mode. @Maxim: as you fixed bug 49853, what do you think should be the fix here?
Hope this quick patch will do the trick: https://gerrit.libreoffice.org/49399/
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9d77e7551e56b85d7f1b40bc42b9ba6876091f22 tdf#100784 macOS: Don't attempt to handle shortcuts via the menubar It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Maxim: as your patch mentions to not do this in full screen mode, is there a reason why its doing it in regular mode?
(In reply to Yousuf Philips (jay) from comment #22) > Maxim: as your patch mentions to not do this in full screen mode, is there a > reason why its doing it in regular mode? Because that's how any other native Mac app works. You can see it in other apps, that when pressing a shortcut which has an entry in the menu, the top level menu item blinks (e.g. when pressing Cmd+C for Copy, the Edit menu blinks). What actually happens is that a click on the corresponding menu item is simulated, instead of letting the app handle the shortcut directly as a keyboard event. Of course we're free to not follow this, at the cost of losing the menu blinking visual effect.
Thanks for the info Maxim, as i'm a Mac novice. :D So will LO register this shortcut behaviour as a menu item activation or a shortcut execution, as this would cause problems to usage metrics collection?
To Maxim, Yousuf and Telesto, Many thanks for taking this on. Is this the patched image file: https://dev-builds.libreoffice.org/daily/libreoffice-6-0/MacOSX-x86_64@49-TDF/2018-02-08_09.36.00/libreoffice-6-0~2018-02-08_09.36.00_LibreOfficeDev_6.0.1.0.0_MacOS_x86-64.dmg ? When I run it (in parallel with 6.0.0.3) the bug is still present. Maybe I am looking in the wrong place?
@gilbox: since whiteboard has "target:6.1.0" as target, the 6.0.x branch will not have the fix (yet).
@steve -_- Thanks, I will wait for 6.1.0. Very happy to know this bug is fixed.
Backport was already submitted two days back, but still not merged yet. https://gerrit.libreoffice.org/49707
(In reply to Yousuf Philips (jay) (retired) from comment #24) > So will LO register this shortcut behaviour as a menu item activation or a > shortcut execution, as this would cause problems to usage metrics collection? It will see it as a menu item activation. But in fact, the current usage collection code doesn't seem to make any distinction between commands that were executed from a kb and those executed by a mouse click.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3b457cb8825882cadec44e0b0679d1e70051eb71&h=libreoffice-6-0 tdf#100784 macOS: Don't attempt to handle shortcuts via the menubar It will be available in 6.0.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Sorry to say the 6.0.2 patch is not WFM. All three scenarios fail, including A (see comment 16). Version: 6.0.2.1 Build ID: f7f06a8f319e4b62f9bc5095aa112a65d2f3ac89 CPU threads: 4; OS: Mac OS X 10.11.6; UI render: default; Locale: en-US (en.UTF-8); Calc: group
(In reply to gil from comment #31) > Sorry to say the 6.0.2 patch is not WFM. You're right. The patch present in the 6-0 branch, but not in 6-0-2. I'll correct the Whiteboard to reflect that.
Thanks Maxim, I'll look forward to 6.0.3
Glad to report full screen keyboard shortcuts are working perfectly in: Version: 6.0.3.2 Build ID: 8f48d515416608e3a835360314dac7e47fd0b821 CPU threads: 4; OS: Mac OS X 10.11.6; UI render: default; Locale: en-GB (en.UTF-8); Calc: group Big thanks to Maxim, steve, Yousuf, Telesto, Stuart, Alex and everyone involved with this fix. Now I can start writing again :^)
There is a comment above the relevant code that says "the main menu just beeps for an unknown or disabled key equivalent", is that really true any more? Did you hear beeps for shortcuts that did not work?
(In reply to Tor Lillqvist from comment #35) > There is a comment above the relevant code that says "the main menu just > beeps for an unknown or disabled key equivalent", is that really true any > more? Did you hear beeps for shortcuts that did not work? By "beep" it means that the app menu flashes. At least that was the case in some older macOS releases. IIRC there was a (documented) change in behavior in one of the latest macOS releases which made this "manual" asking of the menu bar unnecessary, so (depending on our minimum supported version) we might not need this piece of code anymore. But I can't remember the details right now.
I didn't hear any beeps or see any app menu flashes in OS X El Capitan (10.11.5)