Closed Bug 76197 Opened 21 years ago Closed 17 years ago

Scrollbars should look disabled when there's nowhere to scroll

Categories

(Core :: Layout, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: braden, Assigned: neil)

References

Details

Attachments

(7 files, 2 obsolete files)

Mozilla's interpretation of "overflow: auto" does not provide a means of having
a disabled vertical scrollbar present, which is enabled once there is an actual
need to scroll. This behavior is desirable to prevent the reflow that would
occur when a scrollbar "pops" in.
Severity: normal → enhancement
Blocks: 68390, 72540
The Mozilla "bouncing scrollbars" feature creates an insolvable problem in some 
existing e-commerce site designs.

The problem worked around because of the combination of 2 "features":
1) the width of a page cannot be calculated by any means
   (even the browser does not know it until the page is fully loaded)
2) FRAME: "scrolling = yes not implemented: forced scrollbars don't show up"

The "bouncing scrollbars" breaks frames designs that are as basic as having 2 
rows with proportionally aligned content.
Proportional alignment is a necessity wherever a window is resizable or the 
screen size is not fixed, both of which are fundamental boundary conditions on 
the web.

As commercial e-commerce site providers, we are extremely disappointed that some 
misguided Mozilla designers are prepared to break compatibility with all other 
browsers in the market (Severity: Enhancement, Priority: Nothing, Target 
Milestone: Nothing).

We are also disappointed that such a basic arithmetic failure can get beyond the 
design stage.

We recognise and appreciate the efforts of the Mozilla team in the area of DOM 
and CSS standards compliance.

However, for us, these CSS and DOM related improvements are overshadowed by more 
basic issues such as this.
not a table specific bug, reassigning.
Assignee: karnaze → attinasi
Reassigning to Eric.
Assignee: attinasi → evaughan
targeting
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.1
Keywords: mozilla0.9.9
The discussion whether the vertical scrollbar should always be visible takes
place in bug 72540. Marking DUPLICATE.

*** This bug has been marked as a duplicate of 72540 ***
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
This is not a duplicate of bug 72540. Note that this bug depends on bug 72540.
This bug is something that can (and should) be addressed regardless of whether
or not bug 72540 is resolved WONTFIX.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
I'm changing the summary of this bug to reflect the current issue.

The overflow property values

  -moz-scrollbars-none
  -moz-scrollbars-horizontal
  -moz-scrollbars-vertical

provide a means of maintaining a scrollbar, and thus avoiding reflow. However,
these are somewhat unsightly in that the scrollbars do not appear disabled when
there is nowhere to scroll.
No longer blocks: 68390
Severity: enhancement → minor
Summary: Need a way to display disabled vertical scrollbar → Scroll bars should look disabled when there's nowhere to scroll
Not a blocker for bug 72540. That bug has become about whether space should be
reserved for a vertical scrollbar for "overflow: auto".
No longer blocks: 72540
After much consideration (documented in bug 48634), it seems that bug 48634 is
merely a duplicate of the effect of this bug.

So, that being said, what is being done with regards to this bug?
Nothing so far, since this is currently assigned to someone who has not been
with the project for months.

Reassigning to layout.  resetting target milestone, which was set sometime in
Dec 2001.
Assignee: eric → attinasi
Severity: minor → major
Status: REOPENED → NEW
Target Milestone: mozilla1.1alpha → ---
Blocks: 48634
Keywords: mozilla0.9.9mozilla1.2
-moz-scrollbars-vertical does the wrong thing here. See screenshot.
This appears to be what -moz-scrollbars-vertical is attempting to do, but
failing.
Cc'ing dbaron, who might be willing to take this bug from attinasi (who is no
longer hacking on Mozilla).

/be
Do XUL scrollbars implement the ability to be disabled?  What about nsITheme
scrollbars?
Comment on attachment 90532 [details]
height: 100.1% applied to <html>

100.1%? was 100% not enough? :-)
Priority: -- → P2
Target Milestone: --- → Future
*** Bug 209939 has been marked as a duplicate of this bug. ***
.
Assignee: attinasi → other
Severity: major → normal
Priority: P2 → --
QA Contact: petersen → ian
Summary: Scroll bars should look disabled when there's nowhere to scroll → Scrollbars should look disabled when there's nowhere to scroll
Target Milestone: Future → ---
See http://bugzilla.mozilla.org/show_bug.cgi?id=72540#c154

Basically, I said the following identifiers should be removed (they don't work
anyway):
  -moz-scrollbars-none
  -moz-scrollbars-horizontal
  -moz-scrollbars-vertical

Instead, we should have:
scrollbar-y: -moz-always-on | auto | -moz-always-off
scrollbar-x: -moz-always-on | auto | -moz-always-off
dbaron mentioned the CSS3 recommendation covered this
http://www.w3.org/TR/2002/WD-css3-ui-20020802/#overflow-x

So I rewrote the comment in bug 72540 to reflect that. Disregard comment 19 on
this bug. Since this likely the bug that overflow-x and overflow-y
implementation details will be discussed, below is what I said (minus the rant)
in http://bugzilla.mozilla.org/show_bug.cgi?id=72540#c156

***

I always say developers should leave information for things they'd like done but
aren't going to do themselves. I will therefore stick true to my words. Here are
some implementation details:

XPI would not be the route to go on this. Use overflow-x, and overflow-y, which
is part of the CSS3 recommendation.
http://www.w3.org/TR/2002/WD-css3-ui-20020802/#overflow-x

This should go into XPCOM

