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
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.
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
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
Depending on the set reader width, the auto margin of the images took effect and separated the double pages.
However, for double pages, only the margin left/right depending on the page should be set, to properly center the pages without a gap between them
Depending on the screen size and e.g. the set "reader width" pages might not have filled out the full img elements size due to "object-fit contain".
This was caused due to the image wrappers flex container "align-items center" which slightly reduced the images width to some ".xy" number (e.g. instead of wrappers width 258px, the images were something like 257.83px)
In case two pages were displayed with different dimensions, the bigger page might take up more than 50% of the screen.
In this case the bigger page got limited to 50% which caused in to unintentionally get reduced in size
There was an issue where one had to click twice at the end of a chapter in the "double page mode" to get to the chapter transition page.
This was caused due to setting the "primary page index" as the "current page index" and thus, when opening the next page, it got changed to the "secondary page index". However, this page was already visible and therefore, there was no visual change.
Due to the way the pages got scrolled into view, the current page was not changed to the new page.
This then prevented the previous/next page to get opened via click/hotkey actions
- open from outside reader
- is read
- yes: 1st page
- no : last read page
- inside reader via
- chapter selection: first page
- previous chapter : last page
- next chapter : first page
