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.
