134642 - Scrollbars in classic skin are off by a pixel at the bottom and left

Status: RESOLVED EXPIRED

(SeaMonkey :: Themes, defect)

Description

[Mike Pinkerton (not reading bugmail)]

In the mac classic skin on os9, if you look at a page with horizontal and
vertical scrollbars, you'll see that there is 1px of space between the bottom of
the vertical scrollbar and the resizer as well as a 1px gap between the status
bar and the bottom of the horizontal scrollbar.

looks really bad and makes us look like a bunch of amatures.

Comment 1

[Mike Pinkerton (not reading bugmail)]

andreww, we probably won't ship another os9 version after this. so not fixing it
now means never fixing it. i'd suggest a TVF of 1.0 or 1.01.

Comment 2

[Matthew T (active 1999-2002)]

This bug was introduced by Hewitt when he replaced the Windows Classic and Mac
Classic versions of navigator.css with a cross-platform version. In a document
window, Mac OS provides its own inner edge for the window frame, but Windows
does not; Windows apps are expected to add their own inner edges. This appears
to be the sole purpose of the #content rule in navigator.css. Without being able
to test it, I'm confident that removing this #content rule makes Mac Classic
look much better (though not perfect -- I'll get to that in a moment), but Mabus
tried it and found that it made Windows Classic look rather odd.

So, to fix this bug, do the following:
(1) Clone navigator.css into win/navigator.css and mac/navigator.css, delete
    the XP navigator.css, and update the relevant jar.mn file accordingly.
(2) Delete the #content rule in mac/navigator.css.
(3) Get the above reviewed and checked in. This returns us to the pre-Hewittage
    state.

Then, either:

(4a)Special-case the horizontal scrollbar of the viewport to remove its bottom
    1px black border (that's already provided by the bottom of the window or
    the top of the status bar), and the vertical scrollbar of the viewport to
    remove its rightmost 1px black border (that's already provided by the right
    side of the window). The following, or similar, may fix this:
    #content>scrollbar[orient="horizontal"]>thumb,
    #content>scrollbar[orient="horizontal"]>thumb:active {
        border-width: 2px 2px 1px 2px;
        -moz-border-bottom-colors: -moz-mac-accentlightshadow;
    }
    #content>scrollbar[orient="vertical"]>thumb,
    #content>scrollbar[orient="vertical"]>thumb:active {
        border-width: 2px 1px 2px 2px;
        -moz-border-right-colors: -moz-mac-accentlightshadow;
    }
    #content>scrollbar[orient="horizontal"]>scrollbarbutton,
    #content>scrollbar[orient="horizontal"]>scrollbarbutton:hover:active {
        border-width: 2px 2px 1px 2px;
        -moz-border-bottom-colors: #AAAAAA;
    }
    #content>scrollbar[orient="vertical"]>scrollbarbutton,
    #content>scrollbar[orient="vertical"]>scrollbarbutton:hover:active {
        border-width: 2px 1px 2px 2px;
        -moz-border-right-colors: #AAAAAA;
    }
    You'll need to fix #content>scrollbar[...]>slider in a similar fashion, but
    first xulscrollbars.css will need to be fixed to use -moz-border-*-colors
    instead of url(chrome://global/skin/scrollbar/slider-hrz.gif) and -vrt.gif.
    (Look ma, a miniscule footprint win!)

Or:

(4b)In the place of the previous #content rule, write:
    #content {
        margin: -1px;
        padding: 0 1px 1px 0;
    }
    If this moves the scrollbars without moving the content, as I hope it does,
    this will have the effect of moving the various edges of the scrollbars
    either `under' or `over' the edge pixel of the surrounding chrome or window
    edge (it doesn't matter whether it's under or over, since they're all 1px
    solid black). Then smile sweetly at the super-reviewer and convince them
    that the ugliness of the scrollbars is much more important than a 1px
    inaccuracy when a Web author adds a border to their Web page.

Comment 3

[Matthew T (active 1999-2002)]

Correction: In (4b) above, `padding: 0 1px 1px 0;' should be `padding: 1px'.

`First xulscrollbars.css will need to be fixed to use -moz-border-*-colors ...'
To do that, make a patch which deletes
<chrome://global/skin/scrollbar/slider-hrz.gif> and <.../slider-vrt.gif>, and 
replaces the two `slider' rules in themes/classic/global/mac/xulscrollbars.css 
with the following three:

slider {
  background: #AAAAAA;
  border-style: solid;
}
slider [orient="horizontal"] {
  -moz-appearance: scrollbartrack-horizontal;
  height: 16px;
  border-width: 3px 0 3px 2px; /* strange but true */
  -moz-border-top-colors: #000000 #77777 #88888;
  -moz-border-bottom-colors: #000000 #CCCCCC #BBBBBB;
  -moz-border-left-colors: #77777 #88888;
}
slider[orient="vertical"] {
  -moz-appearance: scrollbartrack-vertical;
  width: 16px;
  height: none;
  border-width: 2px 3px 0 3px;
  -moz-border-top-colors: #77777 #88888;
  -moz-border-right-colors: #000000 #CCCCCC #BBBBBB;
  -moz-border-left-colors: #77777 #88888;
}

This should be done even if (4b) is chosen, since it fixes an
as-yet-unreported cosmetic bug (missing short shadows in the scrollbar trough). 
Any volunteers?

Comment 4

[Vidar Haarr (not reading bugmail)]

Attachment: Win32 Classic screenshot

This screenshot shows how Mozilla (win32) looked when I removed the #content
rule from navigator.css.

As you can see, all the inner borders are missing.

 - Mabus -

Comment 5

[Vidar Haarr (not reading bugmail)]

Attachment: No sidebar in this one.

right.. no sidebar this time ;)

Comment 6

[Stephen Walker]

Attachment: patch

xulscrollbars.css part of the patch. The images still need to be removed, but
that requires cvs access, which I don't have.

Comment 7

[Matthew T (active 1999-2002)]

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

Comment 8

[andreww]

Comment on attachment 85956 [details] [diff] [review]
patch

r=andreww

Comment 9

[Samir Gehani]

Nav triage team: nsbeta1-

Comment 10

[Simon Paquet [:sipaq]]

This bug is targeted at a Mac classic platform/OS, which is no longer supported
by mozilla.org. Please re-target it to another platform/OS if this bug applies
there as well or resolve this bug.

I will resolve this bug as WONTFIX in four weeks if no action has been taken.
To filter this and similar messages out, please filter for "mac_cla_reorg".

Comment 11

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 12

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420