I looked at the current dark-mode scrollbar styling in server-core/src/main/java/io/onedev/server/web/page/base/base.css:

.dark-mode * {
	scrollbar-color: rgb(51, 52, 75) rgb(37, 38, 55);
}
.dark-mode ::-webkit-scrollbar {
	border-color: rgb(37, 38, 55);
	background-color: rgb(37, 38, 55);
}
.dark-mode ::-webkit-scrollbar-thumb {
	background-color: rgb(51, 52, 75);
}

There is no custom :hover rule in OneDev. The stronger “hovered” look is almost certainly the browser’s built-in behavior (especially Chromium): when scrollbar-color is set, the idle thumb is rendered more faintly and becomes full-strength on hover. Light mode has no custom scrollbar-color, so it follows the OS/browser default.

A few clarifying questions before an implementation plan:

1. Desired idle vs hover behavior in dark mode?

   • A) Idle thumb uses today’s hover appearance, and hover does not change further (same color always)
   • B) Idle thumb uses today’s hover appearance, but hover may still brighten slightly for affordance
   • C) Something else (please describe)

   Pros of A: Matches light-mode “no distinct hover color” expectation; simplest mental model. Cons of A: Removes a subtle affordance that the thumb is interactive. Pros of B: Keeps a small hover cue. Cons of B: Still two colors; may feel inconsistent with light mode. Recommendation: A — matches your stated goal and light-mode parity.

2. Scope?

   • A) Global dark-mode change for all native scrollbars (the base.css rules above)
   • B) Only specific areas (e.g. side panels, code viewers) — please name them
   • C) Also revisit PerfectScrollbar / CodeMirror custom scrollbars for consistency

   Pros of A: One small CSS change; consistent site-wide. Cons of A: Custom widget scrollbars may still look different. Pros of C: Visual consistency everywhere. Cons of C: Broader change, more testing. Recommendation: A first; follow up with C only if those widgets still feel wrong.

3. Browser expectation?

   • A) Fix primarily for Chromium/WebKit (where idle vs hover divergence is most noticeable with scrollbar-color)
   • B) Must look identical in Firefox as well
   • C) No preference as long as dark-mode idle contrast improves

   Pros of A: Focuses on the reported problem with the smallest change. Cons of A: Firefox may still differ slightly. Pros of B: Cross-browser parity. Cons of B: May need dual scrollbar-color and ::-webkit-scrollbar* tuning/testing. Recommendation: C, implemented so both scrollbar-color and ::-webkit-scrollbar-thumb stay aligned.

Once you answer 1–3, I’ll post a concrete implementation plan on this issue.

1. A
2. a
3. b

@servicedesk

Thanks @zaakiy — recorded answers: 1A, 2A, 3B.

Implementation plan

Goal: In dark mode, native scrollbars always use today’s stronger (hover) thumb color, with no further hover change, globally, in Chromium/WebKit and Firefox.

File: server-core/src/main/java/io/onedev/server/web/page/base/base.css (existing .dark-mode scrollbar block ~757–770).

Colors (unchanged):

• Thumb: rgb(51, 52, 75) (current hover / full-strength look)
• Track / corner / border: rgb(37, 38, 55)

Steps:

1. Keep track styling on .dark-mode ::-webkit-scrollbar and .dark-mode ::-webkit-scrollbar-corner.
2. Set .dark-mode ::-webkit-scrollbar-thumb to the full-strength thumb color.
3. Add matching :hover and :active rules on the thumb with the same color so WebKit/Chromium does not brighten further (requirement 1A).
4. Keep .dark-mode * { scrollbar-color: <thumb> <track>; } aligned with those colors for Firefox (requirement 3B). If Chromium still paints a faint idle thumb because scrollbar-color wins over webkit pseudos, adjust so Chromium takes the webkit path (solid idle) while Firefox still gets scrollbar-color — e.g. via engine-appropriate layering/@supports, without changing the visual target colors.
5. Manual check in dark mode: page + nested overflow (side panels, dropdowns) in Chromium and Firefox — idle thumb readable, hover/active unchanged, track unchanged.

Out of scope (per 2A): PerfectScrollbar, CodeMirror, and other custom widget scrollbars.

No code yet — this is the plan only. If this looks right, reply and we can turn it into an implementation issue / PR; if you want changes, say what to adjust.