Simplify searching by making matching logic less strict.
- do not require full match
- additionally compare by removing all non letter and number chars
Due to the reader and the "default" nav bar updating the same navbar width in the context, the grid item width calculation resulted in different grid item widths, which caused the items to "jump" after closing the reader
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
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
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
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.
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.
