https://bugs.documentfoundation.org/show_bug.cgi?id=102307
V Stuart Foote <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |heiko.tietze@documentfounda | |tion.org, | |[email protected] Summary|F3 executes |F3 is hardcoded as Find |uno:RepeatSearch from the |next but not defined as the |FindBar TextFind widget |shortcut for |when not defined as the |uno:RepeatSearch |shortcut | --- Comment #11 from V Stuart Foote <[email protected]> --- My comment 1 and comment 3 regards the UNO assignment were off topic. For legacy Find use, the F3 key is hardcoded (as Key_F3) assigned at tbunosearchcontrollers.cxx#301 to activate the Find bar, so non-customizable. <F3> and <Shift><F3> Find next and find previous movements are held over from legacy MS Word handling (since removed IIUC), but they remain in common use, e.g. for Notepad and the Visual Basic Editor as well as new Visual Studio Code for Find Next and Find Previous. However, case can be made as in OP that behavior seems wrong. But not the assignment of the <F3>, but that its behavior changes depending on *edit cursor* focus. When the Find bar tb has edit cursor focus, the <F3/Shift+F3> pair perform the next/previous Find actions. But with Find tb open, but edit cursor shifted onto canvas, the text at cursor position becomes the new search target and throws an info warning 'AutoText for shortcut <selected text> not found'. And when UI is not focused to document canvas (e.g. is on Main menu or Std Toolbar)--the F3 pair then have no action. Likewise get the same behavior when edit cursor is not on the Find bar affecting the <Ctrl>+G/<Shift><Ctrl>+G Find next/previous shortcuts. Except that the <Ctrl>+G is now assigned and when on document canvas now launches the GoTo page dialog. A this point, I don't think removing the <F3> pair would be correct, it is not a bug. They are valid common shortcut. But maybe should be bound to the Find bar being open even if unfocused, and the Find next/previous not dependent on edit cursor and UI focus placement? As in OP "... it should work even when cursor is not inside search box." -- You are receiving this mail because: You are the assignee for the bug.
