Resizes of elements below the current scroll position do not cause a layout shift; thus, they can be ignored.
This was a problem when using tap zone click scrolling, because the scrolling was aborted by the scroll position preservation
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 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
* Reader: Reset bounds on window size change
19f2d993 introduced a `minWidth` to make sure sizes are consistent over
chapter changes (or when images load later), but when the window itself
changes, this makes the reader incorrectly sized
* Reader: Update size on navbar width change
This happens mostly when the bar is pinned; same effect as previous
commit
* Reader: Attempt to set the page on resize
It's not perfect, but not changing position at all seems impossible due
to how resizes are handled by the browser (since we adjust our content
to the window size)
* Simplify and abstract reader size reset
Co-authored-by: schroda <50052685+schroda@users.noreply.github.com>
* fix: Reader page full width was not properly calculated for static navbar
Only relevant for Fit Content, this did not properly consider the navbar
when the user clamps the content to a custom width
* Refactor: Put reader min sizes to reader itself instead of chapter
This allows some logic simplification.
The `ResizeObserver` can needs to be on an element without restrictions;
previously, the observer would not see the chapter elements get smaller,
since the `min-width` prevented it from shrinking. By applying to the
outer element, we still preserve the centering (since `margin: auto` is
also applied here), but allow the chapter itself to be smaller.
* Reader: Only scroll in continuous reading modes
* Reader: clean up size tracking
Co-authored-by: schroda <50052685+schroda@users.noreply.github.com>
* Fixup previous commit stupidness
* Reader: move `minWidth`/`minHeight` back to chapter wrapper
* Apply suggestions from code review
Co-authored-by: schroda <50052685+schroda@users.noreply.github.com>
* Also revert `fullWidth` calculation
* Simplify `chapterViewerSize`
Co-authored-by: schroda <50052685+schroda@users.noreply.github.com>
* Move size logic entirely to hook
---------
Co-authored-by: schroda <50052685+schroda@users.noreply.github.com>
In the horizontal pager loading the previous chapter caused the scroll position to get lost and instead of starting at the end of the previous chapter, the scroll position was at the very start.
This happened everytime no matter if the scroll position was at the x 0 or not before the previous chapter got visible.
Same issue can be observed in the vertical pager in case the scroll position is at y 0 before the previous chapter has been rendered.
The viewers can have different sizes which caused theme to not be properly centered.
E.g. for the "vertical mode" in case "chapter 1" is greater in width than "chapter 2", the pages of "chapter 2" were not correctly centered due to the "viewers" having different widths.
In case many chapters are rendered, even just the HOC wrapper component re-render due to the context change increases the render time.
Thus, getting rid of these HOC wrapper re-renders by moving the context usage up to the ReaderViewer decreases the render time.
In case many chapters are rendered, even just the HOC wrapper component re-render due to the context change increases the render time.
Thus, getting rid of these HOC wrapper re-renders by moving the context usage up to the ReaderViewer decreases the render time.
By the time the scroll area got scrolled to the start of the visible pages, the previous/next page wasn't yet shown and thus, the scrollable area wasn't updated yet.
Thus, in case the scrollable area grew in width due to the page change, the start never got scrolled into view due to triggering the logic too early.
Instead of immediately updating the value once the page count changed, it got updated after "pagesToSpreadState" changed, which was after the rendering finished.
This was the actual root cause of what was tried to be fixed with 9ab6ec89c7
Since "pagesToSpreadState" isn't part of the dependency array and also would decrease the render performance if it was (see reasoning of c79f7cc874), the array reference might be out of date and thus, the guard might not work correctly
In case the current page changed after selecting a page, the previously selected page couldn't be selected again since the "pageToScrollToIndex" was still set to this page
Due to handling an "offset spread page" change as if the "double page" mode got activated, the index of the secondary page was set, which resulted in opening the next page
Depending on the screen size and e.g. the set "reader width" pages might not have filled out the full img elements size due to "object-fit contain".
This was caused due to the image wrappers flex container "align-items center" which slightly reduced the images width to some ".xy" number (e.g. instead of wrappers width 258px, the images were something like 257.83px)
In case the last page of a manga was immediately visible or the became visible after the "image spread state" change, the chapter never got marked as read
Due to the way the pages got scrolled into view, the current page was not changed to the new page.
This then prevented the previous/next page to get opened via click/hotkey actions
