* 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>
There were different issues with the direction the pages got preloaded.
- when resuming a chapter with an initial page > 1, it incorrectly preloaded leading pages instead of trailing ones.
- when going to the previous/next rendered chapter no pages got preloaded at all
There can be cases where when scrolling backward/forward the first/last page never gets visible in the viewport due to a large width/height of another page.
In that case the intersection observer would never trigger and thus, the chapter wouldn't get changed.
By using the Pager, which always takes up the full width/height, this problem will not be possible, since the start/end of the Pager always enters or leaves the viewport.
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.
Seems like not all browsers handle
width/height: 100%
min-width/min-height: fit-content
correctly.
the "min" setting just never applies and the size is stuck at 100%.
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.
