Search from selection broken

[detuur]

SumatraPDF version

• v3.6.17065 64bit

Describe the bug
A common workflow is to select text in a document, then press Ctrl+F to search for occurrences of the search text. Then, subsequent inputs of Ctrl+F should enumerate subsequent occurrences. Sometimes this works, but often it doesn't, either refusing to search, or searching for a stale search string. Using F3 after Ctrl+F functions as expected, but Shift+F3 has issues as well, performing a forward search if no F3 has been issued before.

Reproduction and expectation
There's multiple broken behaviours, but I expect that all of these have a common or related cause. I'll make one sequence that illustrates all of them.

1. Open the application, and a document.
2. Select any common word with the cursor. Pick a common word like the, and do not select the first occurrence on the page.
3. Press Ctrl+F.
4. Expectation: Search bar fills with selected text, and selection jumps to the next occurrence of the search string.
5. Actual behaviour: Search bar fills with selected text, and selection jumps to the first occurrence of the search string on the page.
6. Repeat Ctrl+F inputs a few times.
7. (Expected) The selection continues to iterate through occurrences of the search string.
8. Press Shift+F3.
9. Expectation: selection jumps to the previous occurrence of the search string.
10. Actual behaviour: selection jumps to the next occurrence instead.
11. Press F3 (any number of times).
12. (Expected) The selection jumps forward through occurrences of the search string.
13. Press Shift+F3 (any number of times).
14. (Expected) The selection jumps backward through occurrences of the search string.
15. Select a different common word with the cursor.
16. Press Ctrl+F.
17. Expectation: Search bar fills with selected text, and selection jumps to the next occurrence of the NEW search string.
18. Actual behaviour: Search bar fills with selected text, and selection jumps to the next occurrence of the OLD search string.
19. Repeat Ctrl+F input.
20. Expectation: ???
21. Actual behaviour: Search bar fills with selected (OLD) text, and selection jumps to the next occurrence of the OLD search string.
22. Open a different file in a new tab.
23. Select an uncommon word with the cursor.
24. Press Ctrl+F a few times.
25. Expectation: Search bar fills with selected text, and selection jumps forward through occurrences of the search string, looping at the last occurrence.
26. Actual behaviour: As expected, but stops accepting input after the last occurrence, not looping.

File that reproduces the problem
This is common across any PDF I've tried.

Screenshots
n/a

Additional context
n/a

[GitHubRulesOK]

Hmmm agreed totally bemusing separate functions but could be better.
The last one is perhaps the oddest and might be the one to resolve first so when selecting a second word as described it is transferred to find box but needs accepting manually via enter or else ignored and old word is in buffer. That could be automatic switch to accept. but the enter also is a signal to look for a match hence the jump.

This also opens a similar issue that when using / the selected word is transferred and search starts at top of page but then another / will replace that etc. so it is the logic about using a selection as a start that is odd.