2029246 - Discord looks a bit worse in Firefox, for overlay-scrollbar users, if we force them to use traditional scrollbars (due to Firefox's experimental/partial ::-webkit-scrollbar support which Discord happens to trigger)

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect, P1)

Description

[Daniel Holbert [:dholbert]]

STR:

1. Ensure you have overlay-style scrollbars (in your Windows or macOS system-settings app, search for "Always Show Scrollbars" and ensure it's off. On Linux, this setting is in Firefox's own preferences UI.)
2. Join some Discord server (there's a Mozilla Common Voice one linked here for example) and view a chat room.
3. Compare how the chatroom and user-list look with about:config pref layout.css.fake-webkit-scrollbar.enabled set to true vs. false. (Reload for the pref-toggle to take effect.)

ACTUAL RESULTS:
With the pref set to true:

• the chat history area, server/channel list, and member-list have a thick traditional-style scrollbar.
• In the chat history area, the scrollbar overlaps a bit with the text-entry chat box at the bottom.
• (This is all because the site has some ::-webkit-scrollbar rules with a nonzero width, which forces us into "traditional scrollbars" mode, per bug 1977511.)

EXPECTED RESULTS:
Maybe we should avoid forcing into traditional scrollbars for this specific site (i.e. if the user has overlay scrollbars in their system settings, then we should use overlay scrollbars)?

Notes:

• The site uses ::-webkit-scrollbar which forces customizable traditional scrollbars in WebKit/Blink, but not for usability reasons (i.e. they're not doing this to avoid superimposed overlay-style scrollbars). Discord only appears to be doing this for cosmetic reasons. So the motivation behind bug 1977511 doesn't apply in this specific case.
• It seems their cosmetic goals include having scrollbars only show up when hovered (using a :hover rule for the thumb) and also **using a very thin scrollbar on the Server and Member List panes. We don't benefit from either of those outcomes, because our ::-webkit-scrollbar support is rather limited as discussed in bug 2027840 comment 3.
• So: for Firefox users who've got their system configured to use overlay-style scrollbars, it ends up being a bit backwards that Discord's styles (combined with bug 1977511) here are triggering Firefox to use permanently-visible and full-thickness scrollbars (the opposite of what Discord is going for).

SO: Bottom line... we should consider shipping a sitepatch for Discord that resets the ::-webkit-scrollbar styles for these elements, to effectively opt them out of getting bug 1977511's treatment.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: Screenshot showing behavior with pref set to true (traditional scrollbars, overlapping chat box near bottom center)

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: screenshot showing behavior with pref set to false (overlay-style scrollbars)

Here's how this looks with overlay-style scrollbars (with the pref set to false). I'm hovering the main chat area which makes the scrollbar briefly show up there (and hovering the server list and member list will make scrollbars show up there too); but otherwise the scrollbars get out of the way (which is similar to the behavior that Discord's full suite of ::-webkit-scrollbar rules end up giving in Chrome).

Comment 4

[Daniel Holbert [:dholbert]]

(I'm putting bug 1432935 as the platform-bug here -- that's the bug that covers our behavior-difference vs. other browsers here, though it's WONTFIX for the time being, because we think bug 1977511 is a reasonable middle-ground that improves most cases, even if it happens to produce a slightly issue in this specific case.)

Comment 5

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1977511

:hiro, since you are the author of the regressor, bug 1977511, could you take a look?

For more information, please visit BugBot documentation.

Comment 6

[Daniel Holbert [:dholbert]]

This would work as an intervention, I think (targeting pages on https://discord.com/):

::-webkit-scrollbar {
  width: auto !important;
  height: auto !important;
}

(Tested using Stylus.)

This restores overlay-style scrollbars, for users whose systems are configured to use overlay-style scrollbars. And for users who have traditional-style scrollbars, it'll have no impact -- they won't have seen any change from bug 1977511 on Discord, nor will they see a change from this intervention.

Comment 7

[Daniel Holbert [:dholbert]]

Note that the pref in question is Nightly-only for now:
https://searchfox.org/firefox-main/rev/6164ea4bacaeaed1f617c11911df7fc32f2e6ec2/modules/libpref/init/StaticPrefList.yaml#11258,11260

- name: layout.css.fake-webkit-scrollbar.enabled
...
  value: @IS_NIGHTLY_BUILD@

So the ACTUAL RESULTS described in comment 0 affect Nightly 151 by default (for users with overlay-style scrollbars who might be expecting to continue seeing overlay-style scrollbars on Discord), but this issue will go away when 151 moves to beta and then release. We'll have this Nightly/release difference indefinitely, until we adjust StaticPrefList.yaml to have value: true to let bug 1977511 ride the trains (i.e. when we think it's ready to ship).

Ideally we should mitigate this Discord issue with an intervention (along the lines of comment 6 perhaps) before that riding-the-trains happens.

Comment 8

[Daniel Holbert [:dholbert]]

(side note, this probably looks more noticeable on Windows than it looks in my Linux screenshots, because the traditional scrollbars are blockier on Windows.)

Comment 9

[Thomas Wisniewski [:twisniewski]]

Attachment: Bug 2029246 - add a CSS webcompat intervention for discord.com; r?denschub

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/0ca4420a13fd
https://hg.mozilla.org/integration/autoland/rev/3ed70b7650a8
add a CSS webcompat intervention for discord.com; r=webcompat-reviewers,dholbert

Comment 11

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/3ed70b7650a8

Comment 12

[mix5003]

Attachment: windows - Screenshot showing behavior with pref set to true (traditional scrollbars)

i just want to let you known that this patch not fixed behavior on windows 10.
and on windows it look more weird than linux

Comment 13

[Daniel Holbert [:dholbert]]

i just want to let you known that this patch not fixed behavior on windows 10.

This patch (and the recent change in bug 1977511 that spawned this bug) only matter for systems that have overlay-style scrollbars turned on. (Bug 1977511 made those systems switch from overlay to traditional scrollbars, for sites that use a particular CSS syntax; and then this bug here opted Discord out of that switch.)

And by default, Windows 10 defaults to traditional scrollbars, as I recall; so it wouldn't have been impacted by any of these changes. I believe your screenshot shows how Discord has always looked in Firefox on Windows 10 with default settings. (I suppose the site itself may have changed over time, but it's how the current site would always have looked in any version of Firefox on Windows 10.)

If you're on Windows 10 and you'd prefer overlay-style scrollbars there, the setting to toggle is:
Windows Settings > Ease of Access > Display > Automatically Hide Scroll Bars In Windows.
(turn that setting "on" I believe - "automatic hide" means "overlay-style")

With that Windows setting "on", I would expect that Discord (and most other sites) should show overlay-style scrollbars in Nightly -- can you confirm that?

Comment 14

[mix5003]

i not sure is it from this bug or not. but

1. toggle layout.css.fake-webkit-scrollbar.enabled can fix it
2. Automatically Hide Scroll Bars In Windows is already set to ON (i not sure i set it, or it default from windows.)

https://youtu.be/skS_JZxS5vM

Comment 15

[Daniel Holbert [:dholbert]]

Interesting, thanks for clarifying that & for the screencast. I retested on Ubuntu (with overlay scrollbars enabled) and it works as-expected there. I don't have Windows 10 available but I can test on Windows 11...

Comment 16

[Daniel Holbert [:dholbert]]

So on Windows 11, I can reproduce unexpected traditional-style scrollbars in one specific situation.

On my Windows 11 environment on my Surface Pro 7:

1. Launch Nightly, load discord chat room --> overlay scrollbars. (expected)
2. In about:config, toggle layout.css.fake-webkit-scrollbar.enabled to false. Reload discord. --> overlay scrollbars. (expected)
3. In about:config, toggle layout.css.fake-webkit-scrollbar.enabled back to true. Reload discord. --> traditional-style scrollbars (UNEXPECTED)

So far I haven't been able to reproduce without intentionally twiddling the pref like that, so I think that pref-twiddle is necessary; but it also might just not-entirely-deterministic.

These steps don't reproduce the issue on Ubuntu (dual-booted on the same machine); only on Windows 11.
If I'm interpreting mix5003's comments/screencast correctly, they get traditional-style scrollbars without needing to do my pref-toggling steps (though toggling the pref to false does of course make the issue go away for them).

Theories:

• maybe there's some race condition in which stylesheet "wins" here (not sure if our intervention stylesheets are reliably higher-precedence than website's stylesheets, and maybe we sometimes insert later/earlier in the cascade?)
• maybe our intervention pref-check is somehow reading the wrong/out-of-date value of the pref here? (That might explain my observations, but not mix5003's observations...)
• or maybe we've got some other nondeterminism in how we manage this scrollbar state...

Comment 17

[mix5003]

i think it because Bug1977511 not support all ::-webkit-scrollbar
eg. the example in that issue still not change scrollbar width https://jsfiddle.net/dholbert/L83ejpvd/
i try to set width,height to 3px/50px and nothing changes

but it changed @supports selector(::-webkit-scrollbar) to be true.

so discord is confusing. i found that in Discord the body tag has class that base on layout.css.fake-webkit-scrollbar.enabled flag
if layout.css.fake-webkit-scrollbar.enabled = false the discord use class no-webkit-scrollbar
if layout.css.fake-webkit-scrollbar.enabled = true the discord use class has-webkit-scrollbar

i think discord detect browser and already handle scrollbar case in firefox.
but this patch make discord assume that firefox already support ::-webkit-scrollbar then use it full feature.

Comment 18

[Daniel Holbert [:dholbert]]

(In reply to mix5003 from comment #17)

i think it because Bug1977511 not support all ::-webkit-scrollbar
eg. the example in that issue still not change scrollbar width https://jsfiddle.net/dholbert/L83ejpvd/
i try to set width,height to 3px/50px and nothing changes

That's a known limitation for now. See the last part of bug 2027840 comment 3 for some context/explanation. Basically, we treat any nonzero explicit width as forcing traditional scrollbars (but we don't let you customize the width).

so discord is confusing. i found that in Discord the body tag has class that base on layout.css.fake-webkit-scrollbar.enabled flag
if layout.css.fake-webkit-scrollbar.enabled = false the discord use class no-webkit-scrollbar
if layout.css.fake-webkit-scrollbar.enabled = true the discord use class has-webkit-scrollbar

Aha! That's an interesting clue. (For me, it's actually the <html> element, not the <body> -- but yeah, that might be involved here.)

but this patch make discord assume that firefox already support ::-webkit-scrollbar then use it full feature.

Right, bug 1977511 had that effect. Nonetheless, the intervention added in this bug here were intended to override that (and they do successfully override that in some cases, but not reliably).

Maybe we just need to add !important, if the site's rules are being treated as more specific and are "winning" over the intervention's CSS...

Comment 19

[mix5003]

after i try digging a while. i think discord set has-webkit-scrollbar or no-webkit-scrollbar base on this javascript window.CSS.supports('selector(::-webkit-scrollbar)')

and it use css differently base on that class. if it use no-webkit-scrollbar it will use scrollbar-width:none/scrollbar-width:thin to make scrollbar look not ugly.

.none_d125d2::-webkit-scrollbar {
  height:0;
  width:0
}
.no-webkit-scrollbar .none_d125d2 {
  scrollbar-width:none
}

and

.thin_d125d2::-webkit-scrollbar {
  height:8px;
  width:8px
}
.thin_d125d2::-webkit-scrollbar-track {
  background-color:var(--scrollbar-thin-track);
  border:2px solid var(--scrollbar-thin-track);
  border-color:var(--scrollbar-thin-track)
}
.thin_d125d2::-webkit-scrollbar-thumb {
  background-clip:padding-box;
  background-color:var(--scrollbar-thin-thumb);
  border:2px solid transparent;
  border-radius:4px;
  min-height:40px
}
.thin_d125d2::-webkit-scrollbar-corner {
  background-color:transparent
}
.no-webkit-scrollbar .thin_d125d2 {
  scrollbar-color:var(--scrollbar-thin-thumb) var(--scrollbar-thin-track);
  scrollbar-width:thin
}
.no-webkit-scrollbar .thin_d125d2.fade_d125d2.scrolling_d125d2,
.no-webkit-scrollbar .thin_d125d2.fade_d125d2:hover {
  scrollbar-color:var(--scrollbar-thin-thumb) var(--scrollbar-thin-track)
}

Comment 20

[Hiroyuki Ikezoe (:hiro)]

The reason why the intervention doesn't work on Windows 10 is, on Windows 10 overlay scrollbar is never enabled, but since bug 1977511, @supports selector(::-webkit-scrollbar) is evaluated as true thus the scrollbar-width styles have never been specified there. We might be able to evaluate the @supports only if the system overlay scrollbar style is enabled, but I guess it will require some amount of work.

Note to Daniel, I am leaving the NI to you here, feel free to drop it if you think ^ above comment makes sense.

Comment 21

[Daniel Holbert [:dholbert]]

Ah, thanks! So probably our intervention here should be a bit fancier, to add the no-webkit-scrollbar class and remove the has-webkit-scrollbar class.

Or we could reconsider whether we want to claim @supports, given that sites use it in this way, and maybe we consider our behavior to be more of a heuristic than real "support" in the way that a web developer checking @supports would think about it at least...

Comment 22

[Daniel Holbert [:dholbert]]

(retaining my needinfo as a reminder to look into the inconsistent win11 behavior that I observed)

Comment 23

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1977511

Comment 24

[mix5003]

i want to say that after bug 2031468 my issue still exists, scrollbar stll ugly in windows 10

when i use Devtool to add this style

@supports (selector(::-webkit-scrollbar)) {
  body {
    display:none;
  }
}

in css @supports (selector(::-webkit-scrollbar)) is now false.

but for discord it use js to check is it support or not window.CSS.supports('selector(::-webkit-scrollbar)')
and it that statement return true.

so for now in css it said not support, but for js it still support.
so discord class detector still not correct.

sorry i can not comment in bug 2031468

Comment 25

[Daniel Holbert [:dholbert]]

Thank you for letting us know! hiro, mind taking a look?

Looks like the JS CSS.supports() API might not be respecting the per-domain blocklist?

Comment 26

[Hiroyuki Ikezoe (:hiro)]

Filed bug 2040196.

Comment 27

[Daniel Holbert [:dholbert]]

(In reply to mix5003 from comment #24)

i want to say that after bug 2031468 my issue still exists, scrollbar stll ugly in windows 10

Would you mind testing again in tomorrow's Nightly? (with the Nightly released on Wednesday, 2026-05-20)

That build should include the fix for bug 2040196, which hopefully addresses comment 24. (I just tested a per-push-build [not a Nightly] that includes that bug's fix, and I confirmed that window.CSS.supports('selector(::-webkit-scrollbar)') returns false in my Web Console, in a https://discord.com/ tab, while returning true for other tabs.)

Comment 28

[mix5003]

Attachment: discord_fixed.png

fixed now. scrollbar is slim and show when hover only.

Comment 29

[Daniel Holbert [:dholbert]]

Hooray! Thanks so much for the help in thoroughly diagnosing/fixing this. :)

Closing as FIXED by bug 2040196.

Comment 30

[BugBot [:suhaib / :marco]]

The patch landed in nightly and beta is affected.
:twisniewski, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval. Also, don't forget to request an uplift for the patches in the regression caused by this fix.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox152 to wontfix.

For more information, please visit BugBot documentation.

Comment 31

[Jan Gerber]

[removed]