-
Notifications
You must be signed in to change notification settings - Fork 174
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Improve Find mode search start position
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". Inspired by vimium/issues#1471.
- Loading branch information
Showing
6 changed files
with
194 additions
and
23 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters