in mozilla , th e size of the scroll bar is always the same if in windows properies, you put size=8, the size of mozilla scroll bar is still the one by default i think this is in all builds but it does it whith the 2000110104

via timeless: we need an api to access the property via css and that themes will be allowed to ignore it hixie: timeless says you should be attn'ed (yes I am his puppet)

hm, it s not in css i speak about the scroll bar at the right of the screen when you need to scroll down to see the rest of the text mozilla doesnt look at the properties of micro$oft windows to get the size, it s always the same

Reporter: you are unfamiliar w/ the way we handle themes. Mozilla themes are composed of .xul and .css. The fact that this will be a css property does not mean the average webpage can specify it, put it does allow chrome(xul) to specify it. Assignee: please implement this for All/All. Thanks

Sending to Hewitt.

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

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

hewitt must have slipped. no reason for this to be ns conf.

RFE? This ain't no RFE. It's an accessibility bug, albeit a relatively minor one.

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

I see the same behaviour under WinMe (Build 3000, German) and Mozilla 201061620. The OS setting of scrollbars on my machine is not used, instead Mozilla uses much thicker scrollbars.

now i m under linux and the problem is still there with the last milestone (2001060713) the theme i use is not used by mozilla, so it s on all os (i think)

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

A small update: as of 2001082803 Mozilla still doesn't do the right thing here. It's annoying to not have applications respect one's settings with regards to UI. I'm not familiar with the Mozilla code to know what needs changing to make Mozilla's scrollbars obey the sizing I've specified. Just to be clear, I'm not talking about scrollbars rendered within a page (such as what you see in BugZilla's query page for Component or Program). I'm talking about the outermost scrollbars in the browser window -- the ones you use to pan a rendered page around in the browser window.

Mass reassigning some of my theme bugs to Shuehan.

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

So how are you planning to implement this for all/all? Is it possible to get the moz window to use the standard gtk+ scrollbar? The reporter of Bug 121702 suggested a pref with scrollbarwidth. I don't like that personally, but it seems to be the only way to let the user decide how big.. If this is "an accessibility bug" (comment #8), maybe moz should ship with an "accessibility theme" with nice big scrollbars and grippies and such. Relying on gtk+ to set a smart value might be unwise - dunno.

>The reporter of Bug 121702 suggested a pref with scrollbarwidth. I don't like that personally, but it seems to be the only way to let the user decide how big.. No good at all, there's a pref in the OS for crying out loud, why there has to be another one in each application? The OS settings are global, the apps should follow them. In my opinion, of course. Marcos.

Yup, on Windows mozilla should use the ::GetSystemMetrics() call to determine the widht/height/font/etc... for the UI elements in the classic theme. as far as i know gtk also has system-wide settings for these kinds of things. shouldn't the classic theme follow the defaults, and be well-behaved like other apps?

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

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

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

I'd like to reiterate the Comment #18 again! I dont get it right now: Why is this ancient bug originating in the year 2000 not fixed yet?! All other apps are following the WinXP setting for the scrollbar width, why is this not possible with the lovely mozilla Windows version in classic theme?! Now what exactly is the problem here?? It seems it simply gets ignored all the time. Excuse me the harsh comment but why can all the other apps do it but only moz can't?! Are there some plans to fix this at least for the final version 1.0?! Thanks a lot.

BTW, it would be nice if Linux users would be able to change the width of the scrollbars too (e.g. in userChrome.css). When I used Netscape Navigator I really wanted to change the width (since the default was so thin). Since it was a Motif app, I could do that using the X-Windows resource file.

> I don't get it right now: Why is this [...] not fixed yet?! Because of the way themes are done. Create a theme; then you'll understand better. Whole specifications have to change (although it's unlikely to break many existing themes, fortunately, except for those that need to take advantage of it, like Classic). I'm agreed with those who have said it's enough for it to be possible for themes to access these settings using css keywords and for the classing theme to do so. Other themes can do as they like. (In particular, themes which use lots of bitmaps don't need to adhere. Classic does need to do so, however.) Are there separate bugs for the other system-wide-settings issues (fonts and sizes, menu colours (are those done already, or is classic just using the regular system colours?), message/dialog box colours, tooltip colours, ... does any platform have system-wide settings for link colours? Or should those issues be covered by this bug as well? Or should there be a meta bug and dependencies? Regarding Linux: does Gnome or KDE provide settings Mozilla could follow, if either of those environments is installed, or are their themes as complicated as Mozilla's and maybe bitmap based? (I don't know; I just _use_ them...)

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

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

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

I agree with the Additional Comment #24 From Jonadab the Unsightly One (Nathan Eady) that it's enough the classic theme adheres to the windows setting for the scrollbar whidth. The other themes can do what they like to. Is there any solution in sight for this issue? So far the classic theme is using the settings for buttons, colours aso defined in the active WinXP theme/style without any problem which is very nice.

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

This was requested in a user discussion forum recently -- I didn't realize we don't obey this. Is it currently assigned to the right person?

