35996 - Maintain native scrollbars

Status: RESOLVED FIXED

(Core :: XUL, defect, P3)

Description

[Henri Sivonen (:hsivonen)]

As of April 2000, Mozilla no longer uses native scrollbars by default. Based on posts to 
the Mozilla newsgroups, it seems that the @netscape.com UI engineers no longer intend 
to maintain the native scrollbars.

Many Mac users have indicated dislike towards the decision to not use native scrollbars 
(and other widgets). Not using native scrollbars is also related to bugs such as bug 
16277, bug 26828 and bug 7347. Currently, the native scrollbars can still be enabled via 
preferences, but the availability of the native scrollbars may not last if the code is left to 
rot.

Since the lack of resources is cited as the decision to move to gfx scrollbars, Mozilla 
needs a volunteer to maintain native scrollbars.

(I am marking this bug "helpwanted" to put it in the field of view of people who would like 
contribute to Mozilla.)

Comment 1

[Henri Sivonen (:hsivonen)]

Marking helpwanted. (And the lack of resources is of course cited as the reason, not 
decision.)

Comment 2

[dark]

God bless! I'll vote for this one if it's extended to all OS'es. I really don't 
like the GFX widgets - too large.

Comment 3

[Adam]

*** This bug has been confirmed by popular vote. ***

Comment 4

[Henri Sivonen (:hsivonen)]

Changing platform and OS to all.

Comment 5

[Ben Goodger (use ben at mozilla dot org for email)]

reassigning to [e-mail]...

Comment 6

[Matthew T (active 1999-2002)]

This is stage 3 of bug 26828.

Comment 7

[Henri Sivonen (:hsivonen)]

>the availability of the native scrollbars may not last

See bug 43434 :-(

Comment 8

[mjs]

Native scrollbars are a requirement for applications that embed Mozilla, such as
Nautilus. While a GFX look for widgets inside the actual web page content area
is passable, non-native scrollbars look extremely out of place, especially for
apps like Nautilus that embed mozilla for some types of content but use other
components with native scrollbars for other content.

Adding mozilla1.0 keyword.

I also suggest that someone add `mozilla0.8' and `embed' keywords; I am not
empowered to do so (I'd love to have the bits to add the `embed' keyword, since
I work on a significant Mozilla embedding application...)

Comment 9

[mjs]

Whoops, it looks like I can't even add the `mozilla1.0' keyword. Request that
someone add at least that and/or give me appropriate bits.

Comment 10

[Gervase Markham [:gerv]]

[e-mail] - I've updated your Bugzilla permissions. But I think if you still
want native scrollbars, you are going to have to do them yourself. :-|

Can't you restyle the gfx ones?

Gerv

Comment 11

[Aaron Lehmann]

Ugh. No. Not only will that not adjust at all to themes, but it will still be
rancidly slow and buggy. "Native" scrollbars (as well as all other widgets)
would work much better than any kind of XUL.

Comment 12

[timeless]

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

Comment 13

[saari (gone)]

native scroll bars are beginning to come back on the embedding radar, I'm taking
this

Comment 14

[Pierre Saslawsky]

Is it a sign that other basic native controls may come back in the content area?  
It would be nice!

Comment 15

[Zach Lipton [:zach]]

This is important on mac os x since the gfx scrollbars look really bad next 
to aqua.

Comment 16

[saari (gone)]

->pinkerton

Comment 17

[Mike Pinkerton (not reading bugmail)]

gee, thanks. what am i supposed to do with this?

it's good to note that with a small code tweak and setting a pref to false, you
can get native scrollbars in the content area. They work just dandy. xul doesn't
use them, but if this is only for embedding, our work is done.

Comment 18

[saari (gone)]

if it works for our purposes, ignore the bug!

I was thinking of it as a tracking bug for native scroll bar support for
embedding clients.

Comment 19

[amutch]

What is the preference to re-enable the native scrollbars?

Andrew

Comment 20

[Mike Pinkerton (not reading bugmail)]

user_pref("nglayout.widget.gfxscrollbars", false);

but you have to make a source change for it to work

Index: nsCSSFrameConstructor.cpp
===================================================================
RCS file: /cvsroot/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp,v
retrieving revision 1.657
diff -r1.657 nsCSSFrameConstructor.cpp
4006c4006
<   //return mHasGfxScrollbars;
---
>   return mHasGfxScrollbars;
4009c4009
<   return PR_TRUE;
---
>   //return PR_TRUE;

we look up the pref, but then we ignore it. oh yeah. gotta love it.

Comment 21

[Eric Vaughan]

This code has bit rotted a lot. It uses the old scrollframe written by Troy 
and it will cause a lot of inefficiencies if used in Mozilla with XUL. The right 
way would be to use the new gfx scroll frame but use special frames that 
have native widgets or use owner draw instead of the current scrollbars.

Comment 22

[saari (gone)]

Read the comments Eric, we're not talking about using it in XUL, just in content
for embedding clients.

Comment 23

[Eric Vaughan]

It its only used in embedding it should be ok. But we need to check to 
make sure it has all the features. We should check to see if scroll position 
state is stored in the old code among other things.

Comment 24

[Hixie (not reading bugmail)]

would implementing NS_THEME_SCROLLBAR* help?

Comment 25

[Mike Pinkerton (not reading bugmail)]

I believe this has been obsoleted by the XBL->native widget bridge i did as part
of bug 121440. Bryner mentioned he wanted to remove
widget/src/<platform>nsScrollbar once he landed XBL form controls.

Any objections to completely getting rid of the old native scrolling mechanism
(which has mostly bit rotted, but still barely works) in favor of the gfx
mechanism with native scrollbars via xbl?

I can't see any reason to keep it around.

Comment 26

[Christopher Blizzard (:blizzard)]

I don't care if you want to delete the old implementations as long as there's
still a way for us to use the new implementation to get native scrollbars in the
content area and other places where a scrollbar is used.

Comment 27

[R.K.Aa.]

Something is broken on linux.. bug 141495, bug 141394, bug 141495

Comment 28

[R.K.Aa.]

typo in comment 27: Third bug should be bug 142536