Closed Bug 76197 Opened 24 years ago Closed 20 years ago

Scrollbars should look disabled when there's nowhere to scroll

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: braden, Assigned: neil)

References

Details

Attachments

(7 files, 2 obsolete files)

overflow: -moz-scrollbars-vertical applied to <html>
(deleted), image/png
Details
height: 100.1% applied to <html>
(deleted), image/png
Details
Using maxpos instead of disabled
(deleted), patch
Details | Diff | Splinter Review
Complete patch
(deleted), patch
janv
: review+
roc
: superreview+
Details | Diff | Splinter Review
testcase
(deleted), text/html
Details
scrollbars.css+scrollbar.xml patch
(deleted), patch
mconnor
: review+
Details | Diff | Splinter Review
toolkit patch merged to trunk (checked in)
(deleted), patch
Details | Diff | Splinter Review
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: 23 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.9 → mozilla1.2
-moz-scrollbars-vertical does the wrong thing here. See screenshot.
Attached image height: 100.1% applied to <html> (deleted) —
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 patch (deleted) — — Splinter 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: 23 years ago → 20 years ago
Resolution: --- → FIXED
Attached file testcase (deleted) —
(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) (deleted) — — 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.

Attachment

General

Creator:
Created:
Updated:
Size: