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.
Preparation for infinite scroll, since there will be a wrapper which fits its content in width and height, thus, percentage based dimension won't work anymore
Instead of getting the whole download status, which contains all queued/active downloads, the download status should be read from the cache for only the required chapters
Automatically choose the progress bar position based on the available space.
Previously it was only possible to automatically switch from a horizontal to a vertical position but not the other way around
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.
Only really relevant for the "progress bar slot" prop to prevent the slots from unnecessary re-rendering, since depending on the total pages, this can impact the render performance on page changes heavily
The page change handling of the progress bar was inverted while RTL was the set readers reading direction.
However, this is only relevant for the horizontal progress bar
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
For the double pager the current page text needs more reserved space since two pages are displayed at once which changes the current page text to "<page1>-<page2>" instead of just "<page1>"
I was unable to find a fix for this problem, thus, the only solution I see is disabling this functionality for the continuous readers.
Due to preloading leading pages, the layout got shifted once the pages got loaded.
This messed with the scroll position which caused the top of the scrolled into views pages to not be at the top of the viewport anymore.
