OS scroll bar visibility setting not read on page load in v153
For some scrollables, v153 doesn't respect the Mac OS setting to hide scrollbars unless scrolling on page load. If that OS setting is adjusted after the page is loaded, then the page respects it again until refresh, so there's apparently some sort of race condition going on where it's not reading the setting in time before the page loads?
This is not a problem in v152. I downgraded back to v152 and it's working again.
Chosen Solution
That's actually a great example as it's open sourced, with clear dependencies and no ugly compressed content to sift through and pretty reproducible. I can see the difference right away. It may end up as webcompat thing, as they do some sizing — and actually changing the OS prefs forces them to recalculate so that's when the site catches up. (Nice find!)
You can actually compare yourself, there's a preference key:
layout.css.fake-webkit-scrollbar.disabled-domains
(don't ask about the existing entries;D) where if you add your site as another exception at the end, like I did with 127.0.0.1, the 153+ apply the 152– rules to those domains and it fixes that local app immediately.
I suspect it comes from their https://github.com/SillyTavern/SillyTavern/blob/release/public/lib/jquery-ui.min.js when if you search for "scrollbar" that decade(s) old library tries to do some magic of its own that's probably too outdated for today. I'll keep looking into the related bug timelines. Basically unless a major site is broken, this will be left as–is for the time being. If you're MS or G you may get special treatment bugzilla.mozilla.org/2058432 …
That said, the allowlist–based approach is probably the best to iron this out over time — if you were mostly concerned about your local app, you can exempt it in the pref in the current release, and if/when you encounter any similar breakage in public sites you use, please do report that for tracking/visibility purposes to see if there's a good pattern how to exclude some older sites/libraries from that (or intervene with user agent sniffing on their end etc.) — thanks!
All Replies (5)
Can you share a public reproducible example? There were some scrollbar changes related to firefox.com/firefox/153.0/releasenotes/#html5 so some compatibility fallout is expected, but this sounds like OS–integration impact that was not intended — an example would help to understand the exact rendering path taken for the affected overflow, thanks!
Um. Kinda? 😅 I'm back on v152 atm and don't recall the online site where I spotted what was going on, but I can try to upgrade back to v153 and play around with it in a bit. Unfortunately, the main place I noticed it was offline: SillyTavern. Don't wanna make you have to download a full GitHub release just to test this, sorry...If it helps any, the scrollables there which are always visible in v153 (until the OS setting is toggled live) are:
and description (plus possibly relevant and probably not so relevant CSS)
though I'm no web dev so maybe all those CSS links are equally unhelpful lol
Chosen Solution
That's actually a great example as it's open sourced, with clear dependencies and no ugly compressed content to sift through and pretty reproducible. I can see the difference right away. It may end up as webcompat thing, as they do some sizing — and actually changing the OS prefs forces them to recalculate so that's when the site catches up. (Nice find!)
You can actually compare yourself, there's a preference key:
layout.css.fake-webkit-scrollbar.disabled-domains
(don't ask about the existing entries;D) where if you add your site as another exception at the end, like I did with 127.0.0.1, the 153+ apply the 152– rules to those domains and it fixes that local app immediately.
I suspect it comes from their https://github.com/SillyTavern/SillyTavern/blob/release/public/lib/jquery-ui.min.js when if you search for "scrollbar" that decade(s) old library tries to do some magic of its own that's probably too outdated for today. I'll keep looking into the related bug timelines. Basically unless a major site is broken, this will be left as–is for the time being. If you're MS or G you may get special treatment bugzilla.mozilla.org/2058432 …
That said, the allowlist–based approach is probably the best to iron this out over time — if you were mostly concerned about your local app, you can exempt it in the pref in the current release, and if/when you encounter any similar breakage in public sites you use, please do report that for tracking/visibility purposes to see if there's a good pattern how to exclude some older sites/libraries from that (or intervene with user agent sniffing on their end etc.) — thanks!
I think that was literally the only key I didn't wanna touch in my testing because I had no idea how that one site had ended up in there, and I assumed it was something past me did a bajillion years ago and forgot! I'll do that and keep y'all posted if any more widely relevant site breaks, thanks ^_^
The sense check is basically: if the pref is bold, that's a value that normally doesn't ship with the build (in layman's terms: you most likely customized it; but it could have also been a remote flip, compat intervention, addon doing its job etc. so it's not that simple) — and in that case it will have the "arrow" button to revert it back to factory defaults. If it's not bold, it means it comes that way out of the box, incl. any weird values that might have been set for bizarre reasons and shipped in builds;D
There's some movement regarding reports from many legacy and private interfaces so it seems the new default will get un–shipped and only selectively flipped for those services that genuinely really need it these day, you can watch bugzilla.mozilla.org/2061547 for how that unfolds…
You must log in to your account to reply to posts. Please start a new question, if you do not have an account yet.