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
