When the end of the scrollable element is reached in the continuous reader, the last image is not visible anymore.
Thus, the "firstVisibleImageIndex" is invalid and gets incorrectly used for the "isEndReached" case which results in an TypeError when trying to use the actual page via the index
The thresholds are only for detecting if a specific side of the image is in the viewport.
For the check if the image fills the whole viewport, the thresholds incorrectly detect this depending on the readers reading direction.
E.g. in the continuous horizontal pager with theme direction LTR and reader reading direction RTL, the left threshold will be the total width of the viewport plus one which will lead to out of view images to be detected as completely filling the viewport
Both hardcoded thresholds (MIN_VISIBLE_PX 0 or 1) break the "first visible image" detection in different kind of ways.
With 1 it always incorrectly jumps to the next page when resuming a chapter, since the page to resume will bet at 0px.
With 0 it fails to detect the correct first visible image when scrolling (automatically not via wheel or touch) to another page.
This happens when there is no gap between the pages because in this case the start of the current image and the end of the previous image are at the same coordinate.
Thus, the previous image is still incorrectly detected as visible since the end still aligns with the viewports start/end
In case the "currentChapter" is undefined, it means that the state has not been set yet.
In case the "currentChapter" does not exist, it would be set to "null".
As explained in c70287363a8e9308fc294baf83c5656a21a479b1, the "chapterSourceOrder" does not start at 0, thus, in case it's the last known chapter, "doesChapterExist" was always false due to subtracting 1 of the total chapters
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.
Sometimes the reader settings state took too long to get set and the previews were shown using the default settings first, since they are set as the default values of the reader settings context, and then again for the final settings
Due to not including the states in the dependency array (to improve render performance), they do not include updated data and might cause an incorrect early exit.
E.g. in case a load error happened for a page whose loaded flag was already set to true, the pages load state never got updated again
In case the "tap zone layout" setting value got changed from or to the same value as the default value, the preview was never shown due to the canvas being reused and therefore not triggering the useEffect
For continuous pagers the chapter transition page is always visible regardless of the current "transitionPageMode".
However, this was not properly checked and thus, it wasn't considered to be visible and instead of opening the previous/next chapter, the transition page got set to be visible first and only with the second hotkey press did the chapter get opened
The min/max limit was only acknowledged when the value was changed via MUIs step logic.
In case the number got inputted via keystrokes the limits did not get applied
"isRTL" was set to the direction value instead of correctly to the boolean flag indicating if it is the actual rtl direction value.
This didn't cause any issues because for ltr because for ltr the result of "scrollAtT0.current[X] - delta[X])" was never less than "-maxScrollPos[X]" and for rtl it always used the expected value since "isRTL" was truthy.
Re-rendering the component isn't too expensive and unmounting it improves the re-rendering caused by page changes since it doesn't get updated.
This removes ~7ms on a "current page" state update and ~25ms caused by the chapter update due to the "last read page" change
