* Fixes two places where navbar was not considered
When set to static, the navbar consumes space, so `vw` units are not
enough.
On small screens, the `left`+`transform` approach does not work nicely,
so just use standard flex alignment, the container is already a flexbox.
* Change card also consider wide viewports
* Update src/modules/reader/components/viewer/ReaderTransitionPage.tsx
Co-authored-by: schroda <50052685+schroda@users.noreply.github.com>
* Reader: Apply new alignment code also to horizontal scroll mode
---------
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
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.
In case a chapter only has a single page and the previous/next transition page was visible, it was not possible to go back to the chapters page, since it just opened the previous/next chapter instead
When a chapter gets opened via the chapter list in the reader, the visible chapter state gets reset.
The problem was that after this happened, the passed location state did not get reset and the "visible chapter state" constantly got reset everytime the state of a chapter changed
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.
In the "vertical mode" intersection changes for the left or right side of the element do not matter.
Same for "horizontal mode" the other way around.
If not handled accordingly, it would cause unwanted chapter changes.
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.