http://lxr.mozilla.org/seamonkey/source/content/shared/public/nsCSSKeywordList.h
<- mapping to identifier
http://lxr.mozilla.org/seamonkey/source/content/shared/src/nsCSSProps.cpp <-
mapping to XPCOM identifier macros
http://lxr.mozilla.org/seamonkey/source/layout/base/public/nsStyleConsts.h <-
Identifier macros defined
http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsGfxScrollFrame.cpp#640
<- Example implementation
http://lxr.mozilla.org/seamonkey/search?string=mOverflow <- All implementations
http://lxr.mozilla.org/seamonkey/source/content/shared/src/nsStyleStruct.cpp#1069
<- Define scrollbar-y and scrollbar-x in nsStyleDisplay
http://lxr.mozilla.org/seamonkey/source/content/shared/public/nsStyleStruct.h#734
<- Define it also in header file

Good luck in implementing to whomever decides to take this on.

****
(In reply to comment #20)
> Since this likely the bug that overflow-x and overflow-y
> implementation details will be discussed,

It shouldn't be.
Assignee: core.layout → neil.parkwaycc.co.uk
Status: NEW → ASSIGNED
Attachment #157148 - Flags: superreview?(roc)
Attachment #157148 - Flags: review?(roc)
Setting attributes during reflow is evil. I know we already do it, but we want
to get rid of it, not add to it.

Is there a real user of this --- some theme that wants it?

If so, can the theme draw its disabled state based on the maxpos value being
zero? Or is that nasty?
Windows "Native theme" scrollbarbuttons expect to use disabled="true" - with
this patch and a tweak to scrollbar.xml (not shown) they work automatically.

I'll investigate the possibility of using maxpos="0".

Either way, the attribute would have to be inherited into the xbl.
This is just the start, it switches the windows native theme code from disabled
to maxpos for scrollbarbuttons. It would need to be ported to the other native
themes, plus of course the XBL and CSS would still be needed although it would
be slightly different to that for the disabled approach of attachment 157148 [details] [diff] [review].
Comment on attachment 157148 [details] [diff] [review]
Automatically set the disabled attribute on scrollbars

minusing in anticipation of a new patch
Attachment #157148 - Flags: superreview?(roc)
Attachment #157148 - Flags: superreview-
Attachment #157148 - Flags: review?(roc)
Attachment #157148 - Flags: review-
Attached patch Complete patchSplinter Review
OK, so this contains:
1. Code to post disabled attribtue changes
2. XBL to forward the disabled attribute to the scrollbar parts
3. CSS for Classic theme for those platforms without native appearance
4. CSS for Modern theme
Attachment #157148 - Attachment is obsolete: true
Attachment #157719 - Flags: superreview?(roc)
Attachment #157719 - Flags: review?(varga)
Comment on attachment 157719 [details] [diff] [review]
Complete patch

+nsGfxScrollFrameInner::SetEnabled(nsIBox* aBox, nscoord enabled, PRBool
aReflow)

PRBool aEnabled
Attachment #157719 - Flags: superreview?(roc) → superreview+
Attachment #157719 - Flags: review?(varga) → review+
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago17 years ago
Resolution: --- → FIXED
Attached file testcase
(a testcase, just for completeness)

It works great in Mozilla. Thanks Neil!
But it doesn't seem to work in Firefox just yet.
Probably because Firefox has it's own scrollbar xbl code, right?
http://lxr.mozilla.org/seamonkey/source/toolkit/content/widgets/scrollbar.xml
Attached patch scrollbar.xml patch for firefox (obsolete) — Splinter Review
This makes it work for Firefox (in my debug build).
I just copied more or less, the the changes from the other patch from
scrollbar.xml
Martin, you probably want to also port the CSS changes for Classic from Neil's
patch, in order to ensure this fixes platforms that don't have nsITheme hooked up.
*** Bug 203645 has been marked as a duplicate of this bug. ***
Ok, I've more or less copied the code from Neil's scrollbars.css code to the
Firefox's scrollbars.css.
Attachment #159842 - Attachment is obsolete: true
Attachment #159851 - Flags: review?(mconnor)
Blocks: 263696
Attachment #159851 - Flags: review?(mconnor) → review?(firefox)
*** Bug 203645 has been marked as a duplicate of this bug. ***
So the bug is marked fixed (because it's fixed on the suite), and the Firefox
patch is bitrotting here unreviewed.
Would it be appropreate to submit a separate Firefox version of this bug, to
keep it on the radar for fixing in Firefox?
Uri: I think it would be, as the core code is supposedly fixed. I think you
should mention this bug in the bug description, and provide a link to the
bitrotting patch.

( The fact this is only fixed in one product is an example of
http://forums.mozillazine.org/viewtopic.php?t=171872 and
https://bugzilla.mozilla.org/show_bug.cgi?id=247730 )
Blocks: 271974
bug 271974 is the firefox (or toolkit, really) version for this patch.
Comment on attachment 159851 [details] [diff] [review]
scrollbars.css+scrollbar.xml patch

r=mconnor@steelgryphon.com

Sorry about the delay.	Thanks for porting this!
Attachment #159851 - Flags: review?(firefox) → review+
Comment on attachment 167931 [details] [diff] [review]
toolkit patch merged to trunk (checked in)

toolkit port checked in.
Attachment #167931 - Attachment description: toolkit patch merged to trunk → toolkit patch merged to trunk (checked in)
Verified fixed since it was checked in.
Status: RESOLVED → VERIFIED
Blocks: 274036
but how to put back scrollbars
my site is jumping. if i click links, some links have scrollbar, some not...
*** Bug 286456 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.