1. open a new document and enter some text 2. press F11 to open styles pane 3. press ^S to save - document is not saved no such issue with navigator pane (F5). There is a similar supposedly fixed issue https://bugs.documentfoundation.org/show_bug.cgi?id=109135, and yet here we are.
Confirm STR. When F11 opens the Navigator SB deck, focus is on the style type tab bar of the Content panel. Default on opening lands on the Paragraph content panel. In that state, a <Ctrl>+S shortcut does not function. Nor with any selection on the styles Tab bar. However, with <TAB> advance into the Style listing to land pointer focus on a viable style, it allows the <Ctrl>+S shortcut to fire and save. Similar mis-handling of the ^S shortcut when pointer focus is advanced by TAB out of the Styles content panel and onto the SB's Tab Bar. Seems an issue in the SB framework for handling the <Ctrl> key? @Jim, Samuel ? =-testing-= Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: bbc9ac1f08a5ee4b9f65eaf10110df328d95de95 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
This also holds true for x11/win/qt5 VCL backends when focus is on any toolbar item, for example, the save button in the standard toolbar, ironic! For me Gtk3 backend already works as expected. Here is a patch that makes these other backends also work as expected: https://gerrit.libreoffice.org/c/core/+/163800
(In reply to Jim Raykowski from comment #2) > This also holds true for x11/win/qt5 VCL backends when focus is on any > toolbar item, for example, the save button in the standard toolbar, ironic! > > For me Gtk3 backend already works as expected. > > Here is a patch that makes these other backends also work as expected: > https://gerrit.libreoffice.org/c/core/+/163800 Thanks Jim, and that is ancient OOo era config to only handle the MOD1 <Alt> modifier. So the not applicable to gtk3 backend seems to have obscured multiple WFM resolved issues, e.g. bug 43822--suspect there are a fair few to identify. Please push it and will test. @Cor, * heads up. =-STR-= <Ctrl>+S as noted OP, or <Ctrl>+w to close from TB 1. new writer document 2. dt <f3> for a para of text 3. <f10> to main menu 4. <f6> advance to standard TB 5. <ctrl>+w; result ??? alternate from SB decks 1. new writer document 2. dt <f3> for para of text 3. <alt>+4 to SB Navigator 4. <shift>+<tab> to move focus back from Page up to SB deck title 5. <ctrl>+w; result ??? 6. <shift>+<tab> to move focus to SB's tab bar 7. <ctrl>+w; result ???
(In reply to V Stuart Foote from comment #3) oops s/MOD1/MOD2/ we're adding the MOD1 <Ctrl> modifier to the existing MOD2 <Alt> modifier for forwarding
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/45e3abcb79fb1ccf7d813a7b080a8ad70bdcb5b1 tdf#159837 Make keyboard shortcuts work when focus is in toolbar It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thanks Jim! Got to test with the c68712d 20240224 nightly build. <Ctrl>+w or <Ctrl>+s shortcut behavior from the SB decks and buttons are much improved. Unfortunately seem to still have issues with <Ctrl> string shortcuts from other Toolbars. The STR of comment 3 to position focus onto a button control (split or direct) of the Standard toolbar still results in the shortcuts as non-functional. So a different issue for those TB? Is this going to be some disconnect with shortcut sequence between the welded TB controls and the SB deck vcl controls that now seem fixed? =-testing-= Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: c68712d3689a0322e59934cd8151d003e869f30d CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
(In reply to V Stuart Foote from comment #6) > Got to test with the c68712d 20240224 nightly build. <Ctrl>+w or <Ctrl>+s > shortcut behavior from the SB decks and buttons are much improved. > > Unfortunately seem to still have issues with <Ctrl> string shortcuts from > other Toolbars. The STR of comment 3 to position focus onto a button control > (split or direct) of the Standard toolbar still results in the shortcuts as > non-functional. > > So a different issue for those TB? Very strange. Testing using gtk3 with the patch removed <Ctrl>+s works *sometimes* from the sidebar but not from the Standard toolbar. I really thought I saw it working from the sidebar and Standard toolbar when using gtk3.
Patch works for me (kf5) except the sidebar tab bar / tabs.
Here's a patch that make shortcuts for qt based VCL backends work when the keyboard focus is on a tab bar tab: https://gerrit.libreoffice.org/c/core/+/164051
(In reply to Jim Raykowski from comment #9) > Here's a patch that make shortcuts for qt based VCL backends work when the > keyboard focus is on a tab bar tab: > https://gerrit.libreoffice.org/c/core/+/164051 Just noticed that the patch also makes shortcuts work here for Windows.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0daeee1a7d0e530f1cce40f86a26ed01f07ee7da tdf#159837 Drop unneeded TabBar EventNotify KEYINPUT handling code It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.