Scroll bars should follow user's Smart Scrolling preference

VERIFIED FIXED in mozilla0.9

Status

()

P3
enhancement
VERIFIED FIXED
19 years ago
17 years ago

People

(Reporter: mpt, Assigned: hyatt)

Tracking

({embed, helpwanted, platform-parity})

Trunk
mozilla0.9
PowerPC
Mac System 8.5
embed, helpwanted, platform-parity
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

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.

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → LATER
Whiteboard: HELP WANTED

Comment 2

19 years ago
resolving as later

Updated

19 years ago
Status: RESOLVED → VERIFIED
QA Contact: claudius → elig

Comment 3

19 years ago
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

19 years ago
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.
(Reporter)

Comment 7

19 years ago
*** 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.
(Reporter)

Comment 9

19 years ago
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.
Status: VERIFIED → REOPENED
Keywords: helpwanted
Resolution: LATER → ---
Whiteboard: HELP WANTED
(Reporter)

Comment 10

19 years ago
... Reassigning.
Assignee: trudelle → nobody
Status: REOPENED → NEW
Keywords: pp
Summary: [PP] Scroll bars should follow user's Smart Scrolling preference → Scroll bars should follow user's Smart Scrolling preference
(Reporter)

Updated

19 years ago
Blocks: 33527

Updated

19 years ago
Blocks: 4252
Blocks: 39375
(Reporter)

Updated

19 years ago
Blocks: 26828
No longer blocks: 39375

Comment 11

19 years ago
Add self to CC.

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

Updated

18 years ago
Blocks: 49144

Comment 12

18 years ago
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

18 years ago
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

18 years ago
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

18 years ago
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.
Assignee: nobody → trudelle
Keywords: nsmac2
QA Contact: elig → jrgm

Comment 16

18 years ago
->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

Comment 17

18 years ago
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)
(Assignee)

Comment 18

18 years ago
Mine.
Status: NEW → ASSIGNED
(Assignee)

Comment 19

18 years ago
No, really.  It's still mine.
Assignee: evaughan → hyatt
Status: ASSIGNED → NEW
(Assignee)

Comment 20

18 years ago
Fixed.
Status: NEW → RESOLVED
Last Resolved: 19 years ago18 years ago
Resolution: --- → FIXED

Comment 21

18 years ago
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

18 years ago
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)?
(Reporter)

Comment 24

18 years ago
Verifying fixed (modulo the bugs that lordpixel mentioned), 2000121514 build, Mac 
OS 9.0. Party in the streets.
Status: RESOLVED → VERIFIED

Comment 25

18 years ago
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

18 years ago
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

18 years ago
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

18 years ago
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

18 years ago
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

18 years ago
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

17 years ago
*** 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.