Closed Bug 35996 Opened 25 years ago Closed 23 years ago

Maintain native scrollbars

Categories

(Core :: XUL, defect, P3)

defect

Tracking

()

RESOLVED FIXED
mozilla1.1alpha

People

(Reporter: hsivonen, Assigned: mikepinkerton)

References

(Depends on 1 open bug)

Details

(Keywords: embed, helpwanted)

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.)
Marking helpwanted. (And the lack of resources is of course cited as the reason, not decision.)
Keywords: helpwanted
Summary: Maintain native scrollbars → Maintain native scrollbars
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.
Status: UNCONFIRMED → NEW
*** This bug has been confirmed by popular vote. ***
Ever confirmed: true
Changing platform and OS to all.
OS: Mac System 8.5 → All
Hardware: Macintosh → All
reassigning to nobody@mozilla.org...
Assignee: trudelle → nobody
This is stage 3 of bug 26828.
Blocks: 26828
No longer blocks: 39375
Depends on: 38467
>the availability of the native scrollbars may not last See bug 43434 :-(
Keywords: nsbeta1
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...)
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.
Keywords: mozilla0.9
Keywords: mozilla0.8.1
Keywords: mozilla0.8
Target Milestone: --- → Future
mjs@eazel.com - 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
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.
Depends on: 43434
*** Bug 78302 has been marked as a duplicate of this bug. ***
No longer blocks: 73812
Blocks: 104166
native scroll bars are beginning to come back on the embedding radar, I'm taking this
Assignee: nobody → saari
Target Milestone: Future → mozilla0.9.8
Is it a sign that other basic native controls may come back in the content area? It would be nice!
This is important on mac os x since the gfx scrollbars look really bad next to aqua.
->pinkerton
Assignee: saari → pinkerton
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.
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.8 → mozilla1.1
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.
What is the preference to re-enable the native scrollbars? Andrew
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.
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.
Read the comments Eric, we're not talking about using it in XUL, just in content for embedding clients.
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.
would implementing NS_THEME_SCROLLBAR* help?
Depends on: 115757, 115758
Depends on: 118301
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.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
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.
Something is broken on linux.. bug 141495, bug 141394, bug 141495
typo in comment 27: Third bug should be bug 142536
You need to log in before you can comment on or make changes to this bug.