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 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.
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.
- 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
When increasing the window, the main reader container did not immediately reflect the change and was still smaller than the available width.
In case the viewed pages were filling the full width, this then caused the horizontal scrollbar to appear until the resize action was finished.
Ensure the restored page index is based on the page index at the start of a resize event to maintain consistency.
At least in the continuous horizontal mode, it was possible to sometimes cause the page to change while resizing.
Ensure fonts are properly trimmed and stripped of quotes to maintain consistency and avoid potential loading issues.
The default fonts defined by MUI e.g., are set as "\"Roboto\", \"Helvetica\", \"Arial\", sans-serif" which lead to an invalid font request.
Fixes#1012
After the slice states got reset, the base reset function just reverted all those resets and only reset the base states in the store (manga, scrollbar, ...)
