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.
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.
