The "status" has to be a number.
Seems like there was some bug in graphql-kotlin since it did not return an error previously and with updating to the latest version it now returns one
Compared to LTR were the "scrollLeft" value is >= 0, for RTL it's <= 0 which was not handled and thus on applying the inertia effect, "scrollLeft" was always set to 0 due to preventing negative values
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
The action to perform which gets determined on a tap zone click is always in the correct direction, thus, the direction for the "openPage" call has to be forced to be "LTR" to prevent inverting the direction
- 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
Update ui versions to the latest compatible versions, they were pointing to the first version that updated the minimum server version while they needed to point to the previous commit of the commit that changed the minimum server version to a higher version.
Updated ui versions that pointed to non-existing revisions.
Multiple commits at once were pushed to the master which caused the revision of the mapping update commit to not be a release
The mutation to add chapters to the download queue returns the current download queue.
Thus, the local queue already includes the new downloads and adding them blindly in the download subscription will cause them to be in the local queue twice.
The total size was the sum of all categories, which could include duplicates, since manga can be in multiple categories.
This still will show an incorrect number, because server side there is the same issue with the "mangas" query including duplicates in the total count, however, once this is fixed, the correct count will be displayed
