30579 - "Scrollbar corner" should be skinnable (currently always white / displaying random garbage)

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, defect, P2)

Description

[Jesse Ruderman]

When both horizontal and vertical scrollbars are visible on a page, the bottom-
right corner should be light gray instead of white.

(Example: http://www.itsajob.com/ at 800x600 resolution)

Possibly related: bug #21890, documents can style their own scrollbars.

Comment 1

[Sean Richardson]

Confirmed with the 2000-03-05-08-M15 nightly binary on WinNT -- but see
the 2000-03-01 comment in bug 20996, where the same region is described as
grey. Possible that the latter was seen on linux. Seems possible that this
region just missed getting a colour defined.

Comment 2

[Eric Vaughan]

targeting

Comment 3

[Peter Trudelle]

Mass moving M17 bugs to M18

Comment 4

[Eric Vaughan]

The corner is the the color of the window background. If the background is gray 
it will be gray. XPApps needs to fixe this.

Comment 5

[don]

Move to M21 target milestone.

Comment 6

[kenneth buttler]

this is a stale bug. it has not been looked at in 30 days. it doens't reproduce 
and i suggest it be marked "WFM"

Comment 7

[Claudius Gayle]

still there for _Win98__ build from 2000071008

Comment 8

[Sean Richardson]

Kenneth - what platform/os/build variation were you using when you saw the
square between the ends of the scrollbars was grey?

Using the 2000-07-17-08-M17 nightly binary on WinNT, that area is still white.

Added URL above for ease of reproduction: it's a big photo of a bear.

Comment 9

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

GFXScrollFrame needs to be XBL so that we can style this individually in an 
appropriate way.

future. 

Comment 10

[Matthew T (active 1999-2002)]

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

Comment 11

[Matthew T (active 1999-2002)]

The square is your default HTML background color, not necessarily white -- in my 
case, it's pale yellow, no matter what the color of the Web page I'm currently 
visiting.

You shouldn't be able to apply only a background color to this area: in the Mac 
Classic theme, for example, it should have a 1px raised bevel.

Comment 12

[Tim Powell]

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

Comment 13

[Tim Powell]

Stealing comments from bug 61609 to help in reproducing this:

In Edit->Prefs uncheck "Use windows colors" and set the background color to 
something noticable (Green?). Go to a page and size the windows so both 
scrollbars show up. In the "notch" to the right of the horizontal scrollbar and 
below the vertical scrollbar you can see the background color you selected 
(green). This looks odd.

I'd think that the skins should use the gray (ThreeDFace? Window?) color here
like Navigator 4 did. Even with the background color set to white (as with the
Windows default) this looks strange when viewing a page that has a background
color that is dark.

Reproducable always.

Comment 14

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

I believe this is a toolkit bug. GFX Scrollframe needs to be some kind of XBL
widget. I mentioned this to hyatt and he said 'that's hard'... nonetheless,
reassigning to XPToolkit. 

Comment 15

[Peter Trudelle]

->evaughan, still future

Comment 16

[Hixie (not reading bugmail)]

blake: you mentioned this bug...

Comment 17

[Paul Chen]

nav triage team:

Not a beta1 stopper, marking nsbeta1-

Comment 18

[Tim Powell]

Proposing for mozilla1.0. I would say mozilla0.9.3, but it's not a valid 
keyword. This looks silly.

Comment 19

[John Morrison]

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

Comment 20

[Chad Austin]

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

Comment 21

[Jesse Ruderman]

Adding "white" to summary to make this bug easier to find.

Comment 22

[basic]

Is this part of HTML or skin/theme?

Comment 23

[Matthew T (active 1999-2002)]

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

Comment 24

[Jesse Ruderman]

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

Comment 25

[rvj]

Bug 107497 above, suggests a possible INTERIM solution based on the scrollbar 
properies 

i.e. no additional xul element is necessary because all the properties are 
derived from the current scrollbar style e.g. width, height, background-color, 
border, etc


However in the longer term, I would like to be able to attach events to this 
area as well as dynamically display/switch a document state icon

Comment 26

[Andrew Hagen]

The change happened earlier, but at least as of Build ID: 2001120303, this
problem seems to have been addressed, although differently than suggested here.
Instead of having a white, non-skinnable corner box, there is now a
non-skinnable encryption icon. The encryption icon was moved.

Should this bug be resolved?

Comment 27

[rvj]

Sorry Im only upto  9.6 (2001112009).

I would expect a minimum fix would define a new 'type' option so that the 
corner can be styled. (in the same way as scrollbarbutton tests for 
type='increment')


scrollbar[type="corner"] 
{
background-image: url("chrome://...") ;
background-color:#cccccc;
border:1px outset white;
}

Does the fix permit this this? 

Comment 28

[rvj]

in fact it probably makes more sense to regard the scrollbar corner as a psuedo 
slider element?

slider[type="corner"] 
{
background-image: url("chrome://...") ;
background-color:#cccccc;
border:1px outset white;
}

Comment 29

[timeless]

spacer[..]

Comment 30

[Shayon Mukerjee]

I don't understand the proposal to make it light gray.  While that would look
just fine with the NS4.7 look-alike skin as well as the modern skin, other skins
(such as that colorful toys one) that use color-schemes not based on shades of
blues/greys would look out of place.  So we'd be creating a problem by fixing one.

Either the corner should be skinnable, or we should change where the scrollbars
go.  Something like the little photoshop job I've done over here:
http://www.shyonline.net/corner.gif

In such a scenario, there is no need for a little box to even be there.  Of
course, no other browser I've seen does this, but it certainly looks better than
a little white square.

Comment 31

[Bernd]

when fixing this, please keep in mind that there is some code laying around
cornerview::paint which is intended to show content quality. Hmmm it would be
good to get this working. 

Comment 32

[Tobias Tinkerman]

This seems to be getting worse.  In WIN XP, (classic theme) the scrollbar 
corner is a dark grey (maybe it has been for a while) but it just looks really 
out of place with the light colors of classic.  Modern theme still has the 
white space.  Also I've noticed that if you right click on the corner between 
the toolbars, it will bring up the context menu, which should not happen.  
This bug was opened in 2000.  When will mozilla's UI get the polish it needs?  
It seems like nobody cares. 

Comment 33

[John Morrison]

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

Comment 34

[Cees T.]

Attachment: Some programs do it like this

Why waste a bit of screen estate?

Comment 35

[Greg K.]

That's a Windows-only solution, CT.

Comment 36

[Boris Zbarsky [:bzbarsky]]

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

Comment 37

[Stewart Gordon]

It seems that different versions/platforms/configurations do different things
with this corner.  Here (2003042808, Mac OS X, Modern theme), that corner just
isn't drawn at all.  This means that when the page is turned or a tab is
switched, whatever is there is whatever was at that screen position on the last
page or tab.  This could be the background of the last page, a scroll arrow, or
quite a mess on resizing of the window.

Comment 38

[Sander]

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

Comment 39

[Sander]

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

Comment 40

[Jesse Ruderman]

I didn't get random garbage in the scrollbar corner when I reported this bug. 
That seems to be a new problem.

Comment 41

[Mats Palmgren (inactive)]

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

Comment 42

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Mine, since I pretty much own scrolling now

Comment 43

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

This patch adds a "scrollcorner" XUL box element which is sized and placed
appropriately in all scroll frames that have two scrollbars. Themes can style
this element. This patch is small and low risk.

Comment 44

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 135713 [details] [diff] [review]
fix

wondering if we can get this into 1.6b

Comment 45

[Robert O'Callahan (:roc) (email my personal email if necessary)]

The hunk in xpfe/global/resources/content/xul.css is not necessary. Ignore it.

Comment 46

[timeless]

roc: it'd be nice if the box would be available for themes if there's only one
scrollbar. This way View-Source on mac os (x) for example could not lose its
scroll arrow.

Comment 47

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Can you explain the problem there? I don't get it.

Comment 48

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 135713 [details] [diff] [review]
fix

bryner would be a better reviewer for this

Comment 49

[[e-mail]]

Comment on attachment 135713 [details] [diff] [review]
fix

I tried this patch but mScrollCornerBox is always null, is part of the patch
missing?
Also, I think that there are five CSS files that style scrollbars which need to
be taken into account.

Comment 50

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: new patch

Try this. There was a piece missing from the previous patch. I've hand edited
the patch to remove some bits of another patch; hope it still applies cleanly.
I verified that the styles in the theme CSS files are indeed applied. The
colors I chose in the Mac CSS files are probably not correct but I can't figure
out what they should be. BTW I can only find four relevant CSS files, where's
the fifth?

Comment 51

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 135782 [details] [diff] [review]
new patch

ready for review again

Comment 52

[[e-mail]]

Comment on attachment 135782 [details] [diff] [review]
new patch

themes/modern/global/scrollbars-mini.css

Comment 53

[Stewart Gordon]

Re: comment 47

See bug 54688

Comment 54

[Stewart Gordon]

Sorry ... I meant bug 56488.  Darn bug 40896 (I think I typed that correctly) again!

Comment 55

[[e-mail]]

Attachment: Patch scrollbars-mini.css

Comment 56

[[e-mail]]

Comment on attachment 135782 [details] [diff] [review]
new patch

Bitrotted slightly due to the GetTag deCOMtamination.

Comment 57

[Brian Ryner (not reading)]

Comment on attachment 135782 [details] [diff] [review]
new patch

Looks ok, but I'd like to test with mac native scrollbars.  I'll comment again
after I've done that.

Comment 58

[Brian Ryner (not reading)]

Attachment: artifacts on mac os x

I applied the patch on Mac OS X (10.3) and I'm seeing artifacts in the
scrollbar corner area, as shown in the screen shot.

Comment 59

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Are these new artifacts or have they been visible before?

What theme is in effect here? Is this loading
"themes/classic/global/mac/nativescrollbars.css"? If so, perhaps -moz-Dialog
isn't defined?

Comment 60

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: simple testcase

Getting the dumps from the layout debugger of the frames and views for this
testcase might also help.

Comment 61

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Another thing would be to try changing the scrollcorner color in
nativescrollbars.css to something like "green" and see if it has any effect
whatsoever.

Comment 62

[Brian Ryner (not reading)]

Ok, so the problem I saw was just because the firebird scrollbars.css wasn't
patched.

However, after doing so, I notice that the scrollbar corner is the wrong color.
 It's gray, whereas in a native app it's white.

Comment 63

[Robert O'Callahan (:roc) (email my personal email if necessary)]

OK, how about we check in this patch now and let the theme designers set the
right color for 1.6final? (since I have no idea how to set the right color for
Mac Firebird)

Comment 64

[Brian Ryner (not reading)]

Comment on attachment 135782 [details] [diff] [review]
new patch

Ok, sure.  Let's get the layout changes in now, then we can figure out whether
-moz-dialog is the right color on Mac (and other platforms).

Comment 65

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 135782 [details] [diff] [review]
new patch

This patch fixes a longstanding polish issue. We need it for 1.6b so that theme
designers can update their themes to set the correct color for the corner box
where the two scrollbars meet.

Comment 66

[Asa Dotzler [:asa]]

Comment on attachment 135782 [details] [diff] [review]
new patch

a=asa (on behalf of drivers) for checkin to 1.6 beta.

Comment 67

[Robert O'Callahan (:roc) (email my personal email if necessary)]

checked in. up to the themes people to fix any remaining issues

Comment 68

[noririty]

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

Comment 69

[Travis Chase]

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

Comment 70

[Jo Hermans]

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