By default, Firefox starts searching after the end of the first selection range,
or from the top of the page if there are no selection ranges. This means that if
you search for "vim", a match for "vim" further up or down the page might be
selected, even though the word "vim" might already be onscreen, because of the
current selection (or lack thereof).
Vim starts searching in a similar way: After the cursor. The difference is that
in Vim, the cursor is _always_ onscreen. When you scroll, the cursor is "pushed
along" by the edges of the screen. This way, it is always very easy to tell
where you are going to start your search from. In Firefox, though, using the `/`
command can be quite disorienting.
Another Vim example: Let's say I searched for "vim" again (pressing `/vim` in
Vim). I then go through a few matches using `n`. Then I come to a block of text
that mentions "vim" _lots_ of times, and I realize that I'm not interested in
that block at all. Then it is easier to scroll (or "jump") past that block
rather than spamming `n` over and over (or trying to guess an appropriate
count). When doing the same in Firefox, though, after having scrolled past the
mentioned block of text, the next `n` keypress will scroll up right back to the
last match and continue the search there. This is pretty annoying to me.
While there's the Caret mode (which few people use) and the possibility to
select text in Firefox, there's usually no concept of a caret, and the caret
does not follow the scroll; it stays where it is, possibly offscreen. So where
should we start searching from, really?
This commit implements the following logic:
If there's a visible selection on screen, start searching after that point. If
not, start searching from the top of the current viewport. This works much more
intuitively. Note: Elements with `position: fixed;` are excluded when
determining "the top of the viewport".