After changes in e4253633c9 the transition page content wasn't properly centered anymore in the single/double reading mode depending on the applied reader settings (scale type, stretch, reader width)
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.
Due to handling an "offset spread page" change as if the "double page" mode got activated, the index of the secondary page was set, which resulted in opening the next page
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
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"
To be able to properly prevent unnecessary chapter updates, the ongoing updates have to finish, so that the apollo cache is update to date.
Otherwise, the update guard will always be false since the apollo caches chapter data is still from before the previous updates were triggered.
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
The current default value fallback logic for metadata just checks if a key is missing, or if it's value is undefined.
Since the keybinds are an object, a keybind that got newly added and wasn't saved to the metadata was never added with its default value to the object due to the metadata containing a "keybinds" key with an existing value
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
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.
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
schroda