Closed Bug 16277 Opened 22 years ago Closed 21 years ago

Scroll bars should follow user's Smart Scrolling preference


(Core :: XUL, enhancement, P3)

Mac System 8.5





(Reporter: mpt, Assigned: hyatt)




(Keywords: embed, helpwanted, platform-parity)

Scroll bars should follow the user's preference, set in the Appearance control
panel, about whether the arrow buttons appear at the same end, or at opposite
ends, of the scroll bar. XPFE widgets obviously aren't trying to mimic every
aspect of native widgets, but for those with Smart Scrolling turned on, this
difference between Mozilla scroll bars and those in other MacOS programs would
be just *too* annoying.

Users of other OSes may also enjoy this feature. If so, it should be available
in the prefs, *except* on MacOS (because MacOS already provides somewhere, the
Appearance control panel, in which to set it).

Note that bug #16245 also involves getting stuff from the Appearance control
panel -- in that case, colors. It would save time to fix both of these at once.

-- mpt (additional keywords: scrollbar, scrollbars, Kaleidoscope)
Count me as one Linux/Windows user who would like this.
Closed: 22 years ago
Resolution: --- → LATER
Whiteboard: HELP WANTED
resolving as later
QA Contact: claudius → elig
Verifying as LATER; anyone who'd like to pick this up and implement it themselves
to the XPToolkit team's satisfaction, of course, is welcome to.
I'll even throw in a free dinner at Moz Cafe with the XPToolkit team!
This should probably be:

Place scrollbar arrows
 o Together
 o Opposite Ends
 o Normal Position (Operating System Setting)

Obviously most OSes have a hardcoded "opposite ends", but this pref is at least
From some screenshots it looks like BeOS uses two thumbs on each end (or at
least the option to), so whoever implements this should do that too at the same
*** Bug 22750 has been marked as a duplicate of this bug. ***
BeOS is not the only OS supporting both arrows at both ends. See <A HREF="http:// ">bug #22750</A> on enabling this

behavior on Mac OS.
Reopening and assign to, in the hope that someone in the Mac 
community will try the scrollbars in beta 1 and be galvanized into fixing this.
Keywords: helpwanted
Resolution: LATER → ---
Whiteboard: HELP WANTED
... Reassigning.
Assignee: trudelle → nobody
Keywords: pp
Summary: [PP] Scroll bars should follow user's Smart Scrolling preference → Scroll bars should follow user's Smart Scrolling preference
Blocks: 33527
Blocks: 4252
Blocks: 26828
No longer blocks: 39375
Add self to CC.

People who are bugged by this bug were also bugged by bug 46174
Blocks: 49144
You can get which style of scroll bar the user is using with:﷒0﷓

i.e. call GetThemeScrollBarArrowStyle

This officially returns 0 or 1 depending on whether the arrows are in the lower 
right or seperate at both ends. However *numerous* utilities exist that can get 
the arrows into the third state of "both arrows at both ends" which was pulled 
late in the beta development cycle of 8.5 (vers?). I've personally had both 
arrows at both ends for a couple of years now with no ill effects.

I'd hazard a guess that the constant for both at both ends is "2" :-)

I'm hoping all we need to do to fix this is add both arrows at both ends to

and then get jiggy with some preferences and some css "hidden" attributes to 
handle turning it off on platforms that don't do this.

Final stage is prefs UI and autodetection of the OS's preferred setting, which 
can be hardcoded on Windows and Unix and detected as explained above on Mac OS.
Been talking to Jag about this one. Here's a summmary of what we said:

Probably should apply this only in Mac classic skin, at least for now.

Way to do this is with XBL and CSS. 

Currently scrollbars are styled in scrollbar.css which in the classic skin binds 
them to the appropriate platform version of classicBindings.xml.

This XBL file defines how the scrollbar is laid out, so one way to proceed it to 
remove the scrollbar definition from this file and instead have 3 (or more?) 
scrollbarBindings.xml files - one for each arrow style. 

Then one needs to use CSS to pick which XBL binding will be used[*]

The way to do this is to add an attribute to the scrollbar thusly:

<scrollbar nativestyle="babe">		(both at both ends)

and then match on that ending in CSS:

