In case the "dialog to inform about available server updates" was disabled, it also prevented the "dialog to inform that the server has been updated" from being visible.
In case chapters of the same manga had been fetched at the same time, they were sorted by their source order ascending instead of descending, which caused the newest chapter of that manga to be farther down instead of being the first
In case an uninitialized manga was opened from the library, the manga and its chapter list got refreshed.
However, the chapter infos (e.g. unread, downloaded count, etc.) were not requested with the chapter list mutation, which resulted in this information to be missing
Manga can be added to the library while they have not been initialized yet.
Thus, for these cases, the reader is broken in case it gets opened.
To prevent this, the continue read button should not be shown in the library
The height of the app bar was lost after opening and closing the reader because ref was already created but its current value changed.
However, the ResizeObserver was still observing the old element.
Updated other hook usages, which might cause the same issue, as well
Duplicates were ignored in case they were already detected before.
However, this did not work as intended and ignored valid duplicates in case they were already detected for a different title
With the changes from df006bb348, the requested download queue data changed not matching the previously used type.
The unnecessary cast then hid the tsc issues during compilation
The sort order was switched and instead of ASC it was sorted DESC and vice versa.
This was caused because the server returned the list (most of the time) in ASC order by chapter number.
Additionally, the list was overall never properly sorted by chapter number and only worked because the server (most of the time) returned it in the correct order by chapter number.
However, this is not guaranteed at all since the server sorts in ASC order by the chapter id by default
In case there were no chapters to migrate the read or bookmark status, a request with an empty list was sent to the server.
This caused an exception on the server which resulted in a request failure which at the end caused the migration to fail
Caused an infinite loop, because in case the Reader was the initial opened page, got closed and the back button was pressed, the Reader just got opened again.
This happened because in case it was the initial opened page, closing the Reader did not use the browser back navigation and instead opened the Manga page, resulting in it to be pushed in the history stack with the Reader being the previous page
The readers history stack was different to the one from the rest of the app, resulting in an infinite loop when using the closing the reader and using the back button in the manga page, since the back button just opened the reader again.
Regression introduced with 4bb458778e
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.
schroda