After all pages had been loaded, the revalidation request of the first page caused the loading placeholder to not disappear anymore.
This was only a visual bug and did not affect the actual functionality.
Everytime the metadata got updated, unchanged values could cause rerenders because their reference changed.
This happened e.g., for the "customThemes" which caused the MUI theme to get recreated resulting in all components to rerender due to the theme context change.
In continuous reading modes the pages are always rendered regardless of if they are visible or not. This is the case to prevent layout shifts when prepending pages while scrolling up.
However, this means that a pages "load priority" and its "should load" flag changes everytime the current page changes, which causes unnecessary rerenders.
The "load priority" and "should load" flag do not matter once a page has been loaded and therefore should stay consistent once loaded.
This caused the reader to "jump to random pages" because it caused the image to get unrendered and rendered again, leading to layout shifts.
This issue existed already for a long time but could only rarely be observed because of the hacky "cache check" logic.
The changes from 9ed05f3fc0 caused this issue to be consistent in case the new service worker could not get installed due to not meeting the required installation prerequisites. If that was the case, the cache check always returned false causing the above-described behavior.
fixes#929
The server is not requesting these images through an extension; thus, it is not a problem to send them directly to the server since there is no problem of getting the server "stuck" due to extension rate limits.
Improves the image request logic by making it possible to check if an image is cached.
In case an image is cached, it does not need to be put into the image queue because it won't be sent to the server.
When scrolling really fast, the delta value could increase, which leads to incorrect trackpad detection, because the delta value is not consistent over consecutive scroll events
In case the connection got lost and the client reconnected again, there is a possibility that the auth token is expired. This will lead to the subscription to fail due to being unauthorized.
This, however, does not close the connection and the heartbeat messages are still being sent and received.
Thus, after refreshing the token, the connection is still alive but not authorized, which is the same as not having the connection open.
In case the tab gets resumed, it does not get fully reloaded but does reexecute js.
This caused the initial timestamp to get overwritten and lead to the forced reload detection to be incorrect, because it assumed that the app just got loaded.
In case the previous page in the history should be ignored, the back button just went back to the root page (library).
Instead, it should try to go back to the next page in the history until there is no page to go back to anymore.
Most cases were preventing some requests from getting triggered. However, this is not necessary anymore since with 6636cc66b1, this is handled globally now
With 12ef012e4b this has no benefit anymore, because the app now always checks if authentication is enabled by the server first before any other request can be sent.
- Reset "requires auth" flag in session storage for reset on tab refresh
- Fix context los for resolving, rejecting queued request
- Process queued requests after successful login
Regression 6636cc66b1fixes#1028
In case it's still unknown if auth is set up on the server, only the initial request to detect this should be sent. Since all other requests will also just fail, they should be blocked until the auth initialization is completed.
While the access token is getting refreshed, no request will succeed since the access token is expired; thus, they should not be sent.
A forced refresh is only necessary in case the webui was already loaded and thus, still uses outdated files from the old version.
In case the app just got freshly opened in a tab, a refresh is not necessary because the latest files are already being used.
In that case, just show an update dialog which won't force a tab refresh.
- Retry on all disconnect events
- Retry infinitely
- Cap retry backoff strategy delay at heartbeat interval (20s)
- Recreate client in case reconnecting isn't working
Fonts get loaded dynamically through "ThemeFontLoader"
Fixes#1016 along with 8c50b33a93.
See explanation of linked commit.
The problem with this import was that MUI by default uses font weight 300, 400, 500 and 700.
For some reason importing all font weights caused the issue of the linked ticket while importing only the necessary font weighs fixed it.
- Extract all fonts and all font weights from the theme
- Load all required weights per font
Not clear 100% what is the root cause. But the (missing font weights?) loaded fonts did cause some incorrect initial tooltip width measurement that lead to an out-of-viewport tooltip placement. Depending on the tooltip text and the monitor (size + scaling) the measurement might result in a fractal width. In case the tooltip was placed right on the horizontal end of the viewport this then lead to a horizontal scrollbar which potentially caused an additional vertical scrollbar resulting in a layout shift.
Once the tooltip was rendered, the placement got corrected. Depending on the mouse placement, however, this issue caused an infinite loop of appearing and disappearing scrollbars.
Fixes#1016
Caused issue for some languages, e.g., for all the different chinese languages, which are not all specified in the "IsoLanguages". These languages all incorrectly used the standard native chinese name which resulted in multiple different source groups with the same group name.
schroda