In these modes the reader does not load leading pages to prevent the resulting layout shift on load.
This behavior prevented the retry button functionality.
Due to the way loading/failed pages are rendered and how the current page is detected, it's possible that the retry button for a leading page is visible, which resulted in showing a retry button without any functionality.
fixes#1088
When directly opening the source/extension browse page as the initial page, the metadata server settings weren't loaded yet, and thus, the default values were being used.
Thus, when opening the dialog the first time, it was showing the default selected languages.
In case the search was aborted due to already having found a match, the state was not updated.
Thus, only if the main migration was aborted and not just the "local" manga search, should it exit early on an error.
Was only noticeable in the mobile reader ui because the desktop one hides this component and uses its own logic.
It resulted in the previous/next button not being clickable because the current page component was overlaying it
The logic to detect if the horizontal scroll position was at the start or end of the element was not correct in case the readers reading direction was inverted compared to the browser themes reading direction.
example:
- theme ltr + reader ltr => worked
- theme ltr + reader rtl => broken
- theme rtl + reader ltr => broken
- theme rtl + reader rtl => worked
In case open migrations did not apply any changes, the applied migration did not get updated.
This causes unnecessary logic to run everytime the metadata are read.
The applied migration change never got stored on the server because the mutation got excluded due to incorrectly setting the "isMigration" flag to false.
This resulted in executing the missing migration everytime the metadata were read.
Regression 430939a47a
Hi team! Maintainer of _@tony.ganchev/eslint-plugin-header_ here.
I was checking the plugin's usage and notice the comment in the wrapper
you had to create about the issues with _oxlint_.
Good news is _@tony.ganchev/eslint-plugin-header_ supports _oxlint_ as
of v3.3.2. The behavior is similar to the change the wrapper introduces
by eliminating defaults but still keeps the schema and any additional
metadata in place.
This PR proposes bumping the version and eliminating the wrapper.
On a side-note, I've added this repository to the plugin's set of
ecosystem tests: https://github.com/tonyganchev/eslint-plugin-header/actions/runs/23719239156/job/69091357637
Best,
Tony
