Open temtemy opened 3 months ago
Curiously I cannot see this issue in Sharkey 2024.5.1 (via https://shonk.social/tags/Misskey). @dakkar, have you encountered this issue before and fixed it on your own end?
Anyway if you need some sort of "control" instance to compare against you can use mine which is based on 2024.3.1 (and don't worry I backported the security fix that came with 2024.5.0): https://makai.chaotic.ninja/tags/Misskey
I have just now tested Firefox 128.0.3 linux x64, both of those URLs load fine, no lockup of any kind
this is the profiler trace fo misskey.io https://share.firefox.dev/3A3Ul6H
this is the profiler trace for mk.udongein.reisen https://share.firefox.dev/4d9PRKD
Well I guess it could be a system issue too. Though still strange that it doesn't lock-up Edge, or that 2024.3.1 and below doesn't lock-up my Firefox.
Profiler trace, FWIW:
I've also created a fresh profile to rule out any about:config changes I may have made as well as any possible offending extensions (even though it's just uBlock Origin) and I can still see the lock-up.
both your profiles shows 100% CPU for several seconds doing font rendering
I suspect you have some very weird fonts installed on your machine… or the Tabler iconfont is somehow confusing your Firefox (Sharkey uses the Phosphor iconfont, it's the main font-related difference from Misskey)
https://github.com/tabler/tabler-icons/issues/476
When running Firefox Nightly, the issue mentioned in the above doesn't occur as TablerIcon is not loaded, so the freezing problem described in the issue does not happen. However, when modifying the Firefox prefs.js to load an OTL non-compliant file for testing, the freezing issue reappeared. This suggests that the problem might be related to the Icon.
Personally, I believe that considering alternative icons could be a viable solution to avoid the Firefox freezing issue.
May related: #10371 , #14271
I also have this problem on my Nightly. I wanted to investigate but unfortunately had no time. It's weird:
firefox -profile (test directory)
on terminal, it doesn't occur on anywhere at allShould probably be some parent process thing, for now I'll report on Bugzilla too.
There it is: https://bugzilla.mozilla.org/show_bug.cgi?id=1912660
There it is: https://bugzilla.mozilla.org/show_bug.cgi?id=1912660
Note: Labeled needinfo?
in bugzilla.
Note: Labeled
needinfo?
in bugzilla.
We just had a company-wide travel week which caused inactivity, sorry 🙏. I'm back to the investigation.
💡 Summary
This bug first appeared in 2024.5.0. Can be seen even when logged out (haven't tested while logged in to one that has upgraded to 2024.5.0 or 2024.7.0 yet). The hanging (which also affects the UI of the browser, which is strange because e10s/multiprocess should've prevented this and only made it so that the Misskey tab is the only one hanging) can last up to 8 seconds straight before the browser can register any action from me again.
The hanging will only happen the first time you load the Misskey in a browser session. However since I close the browser often when I'm done with it, all this hanging can annoyingly add up over time.
Example URLs:
🥰 Expected Behavior
Loading any webpage of a Misskey 2024.5.0+ instance shouldn't hang at all in a new-enough PC that is using Firefox
🤬 Actual Behavior
Loading any webpage of a Misskey 2024.5.0+ instance (I usually do the
/tags
section since I like to look at other instances' hashtag timelines for the most up-to-date info) hangs Firefox, even with a beefy PC like mine as you can see below.📝 Steps to Reproduce
No response
💻 Frontend Environment
🛰 Backend Environment (for server admin)
No response
Do you want to address this bug yourself?