iconoclasthero
commented
2 weeks ago This is going to be very difficult to duplicate but maybe someone else will stumble upon this with the same issue...
There's a way to tell if a user is using a shortcut, maybe? https://stackoverflow.com/questions/16947226/how-to-tell-if-webpage-is-running-in-chrome-application-shortcut-mode but with the self-hosted nature of abs, that's not particularly relevant to figuring out how many people are using that method of browsing.
nichwall
What happened?
I've taken great advantage of the Google Chrome (current: 124.0.6367.207) Shortcut windows. Not sure what else one would call them, but Chrome ⋮ > Save and Share > Create Window > ⌧ Open as Window. I also have the built-in tab suspension enabled. With audiobookshelf (abs) like a couple dozen other websites, the shortcut window uses the favicon for the desktop icon making the webpage more like an app which blurs the line with a PWA(?).
After leaving abs open in a shortcut window for an undetermined time (on the order of several hours to a dozen hours), browser performance in other tabs will noticeably degrade: primarily, if I am trying to read a document that extends beyond the current window, when I try to scroll there will be unacceptably long lags in responsiveness that make it impossible to navigate the document and read it properly.
Hypothesis: The reason I'm only seeing it in the shortcut window is because of the tab suspension, i.e., when I leave abs in a regular tab, it is suspended, but the shortcut windows do not get suspended. As such, the hypothesis is that the reactive portions of the JS end up causing issues. (There are also issues with gmail and google voice and some other google sites and they're currently included in this hypothesis). The sheer number of idle wakeups vs. everything else seems to be in line with this hypothesis, though that could be merely correlation.
FWIW, as I was typing the above, it just happened again. Switching to the abs tab (did not have to close it) fixed the problem, something I believe I observed last night, but I closed the window before I could really explore it. The sheer number of idle wakeups in the task manager supports the hypothesis insofar as abs is definitely not sitting idle.
What did you expect to happen?
Ideally there shouldn't be cross-talk between two browser windows, that's (what I thought was) the point of the chrome sandboxing.
Steps to reproduce the issue
Audiobookshelf version
v2.9.0
How are you running audiobookshelf?
Docker
What OS is your Audiobookshelf server hosted from?
Linux
If the issue is being seen in the UI, what browsers are you seeing the problem on?
Chrome
Logs
Additional Notes
Extensions: I spent a good deal of time trying to isolate this problem to my extensions and had a fantastic time rationalizing all of them. I now run with far fewer and the ones that remain are generally only active on click...this includes the adblock/cookie extensions I normally use, ghostery and ublocik origin. As part of this effort, I switched to router-level ad blocking on my OpenWRT Cudy. I'm not unwilling to look at them further, but I am fairly sure that will not be a profitable search.
Other tabs: I don't browse anything in isolation... I have lot of tabs open all the time (116 now) so it isn't really instructive to try this in isolation. First, if it happens, so what, I'll never do that IRL, Second, I'll never leave my machine in that state long enough for the problem to develop...