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.

resolving as later

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 cross-platform.

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 time.

*** 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:// bugzilla.mozilla.org/show_bug.cgi?id=22750 ">bug #22750</A> on enabling this behavior on Mac OS.

Reopening and assign to nobody@mozilla.org, in the hope that someone in the Mac community will try the scrollbars in beta 1 and be galvanized into fixing this.

... Reassigning.

Add self to CC. People who are bugged by this bug were also bugged by bug 46174

You can get which style of scroll bar the user is using with: http://developer.apple.com/techpubs/macos8/HumanInterfaceToolbox/AppManager/﷒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 http://lxr.mozilla.org/mozilla/source/xpfe/global/resources/content/ scrollbarBindings.xml 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 want. 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 startup?[1][2] 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 http://www.macintouch.com/netscape6.html: Application refuses to acknowledge smart scrolling.

->evaughan, ->moz0.9, adding embed keyword. We need to support this in a clean/efficient manner after mutation events land.

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)

Mine.

No, really. It's still mine.

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)?

See http://bugzilla.mozilla.org/show_bug.cgi?id=61827 and http://bugzilla.mozilla.org/show_bug.cgi?id=61826

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 netscape.com.

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 (netscape.public.dev.skins) : news://news.mozilla.org/3A2C032E.8050000%40netscape.com 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. ***