In the Writer Find&Replace window, the keyboard shortcut ~r for Replace does not work; clicking Replace does. (The shortcut ~x does.)
Steps to Reproduce:
2.^h: search for 'a', try replacing with 'b'
3.'a' found; hit ~r (alt r), or 'r'. Nothing happens.
4. Click Replace: 'a' becomes 'b', next 'a' found —as expected.
User Profile Reset: No
Created attachment 149698 [details]
file with 3 'a'
I think, hitting 'r' just brings the focus to the Replace Button. You have to press Enter to replace 'a' with 'b'. So for me everything works as expected and NOTABUG. Please change it back to UNCONFIRMED with an explanation, if you disagree.
(In reply to Dieter Praas from comment #2)
> I think, hitting 'r' just brings the focus to the Replace Button. You have
> to press Enter to replace 'a' with 'b'. So for me everything works as
> expected and NOTABUG. Please change it back to UNCONFIRMED with an
> explanation, if you disagree.
If one has to hit Enter after ~r, it's not a SHORTcut any longer!
With other editors (Open Office, Notepad, Notepad++, SciTE), just hitting the key (r, or ~r) does the replacement and searches for next.
Besides, the shortcut ~x is immediate, does not require the user to press Enter.
I confirm it with
Version: 22.214.171.124.alpha0+ (x64)
Build ID: f42554a1886ebe49170c25096dc3281b2c7bb1f4
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win;
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-02-08_22:37:30
Locale: en-US (de_DE); UI-Language: en-US
Click or <enter> while on the Replace button will perform the replacement. But action of the accelerator seems disconnected. It will toggle between the Replace button and the Find Next button--but not perform the replacement.
Contrast that with the ~l for an "Replace All" action which applies correctly.
On Windows 10 64-bit en-US (1803) with
Build ID: 5fe551931d49a64ca4ea793a5016c098e41e84cd
CPU threads: 8; OS: Windows 10.0; UI render: default; VCL: win;
Locale: en-US (en_US); UI-Language: en-US
This happens because the r accelerator conflicts with the "Diacritic-sensitive" check boxes accelerator.
Using a unique one for the latter box would solve this; for example s does not seem to be used.
Also the accelerator for Comments checkbox and the Close button (c) also conflicts, causing the same problem.
I may confirm the issue for LO 126.96.36.199.
Previous LO 6.2.5 accelerator worked fine
*** Bug 129281 has been marked as a duplicate of this bug. ***