45469 - Need control over browser scroll bars look and feel

Status: RESOLVED WORKSFORME

(Core Graveyard :: Embedding: APIs, enhancement, P3)

Description

[Nathan Kirkham]

Currently the scroll bar is in mozilla style.  Within the Java it should be 
either the AWT look, or the current Swing L&F

Comment 1

[Blake Ross]

Can you please explain further?

Comment 2

[Nathan Kirkham]

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.

Comment 3

[edburns]

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.

Comment 4

[Nathan Kirkham]

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.

Comment 5

[edburns]

Changing to embedding.

Comment 6

[Peter Trudelle]

->evaughan/M0.9.  We need to address this for embedding.

Comment 7

[Eric Vaughan]

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.

Comment 8

[edburns]

evaughn: can you please point me to a tutorial on how to do this?

Comment 9

[Paul Wyskoczka]

Updating QA Contact

Comment 10

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

unsetting target milestone

Comment 11

[Brian]

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?

Comment 12

[Michael Dunn]

Correction: Changing QA contact for the Embed API bugs to David Epstein.

Comment 13

[Viswanath Ramachandran]

nav pretriage: Ben's not going to have time for this in mozilla0.9.1. Moving to 
future. 

Comment 14

[Paul Chen]

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

Comment 15

[Adam Lock]

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.

Comment 16

[Adam Lock]

Shall I mark this as a WONTFIX then?

Comment 17

[Maher Awamy]

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..

Comment 18

[Maher Awamy]

Ideas Blizzard?

Comment 19

[Christopher Blizzard (: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.

Comment 20

[Adam Lock]

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?

Comment 21

[Christopher Blizzard (:blizzard)]

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.

Comment 22

[Adam Lock]

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.

Comment 23

[Christopher Blizzard (:blizzard)]

> 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.

Comment 24

[Maher Awamy]

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.

Comment 25

[Brian Ryner (not reading)]

This will be fixed by http://bugzilla.mozilla.org/show_bug.cgi?id=118301.

Comment 26

[Marek Z. Jeziorek]

making it topembed- per edt bug triage.
This is fixed for non-gtk platforms (i.e., Mac and Windows).

Comment 27

[Chris Nalls]

Confirming Topembed-

Comment 28

[Julien "_FrnchFrgg_" RIVAUD]

Is this still relevant ?

Comment 29

[Julien "_FrnchFrgg_" RIVAUD]

Closing, since scrollbars follow the native theme now.