-
-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug: overlay stays when navigating from store to library via sidebar #11
Comments
The store page doesn't close properly anymore when navigating via the sidebar, on previous versions of SteamOS the store page did entirely close. I honestly don't think this is fixable within the plugin, unless maybe there is some way to check which tab is active in the sidebar. Because the store page doesn't close properly it is now also possible to have multiple instances of the store open at once, which causes the popup to appear and dissapear every second. Anyway, I momentarily do not have the time to research this. I might have some time in a month from now. Thanks again for the report. |
Oh yeah i encountered this issue too with multiple instances. Thank you so much for the plugin in the first case! |
I think this constant refresh was due to a small error i made. I am so sorry, i set the declaration of oldUrl on line above the necessary recursive function call and by that it got into a loop :( I made a pr for that. Now everything should work as intended! |
No worries, that's one me too for not thoroughly testing. Anyway, your previous fix hasn't reached the decky database yet, so there's nothing to worry about. I'll check this new fix out this weekend. |
Opened a PR to the plugin database, issue should be resolved when this gets merged |
Describe the bug
When navigating from the store page to any other page via the sidebar the deal overlay stays on top and prevents some buttons to be clicked.
To Reproduce
Expected behavior
The overlay disappears.
SteamOS version
3.6.9 stable
Additional context
From what i could gather, this could be because the store page is still stored inside the history object and thus the plugin still thinks that the store page is open.
I could be wrong about it.
This seems to be a minor bug tho.
The text was updated successfully, but these errors were encountered: