(v0.2.10, Windows, desktop)
If you start the search and the list of search results opens, the element that “coincidentally” lies under the mouse pointer (if the mouse pointer is in this area) is selected. Even if you want to go through the hit list with the up/down keys, you seem to start at this preselected element.
In addition, the mouse pointer interferes with scrolling through the hit list because new elements are always selected by the mouse pointer and thus get stuck in the hit list.
When searching, if the mouse is anywhere in the zone of the search result pane, the result under the pointer gets selected.
Consequently, using down does not select the first entry of the results (which is the most relevant) but does one down the result selected because of the mouse pointer.
This is a UX bug 
Correct behavior should be that the mouse position is ignored until moved and that the first (most relevant) result is highlighted by default.
Thanks for reporting this. It annoyed me almost every day, but apparently not enough to find the time to report it
Please upvote!
It’s been bugging me every day as well.
I just noticed that I already HAVE reported that problem here:
Maybe someone can merge our to request.
Just merged - thanks for the head up!
This is also an issue on Mac desktop as of version 0.6.3.
To generalize this issue, the passive location of the mouse always acts as if it was a user intentional hover action.
In addition to the search issue described above, this causes tooltips to appear if any link moves under the mouse (e.g. you go to a new page using only keyboard commands and a link on the new page happens to be under where the mouse is). This both breaks keyboard navigation and also makes it so one has to move the mouse to get it out of the way far too frequently.
One solution would be to only respect mouse hover location when the user moves the mouse to a location, and then once any state changes (scroll, navigation, typing?) then the hover location is ignored until the user moves the mouse again.
Specifically for tooltips, this could also involve hiding page previews behind a key command as mentioned here: Add hotkey (suggest CMD or CTRL key) to preview page/block link currently under mouse cursor.
I’ve mentioned this thread in a comment on this issue on GitHub: