Version: 7.0.0.3 (x64) Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: threaded Also an issue in LO 6. If the cursor focus is on the Find & Replace dialog, then the SAVE shortcut, Ctrl + S, does not work. This requires the user to click back on the text, thus interupting the work flow.
Same for UNDO (Ctrl + Z), and no doubt others.
Ctrl + S or works on MacOS (CMD S) being inside the dialog. So could/should work on win too. CTRL+Z. It probably places cursor in document, after pressing CTRL+Z, if it would work. Also it tends to scroll things to different pages in certain scenario's. So not to optimistic if this would work properly all the time And is the workflow personal or common. I personally don't press CTRL+S that often. Certainly not with dialogs open. But that's me.
Me telling bogus. Both did work before Fine in Version: 6.0.6.0.0+ Build ID: c30963b8b4bbbe42a24b97aafa161eff9d7ccdd4 CPU threads: 4; OS: Windows 6.3; UI render: default; Locale: nl-NL (nl_NL); Calc: CL
Found in Version: 6.3.0.0.beta1+ (x86) Build ID: 5cfac16dbd4af456a7fb6d52c8953c69a72ba2ba CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL not in 6.2
A longshot perhaps: but any connection with Bug 123825?
Created attachment 164871 [details] Bibisect log Finally a succeeding bibisect.. last view I did where a disaster/waste of time Bisected to: author Caolán McNamara <caolanm@redhat.com> 2019-03-22 15:59:00 +0000 committer Caolán McNamara <caolanm@redhat.com> 2019-03-24 18:19:29 +0100 commit f920e86fbf3968104e1dfc0e9934e80652ed0837 (patch) tree 01f8ed9c445821739b9709c5fee6e51eab0ae24d parent da881f38c088c439f034e340bbbb4ca53e67389f (diff) weld SvxSearchDialog I have to use the other way to specify an a11y role, both are implemented in the vcl parser, but in my gtk3-3.24.7 the role tag crashes the gtk parser, while the other route works fine. The CONTENT_FLOWS_TO accessibility relation is another additional complexity over the norm https://cgit.freedesktop.org/libreoffice/core/commit/?id=f920e86fbf3968104e1dfc0e9934e80652ed0837
Adding CC: to Caolán McNamara
(In reply to R. Green from comment #5) > A longshot perhaps: but any connection with Bug 123825? I think so. Based on time range where problem got introduced & dialog involved
Inherited from OpenOffice.org/StarOffice (and still in Apache OpenOffice 4.1.5) up until https://cgit.freedesktop.org/libreoffice/core/commit/?id=beeef93480fae65840646e4e36aa888efe92579a (somewhere between 5.1 and 5.2) there was a "Search For" label which had alt/ctrl+s as its accelerator. In all those versions ctrl+s in the search dialog didn't trigger save. The ctrl+s falling through the dialog accelerator handlers and escaping into the document accelerator handling seems to have been a feature of the SfxModelessDialog class which no longer exists but which the find&replace dialog used to use. So there was a window of time when there was no accelerators in the find&replace dialog for ctrl+s and when the find&replace dialog was based on SfxModelessDialog so that ctrl+s could call save.
(In reply to Caolán McNamara from comment #9) > Inherited from OpenOffice.org/StarOffice (and still in Apache OpenOffice > 4.1.5) up until > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=beeef93480fae65840646e4e36aa888efe92579a (somewhere between 5.1 and 5.2) > there was a "Search For" label which had alt/ctrl+s as its accelerator. In > all those versions ctrl+s in the search dialog didn't trigger save. > > The ctrl+s falling through the dialog accelerator handlers and escaping into > the document accelerator handling seems to have been a feature of the > SfxModelessDialog class which no longer exists but which the find&replace > dialog used to use. So there was a window of time when there was no > accelerators in the find&replace dialog for ctrl+s and when the find&replace > dialog was based on SfxModelessDialog so that ctrl+s could call save. Lovely coincidence. So some coincidence is happening on MacOS.. and needs this to go through UX?
mac, presumably, isn't special and I assume SfxModelessDialog just worked the same on mac as in win and gen. Going to the effort of allowing keystrokes not consumed by such a "modeless" dialog to go to the parent might be possible to restore, but in this specific dialog the "s" mnemonic is now in use by (in the English UI) the Diacritic-_sensitive checkbox so it wouldn't go to the parent window unless that was changed to some other mnemonic. Which then suggests that if this is a desirable feature then ideally translations should somehow know not to assign the equivalent language save mnemonic letter to modeless dialog translations, and that the save mnemonic (and possibly) others should be reserved not to be autoassigned for modeless dialogs when a label doesn't already have a mnemonic. For the general dialog case (bug#95410) the outcome was not to have ctrl+s (and others) get processed by parents of modal dialogs which is my own expectation for modeless dialogs too. Maybe @heiko has an opinion.
(In reply to Caolán McNamara from comment #11) > Maybe @heiko has an opinion. Don't see a solution either. Dialogs and controls receive and process key events and block thereby "global" shortcuts. If not, you could run any command from a modal dialog and we have to block the execution. Unblocking couldn't be done on a per-command basis but needs a per situation solution. Think this is a bottomless pit.
Agreed, a tar pit. I think we'll just have to take it that dialogs aren't expected to pass through accelerators to the document. Relatively difficult to implement and horrible burden of effort on translators to know to avoid what is a vast range of shortcuts