scrollbar[nativestyle="babe"] {
	-moz-Binding: ... whatever... babeScrollbarBindings.xml;

and so on for the other two styles.

Setting the attribute  is where C++ comes in. Somewhere around mac/scrollbar.cpp 
or thereabouts we query the function listed above to find out the OS setting, 
then we set an attribute on the newly created scrollbar saying which end style we 

I copied Jag on this bug, so I hope he'll elucidate where I've failed to explain 
it properly.

Hey, I think I just grokked what XBL is for...

[*]Will also need to use CSS to style Mac scrollbar arrows a little, some of the 
3D border is omitted when the two arrows are close together.
Hyatt suggests another approach....

1/ Expose the current smart scrolling style as a preference. Set it on

2/ In the XBL for scrollbars, have some JavaScript that reads the preference and
arranges for things to look right.

The arranging part would be:

i/ apply any CSS styles needed to make the scrollbars look right. This should be
easy, XBL can apply CSS to the bound element

ii/ Hide or show the extra arrows... simple approach... simply have all 4 arrows
in the XUL and use display:none. Better, according to hyatt, clone the existing
arrows in the Javascript in the XBL.

Can anyone help with the 1st part - how to add new prefs that are backed by C++
code? I'd like to evaluate their values:

* at worst, on startup
* better, on new window open
* best every time they're read
	(but see [1] and [2] below for why this is maybe not best)

[1] Ultimately this is a Bad way of doing it - we need a Javascript function
call that rechecks this each time its called.
[2] Even given [1] this needs to change when the user changes the preference in
the operating system. At this point Hyatt & BenG started talking about mutation
events and how cool if would be if "XBL" was notified (i.e. re-evaluated) when
prefs changeed, which would make [1] unnecessary.
Reassign to module owner to get this back on the radar (hopefully).

Jason Alcock mentions this issue on 11/15/2000 at

Application refuses to acknowledge smart scrolling.
Assignee: nobody → trudelle
Keywords: nsmac2
QA Contact: elig → jrgm
->evaughan, ->moz0.9, adding embed keyword. We need to support this in a
clean/efficient manner after mutation events land.
Assignee: trudelle → evaughan
Keywords: embed
Target Milestone: --- → mozilla0.9
2 things - I see how to add a metric to nsLookAndFeel to capture the style, its 
about 1 hour's work. 

Secondly work Beard is doing on theme compliant scrollbars etc will effect this, 
so talk to him before begining a fix. 

(also talk to someone about BeOS)
No, really.  It's still mine.
Assignee: evaughan → hyatt
Closed: 22 years ago21 years ago
Resolution: --- → FIXED
Hyatt! Wow. My sensors detect you fixed that bug in a maxium of 59 seconds :-)

Seriously though - I wonder if you cracked the whole thing which is to make it 
track the operating system's current setting. I guess I need to pull, build and 
find out...
I'm not sure this is 100% fixed - if you open a link in a new window, the scroll
bars in the new window don't follow the smart scrolling prefs. The view source
window doesn't follow the smart scrolling prefs. Should this be reopened or
should new bugs be filed (now that the basic functionality is there)?
Verifying fixed (modulo the bugs that lordpixel mentioned), 2000121514 build, Mac 
OS 9.0. Party in the streets.
Is this really fixed? It doesn't work in 2001010816. My system is configured to
display both arrows at the bottom of the scroll bar, and Mozilla displays with
one at each end. Reload doesn't change it, opening a new window doesn't change it.
Works for me in 2001020908, after reload.

You are on MacOS right? BeOS implementation isn't complete yet, and there's 
currently no work been done to enable it on Windows or Linux. (though in 
principle it could be done on those platforms)
Yes, I'm on Mac OS. Turns out though I was using Moz 0.7 it was accessing a
profile I'd created under NS 6.0.1.  I created a new profile under Moz 0.7 and
the scroll bars displayed properly.

Shouldn't this have also worked in the NS profile, though, when accessed through
Moz 0.7?
I got this to work right under the Classic and Modern themes installed along
with Moz 0.7, but not the Blue one.  It also doesn't work under the
Modern-Mozillium variant available at
blue isn't supported, you could write a patch to fix it. mozillium is in a grey 
area, i think there's a bug somewhere about fixing it.
Ah right: see this newsgroup posting from ( :


As described in the posting, due to shortcomings in Netscape 6 skins will need to 
be updated to take advantage of this feature.

You'll need to mail the person who maintains the skin and ask them to fix it. 
*** Bug 96895 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.