In case the "depth" of the initial opened app page was greater than 2 it was possible to get stuck in a loop of using the back button twice from the initial page to the previous page and back to the initial page...
Instead, in case a page with a greater depth than 0 is opened, the library should just be opened when using the back button.
This way the back button actually behaves like it's intended, as an app back button and not like the browsers back button
In case the initial opened page had a "depth" of 2 or more, using the back button twice lead to the initial page to get opened again instead of decreasing the depth of the url.
E.g. in case the reader was opened as the initial app page, closing the reader and then clicking the back button caused the reader to get opened again instead of going "back" to the library.
It's possible that the "trackProgress" mutation of the "updateChapters" mutation fails, which then would lead to the "mark as read" and "delete chapter" mutation data to be omitted, thus, preventing the cache from being updated with the received mutation data response
Due to the MangaGrid getting unmounted when changing the category, the "y overflow" value got reset to "auto" which caused the scrollbar from disappearing and immediately reappearing again.
This caused the site content to slightly "jump" due to the increase and immediate decrease in is width.
Related commit 871908eba9
Due to the Checkbox being smaller than the vertical menu icon the ChapterCard was reduced in height, which caused the chapters in the list to jump up sightly.
This issue was introduced by 0ab6549a20 due to changing the line height of the chapter name
Due to setting the html elements "y overflow" to "auto" after a manga grid got unmounted (d21521625b), MUIs "scroll lock" of "modals" was broken in the reader.
For some reason the scrollbar does not get locked and instead, due to the added padding, the pages jumped slightly upward.
MUI uses the "body" element to lock the scrollbar, and thus, using this element as well instead of "html" fixes this problem, since the manually set "overflow" value gets overwritten by MUI and thus, won't mess with its logic.
Makes more sense compared to the previous logic - to only show the scanlator in case "skip dupe chapters" setting was disabled and duplicated chapters existed - which was also not properly implemented, to be always able to tell if chapters of different scanlators might be viewed
In case "skip duplicated chapters" is enabled and the next chapter is from a different scanlator, the initial opened chapter should still be used to remove duplicated chapters.
Otherwise, the original scanlator would get lost and the scanlator of the next chapter would get used, which was only a fallback chapter, because the initial chapters scanlator did not have a next chapter.
The summaries can include invalid html tags which caused issues when trying to render them since these tags do not exist.
Known issue:
The invalid tags will get escaped, however, when they include a space (e.g. "<Author's Notes>" everything after the space is missing (e.g. will be "<Author's>")
It's possible that the queue only contains a failed invalid (does not exist anymore in the database) chapter which then causes graphql errors.
In this case the queue was considered empty which prevented it from getting cleared.
Without being able to clear it, the error could not be fixed.
The available update info is only supposed to be shown in case the auto update is disabled, but instead, it was only shown in case auto update was enabled
In case images are requested of a slow source, aborting image requests that are already in progress will cause the server to take forever for new source image requests because it's still processing the aborted image requests.
Thus, aborting ongoing image request might cause more harm than good, since the server will basically become "unresponsive" for new images requests of this source.
By only aborting pending requests, that have not been sent to the server yet, new image requests will only be handled once the active requests are done, preventing the server from getting spammed with image requests that potentially are just getting aborted immediately again (e.g. due to scrolling quickly in the source browse page), but still will be handled by the server, blocking new requests
The local server settings were not shown in case the actual server settings were loading or the request failed.
E.g. in case the "server url" was set to an invalid url, it was not possible to correct it again
Server settings request loading and error state were never handled, thus, in case this request was still loading or failed, instead of showing the proper page state, the missing repo info was shown
In case the manga wasn't loaded immediately, trying to access the trackRecords totalCount caused a TypeError because the initial manga object did not specify it
In case a manga was completely downloaded, the grouped chapters did not contain a list for the specific manga id, resulting in an TypeError due to trying to use the array as if it was not undefined
Changed with 0c4ce2c9c5, but it does not work because the chapters state could have changed in the meantime, changing the chapters included in the query response, which is not represented by the cached query
schroda