Raises the following error:
"An empty string ("") was passed to the src attribute. This may cause the browser to download the whole page again over the network. To fix this, either do not render the element at all or pass null to src instead of an empty string"
Fix missing peer dependencies:
- warning " > @graphql-codegen/client-preset@4.8.0" has unmet peer dependency "graphql-sock@^1.0.0".
- warning " > @graphql-codegen/typescript-operations@4.6.0" has unmet peer dependency "graphql-sock@^1.0.0"
Ignore missing peer dependency for "mui-nested-menu" (package itself doesn't get used but a copy&pasted and modified version of its "NestedMenuItem" component
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
