Skip to content
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

[Sm-126esr] GUI: Scrollbar related flags non-functional #985

Open
Vangelis66 opened this issue Oct 29, 2024 · 2 comments
Open

[Sm-126esr] GUI: Scrollbar related flags non-functional #985

Vangelis66 opened this issue Oct 29, 2024 · 2 comments
Labels
Minor bug A bug that does not break the browser

Comments

@Vangelis66
Copy link

Describe the bug

In all releases thus far of Supermium 126, I find that all three scrollbar-related internal flags (inside chrome://flags/) do NOT have the desired effect when set to Enabled 😞 .

To Reproduce
Steps to reproduce the behaviour:

(Sm-v126-r4_32 was used)

  1. Go to chrome://flags/
  2. In the Search flags bar, input "scrollbar"; you'll get below three results:

sbf

  1. Set, e.g., the first two of them to Enabled, then, as prompted, relaunch Sm-v126
  2. Load e.g.
    https://github.com/win32ss/supermium/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc
    and scroll down slightly; notice the appearance of the srollbar hasn't changed:

126

Expected behavior
A clear and concise description of what you expected to happen.

In Sm-v124/122/121, the Enabled flags produce the advertised effect, as shown below:

124

Screenshots
If applicable, add screenshots to help explain your problem.

See the ones above...

Desktop (please complete the following information):

  • OS: Windows Vista SP2 x86, fully updated to EoS
  • Bitness of browser: 32-bit, since my OS is x86 😉

Additional context
Add any other context about the problem here.

This isn't the end of the world, obviously 😄 , but my OCD gets worse with things like that (and there are many "such things" in v126, but I'll speak some other time about (some of) the rest 😉 ...

Thanks again for this browser 👍 !

@Vangelis66 Vangelis66 added the Minor bug A bug that does not break the browser label Oct 29, 2024
@win32ss
Copy link
Owner

win32ss commented Nov 2, 2024

There is an issue with non-propagation of some features to renderer processes where they are ultimately implemented. The dark modes were previously affected, and so is this one.

@Vangelis66
Copy link
Author

Vangelis66 commented Nov 2, 2024

Hi 😄 ; the mentioned scrollbar flags work as designed in my "dirty" Sm-v124 profile.
In my dirty "Sm-v126" profile they simply don't; I tried --no-sandbox in that profile, without any change; I was also sad to find that running the dirty "Sm-v126" profile with --single-process made the browser immediately crash 😢 ; I can't be bothered to discover why (an extension, a cmdline flag, an internal flag?), because I'd never run the browser in single process here...

FWIW, I created a (temporary) fresh v126 profile and on that one the scrollbar flags WORK only when --single-process is issued; I always also use #force-dark-mode in my Sm profiles, this flag doesn't seem to affect the scrollbar flags (they do work when --single-process+--force-dark-mode are issued together).

As a workaround to this bug on my dirty Sm-v126 profile, and only for web content (because "those flags" also work in chrome:// pages in v124 and earlier), I'm using the Stylus userstyle ultimate-scrollbar 😉 ...

Regards.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Minor bug A bug that does not break the browser
Projects
None yet
Development

No branches or pull requests

2 participants