Regardless of scroll position in the editor, when searching by Ctrl+F, Obsidian currently searches from the start of the file even if there are results at the current scroll position or after it. This causes disorientation as the editor scrolls to a vastly different location than expected, which is out of the norm for a text editor.
Proposed solution
Search from current view or cursor position, and then wrap around to start of the document when there are no results.
Related feature requests (optional)
Search and Replace in Current Selection raises similar concerns, but specifies to search within a selection which is different from my request. It would be inconvenient to need to select the entire area I want to search within, which could be a very large text area.
Related problem/feature request: When a given word is identified by the search (Ctrl+F), the cursor position should move to that word, as a selected text, similar to most text editors.
Currently, the cursor remains in the location where the search has started, so if you want to type something after the located word, it’s necessary to use the mouse and move the cursor to that word (otherwise, if you try to type something in the document after the search, it will move to the previous cursor position, disrupting the editing process).
(Sorry for the lack of clarity; I’m not a native English speaker).
Obsidian remembers that last place your cursor was. So if you open a new note and scroll (and not select a new location), Obsidian still believes it’s where you left off last time you left the file. Also, if you are only doing a partial search, it does start from the top of the note first and will find that partial result if it is before the cursor position. Hope this helps.
If the partial search behavior is “expected” (searching while typing into the search bar), then introducing a toggle option to only search after pressing the enter key (or previous, next, all buttons) would more easily allow for this request to be implemented.