16277 - Scroll bars should follow user's Smart Scrolling preference

Status: VERIFIED FIXED

(Core :: XUL, enhancement, P3)

Description

[Matthew Thomas, usability weenie]

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)

Comment 1

[Matthew Tuck [:CodeMachine]]

Count me as one Linux/Windows user who would like this.

Comment 2

[Peter Trudelle]

resolving as later

Comment 3

[Eli Goldberg]

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.

Comment 4

[Peter Trudelle]

I'll even throw in a free dinner at Moz Cafe with the XPToolkit team!

Comment 5

[Matthew Tuck [:CodeMachine]]

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.

Comment 6

[Matthew Tuck [:CodeMachine]]

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.

Comment 7

[Matthew T (active 1999-2002)]

*** Bug 22750 has been marked as a duplicate of this bug. ***

Comment 8

[Henri Sivonen (:hsivonen)]

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.

Comment 9

[Matthew T (active 1999-2002)]

Reopening and assign to [e-mail], in the hope that someone in the Mac 
community will try the scrollbars in beta 1 and be galvanized into fixing this.

Comment 10

[Matthew T (active 1999-2002)]

... Reassigning.

Comment 11

[Andrew Thompson]

Add self to CC.

People who are bugged by this bug were also bugged by bug 46174

Comment 12

[Andrew Thompson]

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.

Comment 13

[Andrew Thompson]

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.

Comment 14

[Andrew Thompson]

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.

Comment 15

[Kathleen :Brade]

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.

Comment 16

[Peter Trudelle]

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

Comment 17

[Andrew Thompson]

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)

Comment 18

[David Hyatt]

Mine.

Comment 19

[David Hyatt]

No, really.  It's still mine.

Comment 20

[David Hyatt]

Fixed.

Comment 21

[Andrew Thompson]

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

Comment 22

[Adam]

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

Comment 23

[Andrew Thompson]

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

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

Comment 24

[Matthew T (active 1999-2002)]

Verifying fixed (modulo the bugs that lordpixel mentioned), 2000121514 build, Mac 
OS 9.0. Party in the streets.

Comment 25

[Greg K.]

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.

Comment 26

[Andrew Thompson]

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)

Comment 27

[Greg K.]

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?

Comment 28

[Greg K.]

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.

Comment 29

[timeless]

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.

Comment 30

[Andrew Thompson]

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. 

Comment 31

[Greg K.]

*** Bug 96895 has been marked as a duplicate of this bug. ***