Need control over browser scroll bars look and feel

RESOLVED WORKSFORME

Status

enhancement
P3
normal
RESOLVED WORKSFORME
19 years ago
4 months ago

People

(Reporter: nathan, Assigned: eric)

Tracking

({topembed-})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [T2])

Currently the scroll bar is in mozilla style.  Within the Java it should be 
either the AWT look, or the current Swing L&F
Can you please explain further?
The embedded mozilla control has scroll bars to the right, and if necessary at 
the bottom.  These use the mozilla look (skin?) where the scroll bar has dashes 
in the middle. It looks different than standard windows for example.
When embedded in another app (in my case Java) I wan't it to look consistant 
with the rest of the application.  This means tat the scroll bars should look 
like the rest of the environment.
In Java you can be using AWT, in which case it should look like the hosting O/S 
control.  If it is swing then it should use the swing L&F that has been chosen, 
perhaps Metal or your own corporate one.
I would also argue that when embedding on any platform it should take that 
platforms look.  Linux has its own window manager, and Windows is going that way 
too.
Nathan is correct.  This is a bug.  However, I think it's a bug in the design 
of the embedding engine.  What we need is the ability to just get the mozilla 
content area without scrollbars so the custom app can put it in a JScrollPane 
or whatever.

Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Yes I agree that sounds correct.  What I would say is that the browser should 
come with scroll bars included in a standard option.  You don't want every 
developer to have to find out how to add scroll bars on themselves.
I am not sure of the current quality of scrolling in java.  I would think it is 
best that the mozilla control is left to actually do the scrolling itself, 
rather than relying on Java controls to move the view.
Changing to embedding.
Assignee: edburns → valeski
Status: ASSIGNED → NEW
Component: Java APIs to WebShell → Embedding APIs
QA Contact: geetha.vaidyanaathan → jrgm
Keywords: embed
->evaughan/M0.9.  We need to address this for embedding.
Assignee: valeski → evaughan
Severity: normal → enhancement
Target Milestone: --- → mozilla0.9
We do have ABSOLUTE control over scrollbars look. It is completely defined in
the skin file. We have Mac and Windows native looks as well as Modern and a
hostof others. Its up to the embedder to decide what look they want.

As for swing. You can make easily make a skin that looks like a swing look.

This is purely a skin issue.
Assignee: evaughan → ben
evaughn: can you please point me to a tutorial on how to do this?
Updating QA Contact
QA Contact: jrgm → mdunn
unsetting target milestone
Target Milestone: mozilla0.9 → ---
would it be possible to do something like (pseudo-code):

Mozilla.DisableScrollbars();
range = Mozilla.GetScrollRange();
MyNativeWindow.SetScrollRange(range);

...

void OnScroll(){
position = MyNativeWindow.GetScrollPosition();
Mozilla.Scroll(position);
}

I'm not sure about stuff like frames, but they could work in a similar fashion 
just replace Mozilla. with Mozilla.CurrentFrame. right?
Blocks: 70229
Keywords: embedmozilla0.9.1
Correction: Changing QA contact for the Embed API bugs to David Epstein.
QA Contact: mdunn → depstein
nav pretriage: Ben's not going to have time for this in mozilla0.9.1. Moving to 
future. 
Target Milestone: --- → Future
nav triage team:

Whether a skin issue or not, this doesn't belong in the xpapps group, looks like 
an embedding issue. Reassigning to owner of component
Assignee: ben → adamlock
QA Contact: depstein → mdunn
I don't believe it's an embedding issue either.

It's up to the Java folks to produce a Swing-like skin for the Mozilla component 
and ensure that the profile uses it.

There are notes on writing skins here:

http://www.mozilla.org/xpfe/

Basically it involves writing a replacement for scrollbars.css, replacing the 
gifs used with ones that look like Swing.
Shall I mark this as a WONTFIX then?
I dont think this should be a WONTFIX as for Gtk+ embeddors there is no way we
could create a skin for every Gtk+ theme out there. It would be much easier if
GtkMozEmbed for example could be packed in a scrolled window and its native
scrollbars be hidden and synced against the hscroolbar/vscrollbar of the
GtkScrolled Window, at least for Gtk+ stuff. Anyone knows where the code is, I
would like to take a look. There was an option in Mozilla before that disabled
the XUL scrollbars but its gone since M9 I guess..
Ideas Blizzard?
evaughan, it isn't entirely a skin issue.  On linux when we're embedded in
another application mozilla's skinned scrollbars look really bad since they
don't match the application style at all.  Also on linux we have the added
problem that the scrollbars in the application can be rendered by native
renderers and can't be defined as part of a skin so to maintain native
application-wide consistency we need to support native scrollbars for text areas
and the content area of an embedded window.

We can't emulate all possible themes in linux and we need to maintain
application-wide consistency of look and feel for scrollbars.  Content-area text
controls and form controls are another matter, of course but the scrollbars look
really, really out of place especially for the content area.
This sounds like a GTK widget issue. Who would be the best person to assign the
bug to if you want to keep it open?
It isn't a gtk widget issue.  The layout engine doesn't use the gtk widgets.  If
the gtk scrollbars didnt't work this would be a gtk widget issue.  As far as I
know they work fine. :)

This is really a feature request for evaughan.
I'm reassigning to evaughan then.

Someone should clarify what the issue is exactly.

Is it that you can't override the scroll bar appearance? But you can of course.
Or that you can't produce a skin to match against every GTK scrollbar appearance?
Or that you can't override the default scrollbar widget with your own?

Fundamentally though it's not embedding's problem until such time as the feature
is actually implemented and must be exposed to the embedder in some useful way.
Assignee: adamlock → evaughan
> Is it that you can't override the scroll bar appearance? But you can of course.

That's not the problem.

> Or that you can't produce a skin to match against every GTK scrollbar appearance?

_very_ true.

> Or that you can't override the default scrollbar widget with your own?
> 
> 

Not true.

It's not really any of these.  It's that when you are embedded in an application
you want to look consistent within that application.  Right now we don't have
that.  It's not a problem on windows or the mac since there's one default
scrollbar that looks fine and they are easy to emulate.
I suspect support for this is STILL in the layout engine somewhere in the
scrollbar code cause the pref option is still valid but its just ignored, I
can't put my finger on the exact peice of code but I guess I could find it.
Ok Here I found it:

in nsCSSFrameConstructor.cpp


PRBool
nsCSSFrameConstructor::HasGfxScrollbars()

//return mHasGfxScrollbars;
// we no longer support native scrollbars. Except in form elements. So
// we always return true
     
return PR_TRUE;
     
so when PR_FALSE; is returned instead, the Gtk scrollbars are drawn if the
pref is true, however, they need some work as they dont adjust and do some
weird things from time to time. I dont know where to start about fixing this
but I am wiling to give it a shot if I get some guidance.
Blocks: 98995
OS: Windows NT → All
Hardware: PC → All
QA Contact: mdunn → depstein
Keywords: topembed
making it topembed- per edt bug triage.
This is fixed for non-gtk platforms (i.e., Mac and Windows).
Keywords: topembedtopembed-
Confirming Topembed-
Whiteboard: [T2]
QA Contact: depstein → dsirnapalli
Is this still relevant ?
Closing, since scrollbars follow the native theme now.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.