In case the current chapter should get deleted after reading it, it only worked in case it was already marked as read due to checking the read status from the chapter itself instead of the chapter update patch input
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.
Due to the scrollbar disappearing the dimension of the manga grid items changed which caused them to get unmounted and re-rendered again.
This then caused the dialog to get closed since the dialog is rendered in the manga grid item component
For large download queues this makes the app unusable.
At the moment this is not needed anyway and once it is, it needs to be improved and only be done in the "download queue" page since the queue is only use there
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
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
In case the outdated metadata get successfully deleted and the updated metadata fail to commit, metadata gets lost, due to not being able to apply the migrations again since the outdated metadata have already been deleted
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.
While iOS does not support customizing the scrollbar, it seems there is a bug when the width and/or height gets set.
(see MediaQuery#getScrollbarSize) When inserting an empty div with forced scrollbars and calculating the scrollbar size, for some reason on iOS it has a scrollbar that affects the available size, which is not possible.
In case no keys had to be deleted it always returned an empty object which broke the whole metadata migration and resulted in the final metadata to always fall back to the default values
The "appliedMigrationId" was converted to it's index of the "METADATA_MIGRATIONS" and then was compared to the "migration id" which starts at 1 instead of 0
The wrong chapter list was used.
"chapters" is the filtered list of chapters, which e.g. doesn't contain duplicated chapters.
This caused the "chapter source order" to potentially be higher than the total chapters of the manga.
The end result of this was that the fetched state of the pages wasn't properly detected causing errors due to rendering the reader before it was in the correct state
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
The default timeout of "notistack" is 5s by default, however, this makes it more clear and also prevents any behaviour changes in the future, in case the default timeout gets changed
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
schroda