In case the "webui update status" has already been reset, the "tag" of the status is just an empty string and will cause an invalid url.
Besides this, it is currently not possible to point to the actual changelog of a stable release, because the "tag" is not the actual "github tag" and thus, the url just points to a non-existing release
It's not necessary to observe all elements, since "ReaderChapterViewer" is the parent and thus increases/decreases in size in case its children change.
When scrolling to the previous chapter, which has not been preloaded, the scroll position got lost due to the resulting layout shift
* Update scroll preserve by tracking cursor
* Clean up interface
* Observe just the wrappers instead of individual images
* Switch to `IntersectionObserver` for tracking active element
* Clean up adding of observations
Co-authored-by: schroda <50052685+schroda@users.noreply.github.com>
---------
Co-authored-by: schroda <50052685+schroda@users.noreply.github.com>
Using the actual "document element" as the "intersection observer root" causes issues in case the available reader width is less than the viewport.
In these cases sometimes the previous/next chapter never loaded because the necessary intersection never fired.
The changes from 642708b8b3 didn't consider the case were the chapter change was triggered due to scrolling to the unloaded previous/next chapter with infinite scroll
The logic didn't handle cases were the next/previous chapter wasn't loaded yet, which lead to the load happening in the background without any user feedback.
The pages only change in size with specific "page scale modes".
Thus, if these modes are not active, the scroll position will not be lost.
There are different cases were even with these modes active, the scroll position won't get lost (e.g. "fit width" while no page is larger than the available width), but handling these would be too cumbersome.
Ideally the relative scroll position would be preserved, however, from testing a little that seems to not work too well
The `.toLocalLowerCase` is english-specific, this should be handled via
a dedicated translation like everywhere else, `global.value` is being
abused here
