In Safari, clicking on links triggers `selectionchange`. Since we do not
move the caret when flipping through pages, when you have flipped to the
next or previous pages and click on any link, it would take you back to
the caret instead of activating the link.
Note that the bug occurs in Safari 17 but not in WebKitGTK 2.46.
Not sure if there's a way to fix this and still retain the "set anchor
to caret on click" behavior. But I guess this behavior isn't really that
essential, anyway. So removing it for now.
Fixes#44
The view follows caret when using caret browsing (F7). Also allows
selecting across pages. And if you click on or select some text and
resize the window, the caret/selection always stays visible.
Some quirks regarding caret browsing:
- In Chromium, in paginated mode, it scrolls when changing selection
(https://issues.chromium.org/issues/40889650)
- In WebKitGTK, in scrolled mode, the view doesn't follow the caret
(which would be a WebKit bug)
What's `margin` doing here?! It's like this since the first commit, but
it makes no sense... I think I added it incorrectly, being misled by
the getBoundingClientRect bug in Firefox...
The effect of this is more obvious if you enable caret browsing (F7 in
all browsers). Previously, if you go to a fragment, the caret isn't
moved. Now it works as expected.
This is a purely internal change, but it might make things easier in the
future if one wants to place stuff on the margins (e.g. to fade the edge
of the iframe when animating, or place prev/next buttons on the sides)
Anchoring triggers the `scroll` event, which in scrolled mode causes
`#afterScroll()` to be called again with the reason `scroll`, which
shouldn't happen as it's just anchoring, not scrolling.
Massively simplify margin/padding and header/footer layout and eliminate
unnecessary resizes and resize loops.
Also remove layout and style API from View, as these are only applicable
to the paginator.
Huang Xin
Protected
John Factotum
Ray-D-Song