In case the transition pages are disabled and the first/last chapters previous/next transition page was visible, clicking the next/previous tap-zone caused the chapter to jump to the first page of the current chapter.
Regression f0f740f4af
The changes from 642708b8b3 didn't consider the case were the chapter change was triggered due to scrolling to the unloaded previous/next chapter with infinite scroll
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.
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
ReaderControls#useUpdateCurrentPageIndex:
On a page change the chapter update needs to be always queued since the deletion of downloaded chapters while reading logic is in the "ReaderService#updateChapter" function.
Thus, when the update is prevented here, this logic would never get triggered.
ReaderService#useUpdateChapter:
In case the read status or lastPageRead of a chapter did not change, the update was not triggered.
However, there might still be chapter downloads that need to be de deleted, which was never handled in such a case.
Chapter numbers can change from e.g. "1" to "2.1" and in that case missing chapters were detected.
However, with these weird chapter numbers it's not clear if a chapter is actually missing or not, thus, they should not cause a missing chapter warning
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
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
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
Convert clicks on the progress bar in such a way, that there is a "padding" around the page "dots".
Thus, e.g. even if the click was actually for page 1, if it is inside page 2 padding, it will behave like it was a click for page 2
When e.g. enabling the "offset spread pages" setting the current page index was still the one of the secondary page, which then caused the first page to get skipped.
In case "endReached" is force set to "true" the chapters last page index should always be set to prevent 2 chapter updates
- 1. for second to last page, read true
- 2. last page, read true
This only happens in "continuous pagers" which have to handle cases where the end of the last page is already visible while the last page itself is too small to ever get set as the "current page index"
In case the first/last page was opened and a specific page was selected, instead of opening the page, the previous/next chapter was opened due to incorrectly handling the page change as a previous/next page change
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
