Choose which element to scroll more wisely
'overflow' events _are_ triggered for `<html>`, if it overflows. This means that
there is no need to try to detect if `<html>` is scrollable in `commands.scroll`
using `.scrollHeight` and `.clientHeight`; we can simply use
`vim.state.largestScrollableElement`.
The above is not only a code cleanup; it also fixes a bug, mentioned in #605:
On some sites (such as groups.google.com), `<html>` might overflow, but not be
scrollable because of `overflow: hidden;`. The old `.scrollHeight` vs.
`.clientHeight` technique did not catch this, and wrongly tried to scroll
`<html>` when there was a more appropriate scrollable element on the page.
`overflow: hidden;` _is_ taken care of for `vim.state.scrollableElements` and
`vim.state.largestScrollableElement`, though, fixing the problem.
This clears the confusion from commit
59cb2a9a:
> Revert "Remove unnecessary code in commands.follow{,_focus}"
>
> This reverts commit
1a77a5d62036ee0d6029b36ee3c2ef33355b0d85.
>
> Apparently, I must be wrong. I get a hint marker for the entire page (if it is
> scrollable) after this commit. So confused now.
As noted above, `<html>` (`document.documentElement`) _does_ get 'overflow'
events, and thus ends up in `vim.state.scrollableElements`, so we _should_
exclude `document.documentElement` from getting a marker. There is no need to
deal with quirks mode here, though. In quirks mode, `<body>` is considered the
root element and must be scrolled instead of `<html>`, but 'overflow' events are
still triggered for `<html>`, and _not_ for `<body>`.
git://git.gir.st / VimFx.git / commit