Evidently this is officially a Classic theme only bug (it has the "classic" keyword), yet the problem also exists in the Modern theme. Is there anyone other than me who feels that this should apply to *all* standard general-purpose themes, including Modern? Is there a separate bug for the Modern theme? I see nothing in any of the last 6 bugs duplicated against this one that expresses a desire to have it apply only to certain themes.

I'm not sure if it should apply to modern. Classic is our theme for supporting OS display settings like size parameters and colors. If modern is to support some of those settings, I don't know how we would choose which ones.

Scrollbars get a *lot* of use in a web browser, and their size has a significant effect on the "feel" of the application. That is not so much the case with most other GUI elements, or with colors. I admit that I'm a bit bewilidered as to why there would be any resistance to fixing this, if not for the current technical difficulty. But clearly I'm in the minority.

There's no resistance to fixing it for classic. I just said I was not sure about modern. A lot of the modern theme is based on fixed size images, so I don't even know how hard it will be. Who knows, maybe we'll fix it for modern too -- no one has looked into how it will be done yet.

This is going to be fixed on Windows (for the Classic mozilla skin) when the patch for bug 172751 is checked in.

Re comment #35: Yes, now it's fixed on Windows/Classic. Confirmed with 2002120408 on Win2k.

In the screenshot you see three scrollbars, one on the left (the scrollbar of the sidebar), the bottom one, and the right one. The sidebar scrollbar is correctly sized; it obeys my preferences for how wide a scrollbar should be. The right and bottom scrollbars do not obey my setting, they remain uncomfortably small on my monitor (1600x1200).

J.B.: What Windows OS are you running on? Does this happen consistently when you startup Mozilla? (Note that changing the size while mozilla is running is not fully supported yet.) Also, if you change the scrollbar arrow color (the 3D Objects foreground color in Display Properties), does this show up in the smaller scrollbars? You might also try a clean Mozilla profile to see if this fixes the problem.

Starting a new profile did the trick for me, thanks for reminding me of that. I'll try not to forget to do that in the future before I complain about bugs. I was trying this on Microsoft Windows 2000 SP2. Now I get correctly sized scrollbars in Classic. I wouldn't object to correctly sized scrollbars in more themes (certainly all the ones shipped by Mozilla which means Modern too), but I understand that's a theme-specific issue. Thanks so much folks, I very much appreciate the increased accessibility.

Nav triage team: nsbeta1-

this seems to be broken on XP. it will work with scrollbars over 16px, but if i set my windows scrollbar size to be less than 16px, they still show up as 16px in moz/fb.

WFM with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040620 Firefox/0.8.0+, Winstripe theme. Changing the scrollbar width from 16 to 10 or 28 works in Firefox. I don't even have to restart the browser. In WinXP, the setting is at Control Panel > Display > Appearance > Advanced. I don't know if an equivalent setting exists in other operating systems. I also don't know whether Mozilla is getting the width from the OS in such a way that it could easily be made a hidden pref on non-Windows systems.

see my earlier comment above. Call the Win32 function ::GetSystemMetrics() (http://msdn.microsoft.com/library/default.asp?url=/library/en- us/sysinfo/base/getsystemmetrics.asp) to get the size of various themed objects.

I'm not sure if my problem is the same as what's reported here or not. The SeaMonkey scrollbars are exactly 2 pixels wider / taller than are the scrollbars in any other Windows application - under Windows XP, using Luna, or the theme (Hyperion) I designed and am currently running with. I'm attaching a screenshot of the problem in my "Hyperion" theme, as well as a graphic illustrating the problem with the native XP Luna them. This was also discussed last year in Cheeaun's blog (it's from where the graphic comes): http://cheeaun.phoenity.com/weblog/2004/08/scrollbar-tweaks.html In the case of my Hyperion Windows theme, it screws up the graphics I designed by giving a right vertical line on vertical scrollbars, and a bottom horizontal line on horizontal scrollbars. This occurs with both the native SeaMonkey classic theme as well as the newer Orb Colours Classic theme (http://forums.mozillazine.org/viewtopic.php?t=362605&postdays=0&postorder=asc&postsperpage=15&start=0).

Jason, that would be bug 269777

Excellent, thank you for the correct bug. I'm interested in this one too, though, so I didn't actually waste my time here. :)

i'm seeing jb nicholson's issue (comment 44 - some scrollbars are the proper width, some aren't within the same window) in thunderbird 1.5, even with a new profile. windows xp sp2

i just did some more testing of this. it seems to be fixed in most but not all places. for example, the compose message window of thunderbird 2.0.0.14 seems to use a 16px scrollbar no matter what. haven't yet been able to reproduce it anywhere in firefox 3.0RC1.

If you can't reproduce it in Firefox 3, trunk builds or the Thunderbird alphas, then I suspect we fixed it a long time ago. I think this bug should be closed and if the issue crops up again, then we can file a new one

Closing as WORKSFORME for SeaMonkey. Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111110 SeaMonkey/2.8a1