Closed Bug 72540 Opened 23 years ago Closed 21 years ago

Web pages should have a persistent scrollbar for all pages

Categories

(Core :: Layout, defect, P4)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: ian, Assigned: hewitt)

References

(
URL
)

Details

(Whiteboard: Take discussion to the forum topic 569350 at the above URL)

Attachments

(4 files)

or, base the page alignment on frame instead of frame+scrollbar/lack-thereof?
413 bytes, text/plain
Details
HTML Testcase
1.38 KB, text/html
Details
eye problem caused by this.
266.12 KB, image/gif
Details
Work around
141 bytes, text/plain
Details 
We could eliminate at least one reflow per page load on big pages if we always 
showed the vertical scroll bar (like Windows IE).

There was some talk about this recently. This might therefore be a dup.
Keywords: perf
Never mind.  Thorough profiling and jrgm's tests show that this is not a problem.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
Sorry to reopen this. But it's not a matter of performance but a matter of
aesthetics. Imagine a website with short and long pages, all pages having a
unified layout, with one box centered on the page. On the short pages, since
there's more horizontal space, the centered box will slightly shift right.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Reassigning to the skins team.  It's trivial for me to fix this on my end, but 
I need disabled scrollbars supported in all skins first.

hewitt, when full support for disabled scrollbars is in, you can reassign this 
back to me.
Assignee: hyatt → hewitt
Status: REOPENED → NEW
Depends on: 76197
hyatt told me he didn't need this after all
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → INVALID
This was reopened because of a request that all pages have scrollbars for
aesthetic reasons.  Resolving it as invalid because hyatt doesn't need it
doesn't make sense.
sorry, I didn't read all the comments.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Now that bug 76495 is fixed, I'm not seeing many unsightly reflows from the 
scrollbar appearing while a page is loading.  I have a fast connection, though.

Fwiw, here's a page that looks better without permanent vertical scrollbars:

<body style="margin: 0px">
<style> iframe{ border: none; width: 100%; height: 100%; margin: 0px; }</style>
<iframe src="http://www.mozilla.org"></iframe>
I think this should be implemented only for the top-level BODY, as that is the
case for which reflows are most of a problem. FRAMEs and IFRAMEs (as in Jesse's
example) are often designed to fit (at typical window and font sizes) in the
space available, so the unattractiveness would be worse than the visual
instability in those cases. (In some cases, insisting that a narrow navigation
frame have a vertical scrollbar would result in it scrolling horizontally, when
otherwise it wouldn't have.)
OS: Windows 2000 → All
Hardware: PC → All
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 (Priority: nothing, Target Milestione: 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.
> 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 (Priority: nothing, Target Milestione: nothing).

All other browsers?  You mean IE for Windows?  Netscape 4 for Windows, Opera 5
for Linux, and Konqueror all behave the same as we do.  So far that's 1 for 4,
not all (among the browsers I have access to right now).

Why is it so hard for "e-commerce" sites to deal with this?  Can't you just say
that certain things have width of 50% or whatever and let the browser deal with
it?  Pages bounce around while loading for many other reasons (partial content,
image loads if no height/width are specified, etc.).
David, I am sorry this is primary school arithmetics that you fail to grasp.

In all other browsers, the usable width of the page is always the inner width of 
the frame minus the witdth of the scrollbar, whether it is shown or not.

If, as it is the case with Mozilla ONLY, the usable width is variable, either 1) 
full width OR 2) width minus scrollbar width, then you get the "bouncing 
scrollbars" feature.

If I follow what you describe "Can't you just say
that certain things have width of 50% or whatever and let the browser deal with
it?", then 50% or whatever other proportianl value is ambiguous in that it has 
TWO possible physical results for width depending on the existence of a vertical 
scrollbar.

And because the existence of the vertical scrollbar even changes dynamically 
during the rendering of the page, one cannot simply let the browser deal with it 
because how the browser deals with it cannot be synchronised across frames.

There is no interface such as a callback that can be used to re-render an 
adjacent frame depending on the changed width of another. And quite honestly, I 
wouldn't want to open this can of worms while Mozilla cannot even deal with the 
normal things in life - which closes the loop to what I want to say: Keep it 
simple!

So what you're saying is that *when* Mozilla doesn't create a scrollbar, it does
page width calculations as if the scrollbar were not going to take up space,
whereas in other browsers that don't display a scrollbar all the time, they
leave space for the scrollbar.  That's different from what you said the first
time, and I just checked that it is true for Netscape 4.x and Opera 5.x, but not
for Konqueror.

Finally, if you're going to be insulting, you're not welcome here.  So either be
civil or go away.  Thanks.
David, your second statement is correct.
There must be a way to know the width of the page in advance.
In other words it is not GENERALLY acceptable that the page width is 
unpredictable e.g. that it depends on the length of the page.
If such mechanism does exist as in Mozilla, then there should be a way to 
disable it (SCROLLBARS=NO). Otherwise web designers have to write their own 
layout managers that use scripts to generate pages with pixel values instead of 
percent values which introduces a new level of complexity into some frame based 
web designs, something that is not very welcome in the web designer community.
Severity: normal → minor
Status: REOPENED → ASSIGNED
Priority: -- → P4
Target Milestone: --- → Future
bht: Could we have an example of such a page?
Ian, I would like to privide this but unfortunately I am not allowed to.
But I'll try to demonstrate the concept.
The real world consequences are simple:

Table columns in a scrollable data frame get out of alignment with descriptive
columns in a header frame, depending on the length of the data.
The dilemma is that the width of a page depends on its length. Both the actual
width and length are not available for any computations, inevitably leading
to problems that cannot be solved.
A possible, but ugly workaround is to generate dummy lines in such a way that
scrollbars are always present, and an "end of page" literal such as users don't
get too confused trying to explore the dummy portion of the page.
I'd love to see this marked invalid.  As a web developer myself, I hate seeing 
the space where the scrollbar would be if needed.  It makes my pages look 
unprofessional when there is a large white space down the side of the page.  How 
can your pages possibly scale to different resolutions if you can't handle the 
10 pixel difference of having a scroll bar or not?  Finally, the majority of 
other window's apps both hide the scrollbar, and make that space usable when 
they are hidden.
kerz, I think we have to face the fact that the solution is not that simple.

Mozilla's current behavior breaks designs that work well with other browsers,
and the rather ugly dynamic "bouncing scrollbars" effect is not necessarily
present in other window applications.

The issue is that a browser is a more complex application that cannot be
compared with conventional windows applications that can afford to use
off-screen rendering to a wider extent and just hide the content before it is
fully rendered!

In contrast, dynamic requirements such as displaying a page that has not been
fully loaded over the network, require more sophisticated approaches.

IMHO, the current dilemma has been created by pushing the browser performance to
new heights without providing the means to control the complexity that comes
with this.

At a minimum, an option should be provided for web authors to control scrollbar
behavior.

A "scrolling" attribute in the body tag would be a logical choice (already
present in the frame tag).

BTW this is broken in frames, please refer to bug 44306 "scrolling = yes not
implemented: forced scrollbars don't show up."
Also please refer to bug 48634 "Vertical scrollbar breaks window.innerWidth"
and bug 76197 "Need a way to display disabled vertical scrollbar"
Sorry about this. But while this reflow stunt may be an impressive engineering
achievement, the benefits definitely aren't there if the behavior is uncontrollable.
At present (things being as they are), this just another can of worms.
I agree with Kerz.  I don't like IE's permanent vertical scrollbar, because it 
makes forces me to focus on the right side of the screen in order to tell if 
the page can be scrolled.  Netscape 4's and Opera's permanant scrollbar-space 
looks ugly on pages with wide block elements that have borders.

Incremental reflow is a convenience for users, not for web developers.
As the original reporter of this bug I should point out that I no longer have an
opinion either way. This could be WONTFIXed without me reopening it.
Whiteboard: WONTFIX?
*** Bug 12234 has been marked as a duplicate of this bug. ***
*** Bug 94419 has been marked as a duplicate of this bug. ***
Blocks: 71668
I really hope this turns out as a WONTFIX. It doesn't seem like a "fix" at all
to me, and NC4* does not behave that way.  Needless clutter just "uglyfies" a
webpage and scrollbars steal desktop real-estate. When there is no use for them,
they should not appear. This is also how it works throughout the app.
Suggest remove 'perf' keyword as this no longer seems to be the issue at stake
in this bug. Also suggest remove the block on 71688 (page loading meta bug).

Personally really can't see why all mozilla users should have to lose screen
estate so that frameset-loving web designers have an easier life. And bug 44306
seems to cover their problems. Moreover, supporting a "scrolling" attribute on
'body' isn't the right thing to do unless it's part of the W3C spec for the body
element. 
I'm the person to blame for suggesting this idea to Hixie in the first place, 
and I did so for the sake of users rather than Web designers. The idea being 
that on a fast computer with a slow connection (== high incrementality), the 
constant disappearance and reappearance of the vertical scrollbar between pages 
would be annoying. However, no other Mac browser that I know of has a permanent 
scrollbar, and I don't mind the disappearance and reappearance of the scrollbar 
too much, so it doesn't seem to be that important.

What might be important, though, is that without a permanent vertical scrollbar 
*or* space left available for it, the width of the canvas can (in some cases) 
depend on the height of the canvas *and* vice versa simultaneously. If the 
canvas is long enough, the viewport gets a vertical scrollbar, which makes the 
canvas narrower, which causes a reflow where the canvas gets even longer. This 
might only be as harmless as causing the occasional document to have both 
horizontal and vertical scrollbars when neither were actually necessary (a 
similar problem was present in the Program Manager in Windows 3.x). Or, in a 
freak case, I *think* it could cause an infinite loop where a script was 
repeatedly adding/subtracting content in order to deal with a viewport which 
alternately did and did not have a scrollbar. (I don't think this is that
far-fetched; it's only a small step from <http://www.msn.com/>, which -- if 
you're using MSIE for Windows -- shows or hides a yellow box of features 
depending on the width of the browser window.)
I agree. the height/width dependency is a fundamental dilemma.
It is a new source of instability. I must admit that I cannot propose a solution
for this other than a new scrollbars body tag that would control scrollbar behavior.
Well I don't like permanent scrollbars. So one proposal is... another pref
[Fortunately the one frame of mine where it matters already has scrollbars=no]
...another option is some (Gecko-specific?) CSS e.g.
body > :-moz-vertical-scrollbar { visibility: collapse; }
body:-moz-vertical-overflow > :-moz-vertical-scrollbar { visibility: normal; }
This way it's the page designer's fault if the page is unstable
:-)
bht: i don't understand your problem to be honest. How could the scrollbar 
behaviour restrict your site design? You say:

> If I follow what you describe "Can't you just say that certain things have
> width of 50% or whatever and let the browser deal with it?", then 50% or
> whatever other proportianl value is ambiguous in that it has TWO possible
> physical results for width depending on the existence of a vertical scrollbar.

i'd say that there are a whole lot more then 2 different possible physical 
results, when the user resizes the browserwindow the physical size avalible for 
content goes through a wide array of values. That is why HTML (well, CSS 
really) layout is flowing, instead of positioned like pdf.

Could you please explain in more detail how the scrollbar causes problem for 
you, a small example would be great.


mpt: there is no risk that the browser goes into an eternal loop of 
adding/removing scrollbars, there is special code to prevent that. But yes, it 
is possible that we end up with showing both scrollbars when neither is needed. 
However this is *very* uncommon, and can only happen when the user resizes the 
window.

I'm sure that it would be possible to write a script that would end up in a 
loop of adding and removing something to the page while a scrollbar is added 
and removed. However this is just as possible with the horizontal scrollbar 
(which all browser dynamically add) as it is with the vertical scrollbar, and 
has to my knowledge never happened, so I wouldn't worry too much about that. 
Also, there is a gazillion way to create a fubar'ed script, there's just no way 
stopping people doing it :-)


So all in all, unless someone comes up with a (resonable) design that is 
impossible to create due to the maybe-existence of the scrollbar i would say 
that this should be WONTFIXed

Jonas, the application requirement is to get a predictable canvas width.
In particular, a fixed scrollbar width must be reserved.

If not, then the following occurs in case where frame 2 has no scrollbar:

......................................V--Must be reserved for scrollbar
         |         |                |  |
Line No  | Item ID | Description    |  | <- Frame 1
=========+=========+====================    fixed
       1 | CAT-1     | Foobar_1        |  | 
---------+-----------+-----------------|  | <- Frame 2
       2 | CAT-2     | Foobar_2        |  |    scrollable
---------+-----------+-----------------|  |    no scrollbar

Col 1 10% Col2 10%    Col3 Remainder

Both frames have tables whose columns must line up.
Widths are specified in relative percent values as to be independent from screen
resolution and user re-sizing.
In reality and in this line art drawing, columns in frame 2 that are coded
exactly the same way as in frame 1 get allocated different width depending on
scrollbar existence in frame 2.
Strictly speaking, frame 1 would have to reflow with added scrollbar space
depending on the outcome in frame 2.

It's really simple.

I would be very disappointed if the Mozilla team capitulated here.

WONTFIX is not a solution.

So far I haven't seen a cross-browser compatible solution for scrollable lists
with aligned fixed headers that would not be broken by this.
I think IE has special table tags for this but with frames one can do this for
every browser (It even works with IE3, Netscape 3, HotJava etc.).
> I would be very disappointed if the Mozilla team /capitulated/ here.
please don't use that word. imo your usage is wrong and any 'fix' would be a 
capitulation.

if you're using css, i'd imagine you could use iframe(s) instead of a frameset 
and you wouldn't have the hypothetical problem you're describing.

Thanks for the suggestion. But iframes don't work in Netscape 4. Frames do work.
So I need another word for /capitulation/. I replace it with "inconsistency",
something softer.

IMHO the inconsistency is that a new behaviour was introduced that breaks
existing designs without providing a workaround option to emulate the original
de facto standard behaviour.

The lack of support for "scrolling = yes" with reserved space for scrollbars
even if not shown is an inconsistency.

Increasing screen real estate by not showing scrollbars is a good thing.
Breaking the arithmetics to calculate the available screen width is "inconsistent".

Not allowing web designers to suppress the bouncing scrollbar effect is also
"inconsistent".

It is a dilemma that a new, not yet standardised tag would be required to
control  accurate behaviour. Too bad IMHO. Mozilla needs it.
Blocks: 48634
Disagree with this bug also. This is one one of the thing I like with Mozilla,
not having the vertical scrollbar if not necessary.
Okay.  I started up another bug
http://bugzilla.mozilla.org/show_bug.cgi?id=94419 which has since been marked as
a duplicate of this one and so I;m making my comment in here with the hope that
it will make a difference and put Mozilla up front of all the rest.

The way I see it is that the scrollbars vertical or horizontal are not, and in
my opinion should not, be part of the HTML layout.  They are purely there so as
to allow the scrolling of the canvas/frame that they are related to.

So If your canvas/frame, not window and by that I mean the space available after
taking away any space taken up by other widgets, like say the sidebar but not
the window borders, is say 600 pixels wide then the rendering should be working
on that and not take into account the vertical scrollbar to the right because
this is part of the window controls.  This would should avoid the problem with
the bouncing and possible looping situations as well.

No I have no real programming prowess when it comes to C or C++ and their way of
handling widgets and other controls but I would think that the way to do it
would be to place the scrollbars above the canvas used for rendering.

I imagine this would be possible?

*** Bug 125832 has been marked as a duplicate of this bug. ***
This bug has been dormant for some time but it would be nice to see some
resolution.  Many people are focusing on the aesthetic blight of having unusable
space where the scrollbar would be.  But the real issue comes to light when a
series of pages is considered.  An example:

Lets assume a family of pages where the content is centered in a constant-width
table.  The length of the table depends on the content to be displayed.  Some
pages have enouh content to force a scrollbar, most do not.  There are graphical
elements placed at the top and bottom of each table for navigation.

When the scroll bar is present, the entire document (which is centered and
constant-width) shifts over by half the width of the scroll bar.  This means
that the navigation elements have now moved, and if the visitor is rapidly
clicking through a series of these pages, the mouse cursor may no longer be over
the nav graphic (or worse, over a different graphic, such as jump-to-last-page).

There is no way to fix this problem in Mozilla, at least no way that I can think
of.  IE does not have this issue because of the permenant vertical scroll; NS4
and Opera reserve the scroll space, making the table appear slightly off-center
but at least its position is fixed.  Mozilla causes the table to jitter between
pages, and this is unacceptable for me.

It is my opinion as a web designer that there should be a CSS rule or BODY tag
that reserves vertical-scrollbar space.  Whether or not it should be *default*
behavior is not my concern.
I second to Henry because resolutions used in modern pcs are so large that the
loss of horizontal space isn't a big issue anymore, when compared to performance
gains.
Also if the scrollbar-reserved space is _really_ needed then that page can be
put in a frame with a scrolling=no attribute and - if required - an additional 0
width frame so users won't notice the frameset setup.

In other words even the most extreme requirements can be met if the scrollbar
space was reserved as in IE and Netscape 4, while the bouncing scrollbar
nuisance would be eliminated.

BTW all of the few users I know who use Netscape 6 think it sucks because of this.
I strongly _discourage_ the frames-solution proposed by bht@actrix.gen.nz. This
is not a solution, not a work-around, not a hack. It's pure nonsense. While
Mozilla is trying to stick to the standards, are we going to promote the use of
frames, which is depracated because of thousand reasons I'm not going to repeat
here.

Please give us either an inactive vertical scrollbar or an area as wide as the
vertical scrollbar that doesn't count towards the width of the page, but that
takes the background-color and background-image of the page.
Erich.Iseli@iseli.org, would you please provide a reference to an official and
widely accepted document i.e. a W3C standards paper that declares frames
deprecated. I am always interested in the latest developments such as the one
you are referring to.
bht@actrix.gen.nz, http://www.w3.org/TR/xhtml11/doctype.html#s_doctype is the
latest version of xhtml, which got rid of all depracated elements from html.
There is no mention of frame, frameset and iframe. iframe will be replaced by
object, but obviously, the "frames" are history.
How about my suggestion about 8 comments above.  Make the scrollbars a part of
the interface and not the internal frame/canvas.

This would also possibly mean that recalculations because of wrapping caused by
the addition of scrollbars would be reduced and therefore a possible performance
gain.

Again let me reiterate that I have no knowledge of this level of programming in
C/C++ yet.  Although at this rate I might be tempted to give it a try just to
submit a possible patch.
Isn't there a CSS overflow: value that can be used to force scrollbars to appear
in a particular direction regardless of their necessity? Wouldn't body
{overflow: something} in the rare case that a page author really needs a
predictable scrollbar-presence be sufficient?
Yes, you can use CSS to make the vertical scrollbar always visible.

Always show both scrollbars:
data:text/html,<style> html { overflow: scroll; height: 100% } </style>
foo<p>foo<p>foo<p>foo<p>foo<p>foo<p>foo

Always show a vertical scrollbar and never show a horizontal scrollbar:
data:text/html,<style> html { overflow: -moz-scrollbars-vertical; height: 100% }
</style> foo<p>foo<p>foo<p>foo<p>foo<p>foo<p>foo

Conversely, you can make IE's vertical scrollbar auto (instead of always shown)
using <style> body,html { overflow-y: auto } </style>.  When you set IE's
scrollbar to auto, it works like Mozilla's, only taking up space when it's
there.  Guess what line I just added a line to my IE user-ie.css :)

(I like IE's overflow-y better than Mozilla's -moz-scrollbars-vertical, because
IE's allows me to make the horizontal scrollbar auto while making the vertical
scrollbar always visible.)
*** Bug 139822 has been marked as a duplicate of this bug. ***
*** Bug 76197 has been marked as a duplicate of this bug. ***
*** Bug 140434 has been marked as a duplicate of this bug. ***
I think we should WONTFIX this. I've been using several sites recently that look
stupid in IE because of the disabled scrollbar but look nice in Mozilla.
I think this should be fixed because both IE and NS4.x reserve the space for a
scrollbar whether or not it's the actual scrollbar or just the scrollbar area. 
In both cases the scrollbar area is seperate from the content area, as it should
be.  The scrollbar is a window control and should not be intermixed in with the
content area.  They sould be seperate.
My suggestion would be to copy the behavior of NS4.  Don't show the scrollbar if
it is not needed but don't let any of the page content occupy that space.  That
way the scrollbar space inherits the page background color so it's not ugly, and
the page content doesn't shift around depending on if the scrollbar's present or
not.

When using NS4 you really don't notice the space if the scrollbar's not there
but a person _will_ notice the content of a page shifting between scrollbar and
no scrollbar.  Especially since mozilla has supirior rendering to where the page
doesn't even appear to reload when switching pages, the content just changes
instantly.  So you notice that page shift.
Here, as I understand it, is the problem...

It is desired by a significant number of authors and users to have a situation where

 * The vertical scrollbar is present, but disabled until scrolling is required.
This prevents Unsightly Reflow.

 * The horizontal scrollbar is completely absent until it is needed. It doesn't
cause a reflow for the horizontal scrollbar to pop in, so there's no problem
with it doing so.

This is the default behavior for IE. However, AFAICT, there's *no way* to get
Mozilla to work like this. That should be fixed--with Mozilla extensions to CSS
if necessary. The default behavior of "overflow: auto" is less important than
having this functionality available *at all*.

As I see it, there are three table-based HTML page layout paradigms that we need
to concern ourselves with, regarding vertical scrollbars:

1) the centered table with width less than 100% of the browser window (the width
is usually specified absolutely in pixels)
2) the left justified table with a width equal to 100% of the browser window
3) the left justified table with a width equal to 100% of the browser window,
containing centered elements (that should not shift between similar pages of
varying lengths).

For each of the three layout paradigms above, a *different* vertical scrollbar
behavior is called for---and after reading the previous posts on this topic, I
have a feeling that most web designers may not agree on which vertical scrollbar
behavior is optimal for each of the cases above (and all those others that exist).

Which generally means, the decision should be left up to the web-designer (and
not the web-browser), through the following extension I'd like to propose to CSS:

vertical-scrollbar: auto | always-on | always-off | reserved

  auto - this is mozilla's current behavior, the scrollbar is rendered and the
page canvas resized when the page elements are taller than the page canvas. this
would probably remain the default behavior, optimal for pages without
table-based layout, and for tables with width=100% but without centered elements
(like navigation bars/menus) that might shift when the scrollbar is rendered for
longer pages.

  always-on - this is IE's current behavior, the scrollbar is shaded inactive
when not needed and is rendered when necessary. This would probably be optimal
for page designs that have centered elements within tables that occupy 100%
width of the page canvas.

  always-off - this would supress the rendering of the scrollbar regardless of
the height of the page elements

  reserved - this is the alternative proposed by wjbell@belletc.net (and others)
where the "vertical scrollbar zone" is reserved and takes on the color/image of
the page background, preventing page designs of the centered table variety from
shifting when the scrollbar is rendered.

I believe that the overflow attribute is not appropriate for this solving this
dilemma.
I agree with Justin Watt that that would be a good solution.  That way the page
author has the control to stop the shifting on a centered content page.

Then again, I wouldn't mind just having a default reserved space that inherits
the pages background color. Like someone else said, with todays resolutions and
monitors sizes nobody will miss a few pixels on the right hand side of the
screen. And with it being the same color as the background, you wont see
anything unsightly in your browser window.

I have a test page on my site that shows how the page jump turns a uniform
looking layout into somthing that looks broken.  Click on the test link from the
main page then use the back button to switch between.

http://www.belletc.net/
The following is an example of a page that I described as layout type (2) in
comment 51, where the table has a width of 100%, but no centered elements. I'm
guessing that that would probably *not* look good if the "vertical scrollbar
zone" was reserved by default and rendered with the background color/image of
the rest of the page (white):

http://www.sapient.com/

This layout technique I think is being called "fluid web design" in some
circles---meaning that the page is designed to expand gracefully to various
monitor resolutions and window sizes, using a combination of background images,
expanding tables with background images, and foreground elements. In this case
the web designer *wants* the page to stretch, panoramically, from one edge of
the browser window to the other, without shaded scrollbars or reserved scrollbar
space in the way.
However, yes, for all page layouts of the centered variety, ex:

http://www.unc.edu/

the solution proposed by wjbell@belletc.net is optimal, with the inactive
scrollbar solution (IE) being the next promising. Considering all this
discussion, one can see why the IE developers chose the easy way out. As far as
successfully preventing page shifts in a website environment, it is a smart way
to go.

A CSS extension as I proposed above is more creative though--gives more power to
the people. I sent a modified version of comment 51 to www-style@w3.org, as the
W3C's CSS working group is currently drafting CSS3. I imagine there may be
someone related to Mozilla or otherwise with closer connections to the W3C who
might be able to suggest this extension being included into the standard?
> The following is an example of a page that I described as layout type (2) in
> comment 51, where the table has a width of 100%, but no centered elements. I'm
> guessing that that would probably *not* look good if the "vertical scrollbar
> zone" was reserved by default and rendered with the background color/image of
> the rest of the page (white):

> http://www.sapient.com/

If you open up this page in NS4 it has the white reserved space, but it doesn't
look that bad.  But since this type of page is less common, and it's a certain
style of page, it might be better to have the default behavior of mozilla to
reserve the scrollbar space like NS4 but have the CSS options that Justin Watt
mentioned as an option for web developers to turn it off.  So maybe somthing like:

vertical-scrollbar: reserved (default) | auto | always-on | always-off

The scrollbar appearing and taking over content space just seems unclean to me.
 The scrollbar is part of the window controls and should be seperate from the
content screen and neither one should effect the other.

JMO
*** Bug 144033 has been marked as a duplicate of this bug. ***
This causes two annoyances for me:

1) Page reflow while during loading of a page.

2) Pages within a site may not look the same. A consistent feel is
   important to connect to a reader.

For pages that are short and intend to use up the space, a css
property to make the scrollbar disappear should be sufficient.

I admit though that this may be just a personal annoyance and that
others may not agree with me.

My vote is for this to be fixed rather than wontfixed.

Please make this a preference, if for no other reason to end endless debate.
If possible, anything GUI generating hard opposing opinion should be settable
preference. Nobody debates colors of hotlinks, almost nobody changes default. 
With this, it clear different people want different appearance and would value
preference setting if it were available. 

Can you even imagine "I know as a fact that God himself prefers blue hotlinks,
not green, so you sinful moron, don't ever again speak this blasphemy about
green." Some of what's above isn't far from such sillyness.....  
This isn't an end-user preference, it's a web author preference.  Letting the
user change the bahavior does nothing for the web page author with a centered
layout.

The best thing to do would be to have a CSS rule that allows authors to reserve
the scrollbar area and not let any content occupy that space, like what was
proposed in comment #51.
> 1) Page reflow while during loading of a page.

Paint suppression takes care of this most of the time.

> 2) Pages within a site may not look the same. A consistent feel is
>    important to connect to a reader.

If some pages have a scrollbar-width white gap and some don't, they look
different to me.  If some pages have a 780px-wide content box and some have a
box that's a scrollbar-width smaller, they look the same to me.  Do you have an
example that looks more consistent when space is reserved for the scrollbar?
> If some pages have a scrollbar-width white gap and some don't,
> they look different to me.

The idea is that the scrollbar area, if reserved, inherits the background
color, or image, of the page.

> If some pages have a 780px-wide content box and some have a
> box that's a scrollbar-width smaller, they look the same to me.

> Do you have an example that looks more consistent when space is
> reserved for the scrollbar?

Absolutly.  I have a test page set up here:

http://www.belletc.net/index.cgi?page=test

Go there in mozilla and watch the page shift areound.  Go there in NS4 and
see how the scrollbar area inherits the background color and the page doesn't
shift around.
What I meant to say was "If some pages have a scrollbar-width background-color
gap and some don't, they look different to me."  After looking at your testcase,
that's still my opinion.  One page has a large gap between "print version" and
the edge of the page in Netscape 4, and the other doesn't.
> One page has a large gap between "print version" and the edge of the page in
Netscape 4, and the other doesn't.

Yeah, but that's not nearly as unsightly as a whole page layout shifting. 
Besides, if it's a CSS rule that the page author can apply, 1: It will only
effect users that visit the pages where authors have specified it.  And 2: If
it's a CSS rule then a person who never wants that behavior can always put:

vertical-scrollbar: auto !important;

Or whatever in his/her usercontent.css.
> If some pages have a scrollbar-width white gap and some don't, they look
> different to me.  If some pages have a 780px-wide content box and some have a
> box that's a scrollbar-width smaller, they look the same to me.

Jesse: I guess you miss the point I was making. The current Mozilla behavior
forces me as an author to use a fixed width. I am doing something I don't believe
in because I want my sites to look good in Mozilla.

Now if I had the option to reserve 20px for the scrollbar then I would have
no reservations about using 100% width, because I know my pages would look
consistent in Mozilla.

Here's another use for reserved scrollbar space: menulists. Have you noticed
that on long menulists (e.g. preferences/languages/default) the scrollbar
appears on the right of the list, instead of within the list? Please could space
be reserved for the scrollbar on menulists as well. Of course a separate bug
would have to be filed on themes to use the feature.
Correct me if I'm wrong, but the bug description seems misleading based on
recent discussion, so altering it.
Summary: Web pages should always have vertical scrollbars → Web pages should have vertical scrollbar space reserved
Is there any backing in the specs for doing this? I think this should be marked
WONTFIX (and I originally reported it). I do think we should give authors a way
to control this (an @ rule, maybe?) but I think our current behaviour is best.
No longer depends on: 76197
I am inclined to agree with WONTFIX. I think part of the issues raised here
could be resolved or at least alleviated by fixing bug 76197, thereby making the
"scroll", "-moz-scrollbars-horizontal", and "-moz-scrollbars-vertical" values of
"overflow" more usable.

Resolving WONTFIX.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → WONTFIX
Hixie, please quell my fear. In marking this bug WONTFIX, you are assuming that
bug 76197 *will* be fixed and that fix will *by default* reserve the vertical
scrollbar space with a disabled scrollbar? (... and possibly allow the web
author to relinquish that space with css.)

If not, then I fear that this bug will become a favourite knit-pick for web
authors since moz's behaviour will be so different from that of past and present
browsers.  I agree wholeheartedly with wjbell’s comment 48.
Yes I think Bug 76197 is indeed more basic than this one. I would prefer that
that bug be fixed instead.
By saying WONTFIX I am saying that for short pages there should be no scrollbar
and no gap for a scrollbar. I do, however, believe CSS should have a way of
letting authors control this.
Ian,

That statement is good for single pages, but for multi-page web /sites/
it overlooks two facts:

1) Good websites have a template where all pages are made to look the
   same except for the content.
2) Most sites have a combination of long and short pages in them.

Yes, single standalone pages look better without a scrollbar - I do agree
with you wholeheartedly here - but if a short page is part of a set of
pages with both long and short pages, then it breaks the template.

What we want is consistency within a site - all pages from the same site
that are based on the same template viewed from the same browser on the
same computer should have the same width when rendered.
...which is why sites should be able to control this, like I said.
Should that be a separate bug, then? (Give authors the ability to reserve
vertical scrollbar space) Or should this bug handle it?

Or should it be the other way around? (Moz reserves the space but authors have
the ability to display:none that space)

I prefer the second. Short standalone pages are rare, and it's easier to remove
a scrollbar that is there than add a scrollbar that isn't there. I suggest

  -moz-scrollbar {display: none;}

to make the scrollbar disappear.
No longer blocks: 48634
This bug is very similar to bug 48634 (probably a dup).
*** Bug 156177 has been marked as a duplicate of this bug. ***
Please see my duplicate bug 156177 for another example of why Mozilla's current
behavior looks crappy.
Whiteboard: WONTFIX?
-moz-scrollbars-vertical does not help in my case. When it is applied, the page
is only as tall as the smallest nested <DIV> with a scrollbar on the side. This
makes the content only 200px tall on my test case with a long scrollbar.

This is just silly. When did the scrollbar become part of the Web page, and it
it indeed is part of the Web page, why can't the author control it properly?
C'mon guys.  Please don't make my centered content jump around.
Undoing damage to summary, and reopening. Since my last comment, I have noticed
a number of reasons why this bug should be fixed. In order of importance:

(1) The lack of a vertical scrollbar causes centered/righted elements to jump
    around once the page gets longer/shorter than a screenful. No, paint
    suppression does not solve this; if it did, I would consider that a bug, as
    I shouldn't have to wait ages for a page to get longer than a screenful
    before I get to see any content. And paint suppression can't do anything if
    the layout is shared across multiple pages. Nor would `reserving space' for
    the scrollbar solve the problem adequately, since it would make the layout
    look lopsided for short pages.

(2) The omnipresence of the vertical scrollbar would prevent the scrollbuttons
    in the horizontal scrollbar (where present) from jumping around once the
    page gets longer/shorter than a screenful.

(3) It's breaking the interface guidelines on *every* platform for which I know
    of the existence of both a Mozilla implementation and interface guidelines
    for scrollbars. Windows
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/ch07d.asp>:
    `The common practice is to display scroll bars if the view requires
    scrolling under any circumstances. If the window becomes inactive or is
    resized so that its contents do not require scrolling, you should continue
    to display the scroll bars.' Mac OS 8/9
<http://developer.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-121.html#HEADING121-4>:
    `If the document is no larger than the window, the scroll bars are inactive.
    This means that the rectangles are outlined, but there is no gray area, no
    scroll box, and the arrows are hollow (their outlines appear).' And Mac OS X
<http://developer.apple.com/techpubs/macosx/Essentials/AquaHIGuidelines/AHIGWindows/Scrolling_Windows.html>:
    `If the entire contents of a document is visible in a window, the scroll
    bars do not contain scrollers.' (The interface guidelines for GNOME and KDE
    do not appear to mention scrollbars.)

(4) If the Status Bar is turned off, the lack of a vertical scrollbar causes
    part of the page to be hidden behind the window's grow box. (An alternative
    solution to this problem would be to make the Status Bar compulsory, but
    that wouldn't solve any of the other problems.)

(5) It's inconsistent with other programs, such as AppleWorks, iTunes, and (most
    obviously) the Finder, all of which use vertical scrollbars even when the
    full length of the content fits in the window.

*None* of these reasons have anything to do with Web designers, who (for the
purposes of this bug) I don't give a stuff about, and it's rather unfortunate
that the bug report got invaded by them. The bug appears to have been wontfixed
under the assumption that author configurability makes the default user
experience irrelevant, and that assumption is (as usual) incorrect.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Summary: Web pages should have vertical scrollbar space reserved → Web pages should always have vertical scrollbars by default
Not only centered/righted elements, but also left-aligned pages that
use percentage for their width.
But for me the most important reason for this to be fixed is still the
consistency of layout of pages in a web site.

Not because the spec say so (though that is a compelling reason) but
because it is the logical thing to do.

In fact, there is really no compelling reason for Mozilla to behave the
way it currently does.

> (1) The lack of a vertical scrollbar causes centered/righted elements to jump
>     around once the page gets longer/shorter than a screenful.

I have only noticed this on one page, and it is a Mozilla demo. Please provide
the URI for an actual web page showing this behaviour.

Argument 2 is merely an extension of argument 1.


> (3) It's breaking the interface guidelines on *every* platform for which I
>     know of the existence of both a Mozilla implementation and interface
>     guidelines for scrollbars.

There is precedent for this, for example PowerPoint, Windows Explorer. We
shouldn't blindly follow specs even when they are stupid. When specs are stupid
we should either ignore them (if that doesn't hurt interoperability) or get the
specs changed.


>(4)  If the Status Bar is turned off, the lack of a vertical scrollbar causes
>     part of the page to be hidden behind the window's grow box. (An
>     alternative solution to this problem would be to make the Status Bar
>     compulsory, but that wouldn't solve any of the other problems.)

The likelyhood that there is any important content in the bottom left 12x12
pixels is remote. In the remote case of their being anything there to care
about, users can reenable the status bar temporarily. There is precedent for
this (e.g. Windows Explorer).


Argument 5 is merely an extension of argument 3.


> *None* of these reasons have anything to do with Web designers, who (for the
> purposes of this bug) I don't give a stuff about,

Author are important, but not as important as users.

I think this bug should be WONTFIXed because *as a user* I don't like seeing a
big gray bar to the right of my window when there's no reason for it to be
there.

(a) The scrollbar is unsightly when the page doesn't require it.

(b) The scrollbar being present on the window's viewport but not on an
    <iframe>'s, <textarea>'s, <object>'s, or <img>'s viewport is internally
    inconsistent. (This is much worse than being inconsistent with other apps on
    the system.)

(c) Other applications which display content (rather than displaying an editor's
    view of the content) remove scrollbars when they are not necessary, so that
    the user is not distracted by pointless UI.

(d) It makes no sense to have this behaviour for vertical scrollbars and not
    horizontal scrollbars (and in fact this would be inconsistent with the UI
    guidelines you quoted), and having disabled horizontal scrollbars is even
    worse. (This point of view is even shared by WinIE, which disabled vertical
    scrollbars but _hides_ horizontal ones.)

(e) Pages which are special cases and will be frequently increasing
    and decreasing their content (such as the demo I mentioned at the top
    of this comment) should, IMHO, specify the viewport's scrollbar
    settings themselves, and so should not be considered for this bug.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
QA Contact: petersen → ian
Resolution: --- → WONTFIX
Keywords: perf
>> (1) The lack of a vertical scrollbar causes centered/righted elements to jump
>>     around once the page gets longer/shorter than a screenful.
> I have only noticed this on one page, and it is a Mozilla demo. Please provide
> the URI for an actual web page showing this behaviour.

Ian, see:
http://nchcap.unc.edu/
(click between "home" and any of the other links--the page appears to jump left
when the scrollbar is added)


>> *None* of these reasons have anything to do with Web designers, who (for the
>> purposes of this bug) I don't give a stuff about,
> Author are important, but not as important as users.

With an article like this on the front of news.com, I'd hope you'd both think
authors /and/ users are *tremendously* important: "Sites bow to Microsoft's
browser king" http://news.com.com/2100-1023-941926.html?tag=fd_lede


I vote first for a permanent vertical scrollbar that is dimmed when not in use.
Not an elegant solution, but a solution that does not create any site-continuity
problems ("unsightly" as it is).

I then hope that we could put our heads together and come up with a more
creative solution to prevent a site like http://nchcap.unc.edu from becoming
annoying to navigate.
Ran into this "bug" this week actually when we have a navigation that expands 
using the css display. The navigation is on the right side of the page and it 
look *really* bad when suddenly the whole page "jumps" because suddenly the 
scrollbar appears. 

The site mentioned in comment 84 reloads its content, but still visible. In our 
solution it looks simply bad because of this. :-(

my 2 cents...
A scrollbar is part of the interface just as a back or forward button might be.
Having elements of the interface appear and disappear depending on whether they
are needed is silly in any other context. Why not have the back and forward
buttons in Mozilla disappear when there are no pages in the history? Why not
have the stop button appear only when a page is loading, and then disappear when
it is done? Why not? Because it would look stupid to have the toolbar icons
bouncing around as you browsed, having buttons appear and disappear.

This is all facetious of course, but to illustrate a point. No one would think
of designing an application with magically disappearing interface elements
except when it comes to scrollbars for some reason. Now why is it that an
exception is being made for scrollbars? 
I agree with Hixie.  Btw, if you turn off the status bar in Windows Explorer or
Notepad (WinXP), the resize grippy is hidden unless both scrollbars are visible.
> http://nchcap.unc.edu/
> (click between "home" and any of the other links--the page appears to jump left
> when the scrollbar is added)

Oh come off it. Like users are going to notice that. The home page looks better
when it has no scroll bars, anyway. Big deal.
Totally disagree, it is very visible. And as I mentioned, if  you have a menu 
to the right that expands using the css property display, its not only visible 
but very annoying. 
Our company is developing a site now where this occur and it does not look 
good. Will try to make a testcase a soon as I have some extra time to show this.
I agree with comment #86 made by Jerry Baker. The value of his statement is an
order of magnitude higher than many others such as misguided by the minute gain
of screen real estate achieved by automatic scrollbar bouncing. These gains are
interesting but have little practical value if they cannot be controlled.

Please imagine the following simple scenario:

A dynamically updatable page is first loaded with minimal content not long
enough  to require scrollbars.

The user presses a button on this page to update it (via a http connection to
the server).

The page updates itself with extended content, the button moves away from
underneath the user's mouse cursor and all other thext jumps around plus of
course suddenly the scrollbars appear.

What a joke, isn't it? Ha, Ha, Ha!

I am coming from the direction where the web authors definitely lose control
over the screen geometry. But the way I think wrt this issue is very similar to
Jerry's. What counts is what can be done for the end user and the fact is that
the user does not notice unused reserved space in comparison with the highly
irritating effect of uncontrollable dynamically misaligned content.

I agree with comments made elsewhere that users should not carry the burden but
rather web developers even if it means a lot of work.

But if it is IMPOSSIBLE for a web developer to achieve a simple goal such as
accuracy in content alignment then the web browser has missed its goal by miles.

However whether I aggree or not that doesn't matter in the scale of things in
the real world.

By that I mean that Mozilla 1 / Netscape 6/7 have currently close to 0% market
share. So the question is whether users will tolerate glitches such as this. I
think they won't. Mozilla is much easier to wipe from the computer than to
install it.

In other words every good engineer or mechanic who wants to release a good
service or product has to do at least one thing before getting in contact with a
highly valued customer audience: He has to get the dirty grease out from
underneath his fingernails and adapt to the audience not vice versa. And he
shouldn't talk techo gibberish and how the customers should behave.

I have just opened http://www.sapient.com/

as suggested by Comment #53 From Justin Watt.

Very smart, superior design. The user interface elements (vertical tabs,
vertical scrollbar) are close together for most convenient navigation (sorry,
left-handers). If Mozilla breaks this design then that's too bad for Mozilla not
for that site.
I don't know what went wrong with most other sites that force silly mouse
acrobatics between the left menu bar and the right scrollbar. The fact is that
vertical scrollbars are always right and not left.

Simply silly, isn't it? Good for a laugh anyway.


Ian: Re comment 88, of course users will notice it. How do you think it got
reported, and then all these people got here in this bug?
Look, I don't mind using some method to workaround this so long as Mozilla has
something that is non-proprietary to control it. In an ideal world there would
be a way for page authors to turn on, or off, permanent scrollbars (disabled
when unneeded ala IE Win), and a way for users to override this behavior if they
so choose. I would say that the default should be to behave like every other
browser on the planet (at least on the Windows platform).
>I would say that the default should be to behave like every other
>browser on the planet (at least on the Windows platform).

Okay, I would say that the default should be to behave like every other browser
and other application on the planet (at least on the Macintosh platform).  Now what?

Of course, there is the "fix" mentioned in comment 43, but I suspect it isn't
enough for the purposes of those who want the scrollbar space to stay reserved
in all cases.

Different behaviors on different platforms just like we do for various other UI
conventions. My understanding is that IE and NN4 behaved the same way on Mac as
well though.
Re: a potential fix in comment 44: -moz-scrollbars-vertical doesn't work
properly right now. See my comment about this in bug 76197
FWIW, I feel strongly that the scrollbar, whether visible or not, is a control.
 It is not part of the content, but part of the application, and something that
designers and viewers should be able to mostly ignore.

Adding *features* to allow either to tweak scrollbar preferences would be cool,
but  does not solve the initial problem as posted, nor does it operate on the
principle of least surprise.

Having to add CSS to accommodate specific browsers or browser versions for basic
behaviour like this is precisely what we need to be getting away from.  Being
able to define cool CSS classes to tweak scrollbar beahviour should be optional,
not required.
Look, this is aweful for both the developer and the end user.  Most users 
expect the document's width to remain constant until the window is resized.  
Many developers use centered or right-aligned navigational items across 
multiple pages, and expect them to always fall on the same location.

There is no reason for Mozilla to change the width of the canvas.  It confuses 
and frustrates everybody, except for those who complain that short documents 
look more pleasing without a disabled scroll bar.  I can't comprehend how they 
have won this "feature" at the expense of the rest of us.  This bug is the 
largest of three reasons I cannot recommend Mozilla to coworkers, because our 
web administration pages have small right-aligned navigation buttons that 
should not shift position between pages (but do, often lining the cursor up 
with an unintended button instead).
Comment #97 finally raises a few questions:

1) Why are we as the majority of contributors (= voters who wish to have this
bug fixed) behaving like losers ?

2) Why do we (who have analytical skills and not just opinion) continue to waste
our time with emotional discussions while the overwhelming array of facts
clearly demands that this gets fixed?

3) Why is it only up to the original reporter's opinion whether this gets fixed
or not?
Note that the people who would be annoyed if the behavior were what you want
aren't angry about it and aren't adding tons of comments to the bug.  If we
switch the behavior, we'll annoy a different set of people, who could again
produce the majority of comments on a bug.
Ya. I can hear it now. "The Windows UI specs and the Apple UI specs say
scrollbars should be permanent, now they are in Mozilla. What kind of crap is
this? When did Mozilla decide to start honoring platform 'correctness'?"
dbaron,

Theoretically your statement is correct and I agree but it does not help us much
here I guess, i.e. we need something more powerful that adds weight or value in
an analytical context. I am sure you can come up with something.

I would like to see an analysis where the following 2 values are rated and a
decision is made based on the outcome of this process:

1) Benefit of having a few more pixels of screen real estate in a very small
minority of non-scrolling pages where this could easily be achieved by other
means even with the Netscape 4 legacy browser.

2) Disadvantage of virtually disconnecting the internet user from their visual
interface in a variety of cases, some of them documented in this bug, some of
them in other related bugs. No successful workaround for this defect has yet
been suggested here.
Jerry Baker,

"What kind of crap is this?"

Very interesting highly factual, analytical and qualified comment.

What are you actually saying?

Why are these UI standards crap. I would not want to follow standards blindly,
but first one has to be able to ask questions e.g. what is particularily wrong
with them and why one should ignore them i.e. alienating users who rely on their
values.


I was making the point that sometimes people are a little overzealous in their
pursuit of what they think is cool. They are willing to throw aside the user
interface guidelines for the two most successful GUI's in existence because they
don't like them. Who decides? I don't like some of the W3C specs, so why don't
we ignore those ones too (for a good one look at the big oops with image
alignment in the current box model). For some reason Mozilla has chosen to stick
with the W3C almost to the letter, and without question. When it comes to the
platforms that Mozilla operates on, it's an uphill battle to get Mozilla to
behave the way applications are supposed to behave. I don't know why there is
this need to follow standards for the Web, but to blatantly and flagrantly
ignore standards for the various operating systems that Mozilla is distributed for.
Keywords: 4xp
I notice that you have all been quite carefully ignoring the specifics of my
points in comment 83:

| (a) The scrollbar is unsightly when the page doesn't require it.

I find the disabled scrollbar in IE to be _really_ ugly. It detracts from the
symmetry of many short pages. If authors want them enabled, I think they should
have the choice, through an @rule or pseudo-element or something. (Or simply by
placing invisble boxes everywhere they expect their page to grow to, so that the
content never grows beyond what it started as -- this means that on large
screens such as mine, those cases where the scrollbar isn't needed even when the
dynamic animation is used won't needa a scrollbar at all.)


| (b) The scrollbar being present on the window's viewport but not on an
|    <iframe>'s, <textarea>'s, <object>'s, or <img>'s viewport is internally
|    inconsistent. (This is much worse than being inconsistent with other apps 
|    on the system.)

This is a good reason to ignore the platform user interface guidelines.


| (c) Other applications which display content (rather than displaying an 
|     editor's view of the content) remove scrollbars when they are not 
|     necessary, so that the user is not distracted by pointless UI.

e.g. Powerpoint. This is evidence that even the people who wrote the guidelines
are not always following them blindly.


| (d) It makes no sense to have this behaviour for vertical scrollbars and not
|     horizontal scrollbars (and in fact this would be inconsistent with the UI
|     guidelines you quoted), and having disabled horizontal scrollbars is even
|     worse. (This point of view is even shared by WinIE, which disabled 
|     vertical scrollbars but _hides_ horizontal ones.)

Everyone has been carefully ignoring horizontal scrollbars. Why are they
different? In a world of multi-directional text, why shouldn't we, by the
argument given by people in this bug, have both scrollbars? That's what the
guidelines are asking for. My answer: because it's really ugly. See (1).


| (e) Pages which are special cases and will be frequently increasing
|     and decreasing their content (such as the demo I mentioned at the top
|     of this comment) should, IMHO, specify the viewport's scrollbar
|     settings themselves, and so should not be considered for this bug.

I fully agree that there are some cases where authors need scrollbars when we're
not showing them. Those are not common cases, but we should be taking care of
them by providing ways for authors to control the scrollbars.
(a) So when are the criteria for whether to adopt a platform standard the
ugliness of the standard as it appears to Ian?

(b) But, I would argue, less so than flaunting custom when there is no standard
requiring you to do so. People already expect browsers to behave this way.
Changing it for no other reason than aesthetics is irresponsible I think.

(c) Does Power Point shift centered or right aligned content over when it does
this? IIRC Power Point is to develop presentations of slides in series. This is
very much akin to the type of Web pages that are being disturbed by this bug. If
PowerPoint made the position of right-aligned and centered text or objects
dependent on the vertical heigth of page I would be very surprised.

(d) Because it is of no consequence to page design whether horizontal scrollbars
pop up or not. The only way it would be possible for this to be on the same
level in the "annoying" factor, would be if it were possible that a horizontal
scroolbar would shift content up on the page. AFAIK horizontal scrollbars just
appear over content so they don't affect their position on the page, so no one
cares.
aha@pinknet.cz: this is not 4xp. Navigator 4.x reserves the vertical scrollbar
space but it doesn't show it when it isn't needed. Until summary is changed to
"Web pages should always have vertical scrollbars by default or reserve their
space", I 'm removing the misleading keyword.
Keywords: 4xp
Um. The whole point of this bug being filed originally was to have a static view
port the way NN4 did and IE does. IE chooses to display the disabled scrollbar
and NN4 does not. The effect is still identical.
I just checked and both NN4.x/Mac and IE5/Mac have dynamic viewports-- the
vertical scrollbar appears and disappears based on the length of the page
content-- so I think removal of the 4xp keword was justified.

If you're going to continue ignoring non-Windows platforms in this discussion,
and keep on spamming a closed bug, could you please at least switch the
Platform/OS to whatever version of Windows you're using?  That way those of us
on non-Windows platforms can feel a touch more secure that, in the apparently
unlikely event that this report gets reopened and actually worked on, we won't
be annoyed by having Gecko break user expectations set by all the other browsers
running on our platform(s).  Thanks!

Fair enough. Platform changed. Compat keyword added.

BTW - how do you specify the entire Windows platform?
Keywords: compat
OS: All → Windows XP
emeyer: But does NN4 reserve the space for the scroll bar. Just make a page with
a white background, then a 100% width table with a black background. The Windows
NN4 will show no scroll bar, but the right-hand 20 - 25px will be white because
the 100% table won't go there.
your usage doesn't match the keyword's. i think we're using
p-<sillyapp><sillyplatform> in the status whiteboard for parity markings.

to mark a bug as for all windows, mark it for the oldest windows to which it
applies (w95 usually).  however this bug either will be fixed for all platforms
or will not be fixed for any platforms, so it should not be marked as specific
to one platform/os .
Keywords: compat
OS: Windows XP → All
Why would we want to lock Mozilla into one UI paradign for all platforms? Is
there some overriding need in this case? I have to admit it seems like an
underhanded way of accomplishing the goal of not doing this for no other reason
than because a few have an opinion against doing it, but I may be mistaken.
Let me make a final statement for the record on this bug because it has become
obvious that people are way too emotional about something that is really dumb to
be emotional about, and so Mozilla won't change. This will sit here to be read
by future people who get annoyed by the bug.

There have been precious few arguments in support of Mozilla's current behavior
except for plain personal opinion ("I like it" and "I don't like IE's permanent
scrollbars"). Several rational arguments for Mozilla's current behavior have
been made:

1) That there is precedence for this in other Windows applications such as Power
Point and Windows Explorer.

  The problem with those precedents is that neither of those applications shift
  the content in the window to accomodate the scrollbars. Instead, the scrollbars 
  overlay the content, and if this makes some content fall behind them then a
  horizontal scrollbar is added. Positioning is preserved, unlike Mozilla.

2) It makes no sense to have this behaviour for vertical scrollbars and not
horizontal scrollbars.

  This isn't true. Vertical scrollbars displace content, horizontal scrollbars
  overlay content. That makes all the difference in the world.

3) It would be internally inconsistent to have the main browsr window with
permanent scrollbars, but have iframes, images, textareas, etc. not have
permanent scrollbars. This constitutes sufficient ground for ignoring the
Windows GUI and Mac GUI specifications.

  This is the criteria? Says who? Where was that decided, and where are the
  discussions/minutes published for public review?

  Secondly, what makes it internally inconsistent? Just because Mozilla is a
  monolithic collection of iframes, textareas, etc. does not mean that it should
  behave that way. As far as the user is concerned it is a program like any other 
  and it should act like one. A browser's canvas != iframe as far as the user
  is concerned.

4) Netscape 4.* didn't behave this way.

  Bzzzt! Netscape 4 behaves this exact way. It reserves the space for vertical
  scrollbars at all times.

These are the only arguments brought in favor of Mozilla's behavior that do not
involve subjective feeling and irrational opinions.

Now, let's look at the arguments for permanent scrollbars.

1) The platform specifications for Windows and Macintosh specify that they should 
   be there.

2) (a) The history of Netscape's behavior is to reserve the space for scrollbars
   (even when it didn't always display them), and as such there is no reason
   to break old behavior unless there is some compelling need (like standards
   compliance).

   (b) Internet Explorer on Windows behaves this way. Since about 90% of the
   world is using this browser to view the Web, again, why would we want to go
   and change the behavior that 90% of people are used to with no compelling
   reason?

3) Mozilla's current behavior makes consistent positioning of relatively sized
   right-aligned, and/or relatively positioned page content impossible. Meaning
   that it is impossible to maintain a consistent position of elements throughout
   a site even when the user does nothing more than browse from page to page
   (i.e., they never explicitly instruct their application to change the size of
   anything).

4) It is bizarre behavior for UI elements to pop-up over non-editable 
   content and change the presentation of that content without explicit user  
   instruction to do so (at least on Windows). Since some want to keep this bug
   platform universal, let's at least focus on the platform that Mozilla users
   are using it on the most then.

Pro-change has platform guidelines from their respective manufacturer's, that 90%
of the persons on the Web today are using a browser that behaves the way we are
asking Mozilla to behave, that Mozilla users are likely to be former Netscape
users and Netscape 4.* behaves in similar fashion, that Mozilla's current
behavior forces anyone who wants to avoid this behavior (without hacks) to use
fixed positioning and left-aligned pages, all going for it.

The against change camp has that they think it would look dumb.
> 1) That there is precedence for this in other Windows applications such as
>    Power Point and Windows Explorer.
>
> The problem with those precedents is that neither of those applications shift
> the content in the window to accomodate the scrollbars.

Open "My Computer". Make the window short and shorter. Examine the pane to the
left as the scrollbar appears and disappears.


> 2) It makes no sense to have this behaviour for vertical scrollbars and not
>    horizontal scrollbars.
> 
> This isn't true. Vertical scrollbars displace content, horizontal scrollbars
> overlay content. That makes all the difference in the world.

Horizontal scrollbars will quite happily displace content if the writing
direction is top-to-bottom instead of right-to-left.


> 3) It would be internally inconsistent to have the main browsr window with
>    permanent scrollbars, but have iframes, images, textareas, etc. not have
>    permanent scrollbars. This constitutes sufficient ground for ignoring the
>    Windows GUI and Mac GUI specifications.
> This is the criteria? Says who?

Me. Who says the criteria is blindly following UI Guidlines?


> Where was that decided, and where are the discussions/minutes published for
> public review?

Since when do my opinions need discussions and minutes?


> Secondly, what makes it internally inconsistent?

A document in an <iframe> is going to bounce around just as much as a document
in the browser.


Now, let's look at the arguments for permanent scrollbars:

> 1) The platform specifications for Windows and Macintosh specify that they
>    should be there.

See arguments 1 and 3 above.


> 2) (a) The history of Netscape's behavior is to reserve the space for
>        scrollbars

The behaviour of other browsers is irrelevant, especially obsolete browsers.

MacIE does the same as Mozilla, I am told.


>    (b) Internet Explorer on Windows behaves this way.

IE does many stupid things.


> 3) Mozilla's current behavior makes consistent positioning of relatively sized
>    right-aligned, and/or relatively positioned page content impossible.

No it doesn't. That's nonsense. I've given several options already in this bug
(e.g. making your template trigger scrollbars if required by making an element
cover the area that dynamic content would enter), and have also said that I
believe we should make this author-controlled for authors who really care.

And secondly, I have yet to see a user who cares. This is an author concern, not
a user concern, and users are the people I am most concerned about.


> 4) It is bizarre behavior for UI elements to pop-up over non-editable 
>    content and change the presentation of that content without explicit user
>    instruction to do so (at least on Windows). Since some want to keep this
>    bug platform universal, let's at least focus on the platform that Mozilla
>    users are using it on the most then.

That's the same argument as 3.

These are the only arguments brought against Mozilla's behavior that do not
involve subjective feeling and irrational opinions.


Despite your attempts at making the statement appear minor, a huge reason for
not enabling vertical scrollbars all the time (or leaving room for them) is that
doing so really ruins the look of many pages. Look at pages like:

   http://www.hixie.ch/tests/adhoc/css/background/01.html

...in Opera, a browser which leaves room: it looks unbalanced. Look at it in
IE's full screen mode, a browser which shows a scrollbar (if you can get past
the fact that it doesn't render the page correctly in the first place): it has a
huge unsightly scrollbar down the right hand side of the screen.


Pro-status-quo has aesthetics, precedents on all three platforms, that 100% of
the persons using Mozilla are using a browser that behaves as the status quo,
that Mozilla users are likely to be already Mozilla users, and that authors who
really want their page to have scroll bars have multiple ways of getting them
going for it.

The against status-quo camp has that they think it sometimes shifts text a bit.
Blocks: 158464
Re: comment #c114

>And secondly, I have yet to see a user who cares. This is an author concern, not
>a user concern, and users are the people I am most concerned about.
I'm a user, I care. Sorry Ian. I'll spam my comments from a related bug that
died a silent death:

[ . . . ] I find it very annoying that the scrollbar isn't always there when
browsing regular pages - for consistency's sake.

For example, I'm browsing through pages that have the same layout, and I place
my cursor over the "next" link so all I have to do is click the mouse. 

+------------------------------+
| Webpage - Mozilla            |
+------------------------------+
|                              |
|  [ previous | home | next ]  |
|                              |
|                              |
| lorem ipsum dolor sit amet,  |
| consetetur sadipscing elitr, |
| sed diam nonumy eirmod tempor|
| invidunt ut labore et dolore |
|                              |
+------------------------------+

This works fine as long as the subsequent pages either all show a scrollbar or
do not. As soon as one page needs one when the previous didn't (or vice versa),
the area available for content shrinks a little, and all content shifts right.
(or left, in the other case). 

+------------------------------+
| Webpage - Mozilla            |
+-----------------------------++
|                             ||
| [ previous | home | next ]  ||
|                             ||
|                             ||
| At vero eos et accusam et   ||
| justo duo dolores et ea bla ||
| rebum. Stet clita kasd gub  ||
| ergren, no sea takimata san ||
| lorem ipsum dolor sit amet, ||
+-----------------------------++

Often I find having to move my mouse again, eliminating the fast browsing. I did
a search on "scrollbar" to make sure I wasn't duping - please forgive me if this
load of anal retentiveness has already been posted by someone else.


>Despite your attempts at making the statement appear minor, a huge reason for
>not enabling vertical scrollbars all the time (or leaving room for them) is that
>doing so really ruins the look of many pages. Look at pages like: [ . . . ]
As a reply, I'll quote you again:
>This is an author concern, not a user concern, and users are the people I am 
>most concerned about.
Isn't your argument mostly an author concern?

>[ . . . ] Look at it in IE's full screen mode, a browser which shows a scrollbar
>(if you can get past the fact that it doesn't render the page correctly in the 
>first place): it has a huge unsightly scrollbar down the right hand side of the 
>screen.

>The against status-quo camp has that they think it sometimes shifts text a bit.
As above. It's not just that we only "think" it shifts, it *really* does. I swear!
> Isn't your argument mostly an author concern?

Yes, since I was arguing against authors.


The "next" thing is an issue, but that's what the link toolbar is supposed to
fix. In practice, I see "next" links moving for many reasons other than the
scrollbar, so I am nor in the least bit convinced that this would help much.
Attached file HTML Testcase — 
We ran into this when developing a site not yet released. This testcase
illustrates the issue. Press the button to expand the submenues. When the table
expands the scrollbars will appear. 

Toggling the submenu on and off will make the whole layout to jump.
_If_ the user opens all four menus, _and_ the page isn't taller than the content
area, then, when opening the fourth menu, the page jumps. But then by that time
the content is overflowing anyway, so the effect is lost. At least until you
open the fourth item you don't have an ugly gray bar next to the menus.
Target Milestone: Future → M1
(Removing milestone which i accidentally set to M1. Thanks for the heads-up John.)
Target Milestone: M1 → ---
*** Bug 170971 has been marked as a duplicate of this bug. ***
I must really wonder how so many people making webpages could find it beeing a
problem that Mozilla doesn't provide a scrollbar when it's not needed?
Don't any of you know even some basic CSS?

If you want a scrollbar in Moz, just add eg this to your page
<div style="position:absolute; top:0; height:100%; padding:0 0 1px">&nbsp;</div>

Guaranteed to give a scrollbar at all times, and that also happens to be 100%
valid HTML/CSS (in short there is no need for even a special hack/ Invalid CSS
to do it).

Moz current implementation is the only 1 that give the webauthor the option to
decide if he wants a scrollbar or not using NOTHING but VALID HTML & CSS.

And an advice for next time, before wasting months on arguing about a nonissue,
try to spend jsut 5 minutes to figure out that simple workaround that is already
there...
Stefan,
before people even contemplated about raising this issue in Mozilla their brains
would have spent a few milliseconds only to reject the workaround you are
suggesting. The very point of this bug is that there has to be predictability in
dimensions without having to force a visible scrollbar with fake content
exceeding available screen space as you are suggesting.
> there has to be predictability in dimensions without having to force a visible
scrollbar with fake content

Yes please, why don't we ignore all of the W3C specs and start adding huge heaps
of proprietary code to mozilla.
I'm sure that is the best solution... NOT

And regarding it beeing fake content... it's examplecode...
Replace that &nbsp; with eg <img src="sitelogo.png" ...> and suddenly it's not
fake content any more but a tag to add your site logo to the page + CSS to
create a scrollbar. You just have to think outside the box.

The point here is, whith the current implementation it's a piece of cake to get
your desired look as a webdeveloper with VALID CSS + HTML.
Your suggestion however forces the use of proprietary/invalid CSS.

I'm sure it's pretty obvious which is the better solution.
*** Bug 155092 has been marked as a duplicate of this bug. ***
*** Bug 186381 has been marked as a duplicate of this bug. ***
*** Bug 187553 has been marked as a duplicate of this bug. ***
*** Bug 204649 has been marked as a duplicate of this bug. ***
*** Bug 209480 has been marked as a duplicate of this bug. ***
Internet Explorer 6 has persistant vertical scrollbars.

Stefan: Can you please point to where in the CSS specs it says that a persistant
scrollbar like IE 6 has is invalid? The XUL frame of the HTML document is the
viewport and defines the initial containing block. It says
(http://www.w3.org/TR/REC-CSS2/visuren.html#viewport):

"When the viewport is smaller than the document's initial containing block, the
user agent should offer a scrolling mechanism"

Then look at:
http://www.w3.org/TR/REC-CSS2/visufx.html#overflow

If you look at the intent of this, by reading the section labelled scroll:

"This value indicates that the content is clipped and that if the user agent
uses scrolling mechanism that is visible on the screen (such as a scroll bar or
a panner), that mechanism should be displayed for a box whether or not any of
its content is clipped. This avoids any problem with scrollbars appearing and
disappearing in a dynamic environment. When this value is specified and the
target medium is 'print' or 'projection', overflowing content should be printed. "


This seems to suggest that you should show a disabled scrollbar in that case. So
where does the specs say that the BODY element can't have "overflow: scroll" by
default?

The way that Mozilla causes the page dimensions to change is unattractive and
unreliable when changing pages.

There is no penalty for having it always present except for about 10 unused
pixels on the screen as opposed to possible unattractive bouncing around of
content on pages based on how tall they are.

Various people mentioned a user can override this for the body element, but that
doesn't help when you are crossing site boundaries with different authors (Such
as Excite -> Google).

If writing direction is top-down as Hixie mentioned, then you replace [vertical]
in this bug with [horizontal]. As for textareas, IE 6 has permanent vertical
scrollbars, and that makes sense, also as you don't need the area of what you
can type in to change at the point you go beyond the bottom. In fact, the
appearance of a vertical scrollbar will in some cases necessitate the appearance
of a horizontal scrollbar that wasn't already there. In fact, you can test this
in Mozilla. Pick a textarea with wrap = off, and then use up all the horizontal
space per line, but not enough to cause a horizontal scrollbar. At the point you
go past the bottom, both scrollbars appear!

This enhancement request has 9 votes and a ton of dupes, and doesn't appear to
go against the specs (or no proof to the contrary has been stated). Therefore, I
feel it should be reopened.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Summary: Web pages should always have vertical scrollbars by default → Web pages should have a persistant scrollbar for all pages
This "bug" is not going to be fixed.  It is a conscious design decision.  The 
people in control have made their position very clear.  Life is short, you need 
to pick your battles wisely, and this is not one that you can win.  So let's 
please leave this bug alone.

If you want a scrollbar on your pages, as I do, there are plenty of solutions.  
Just pretend that there is no way in hell that Mozilla will change, and use a 
workaround.  My personal favorite is the following, which doesn't trigger a one-
pixel scroll in IE:

CSS -
#mozscroll { position: absolute; top: 0px; bottom: -1px; visibility: hidden }

HTML -
<div id="mozscroll">&nbsp;</div>

I am not taking a web author position, but that of a user (even though I'm a 
developer). Its not up to the developers or web author what the user sees, and 
the user cannot force the web author to add CSS to their page. I do not see 
this as a standards breach, and is something that will make Mozilla appear to 
have a cleaner interface for the user.

Mozilla is a community, and a meritocracy, and I am throwing some weight 
behind this feature request so there can really be a validation of whether or 
not it breaks the standards, or is it simply an issue of individual developer 
preference. If its simply a case that developers don't want to do it, then I'm 
sure there are others that would be willing to take it. I would be willing to 
take it, for instance. If its a case of a reason with sound basis in standards 
done for principle, then I will be willing to accept that and will be at least 
satisfied it got the proper consideration. At which point, it would be better 
taken to the newsgroups for further discussion.

My main question is: Does it break standards for the initial containing block 
to have persistant scrollbars (enabled or disabled depending on the length of 
the page)? If so, what portion of the standard does it break (URLs)?
This bug will not be fixed, but we will be introducing ways of letting Web page
authors (and users, through user stylesheets) control this, so settle down
people, your needs will be addressed!

WONTFIX.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 21 years ago
Resolution: --- → WONTFIX
-> Verified

Ok, cool. The user stylesheets would handle the user side of wanting this
feature. I do hope it in the user stylesheet by default, though, and W3C decides
that's the default behavior. It just seems like a cleaner interface with the
scrollbar always there. :-)
Status: RESOLVED → VERIFIED
IMHO, scrollbars should be invisible by default, but web developers should have
a method to force them to show or hide. I.e. something like
body {scrollbar-horizontal: visible; scrollbar-vertical: hidden}

Of course, you can object to it that it doesn't comply with current CSS level 2,
but I think if there's a true need in it, mozilla developers should take an
initiative and suggest W3C to make this extention in CSS 3.

Unfortunately, CSS 3 will not ne done soon, so this extension should be
incarnated before it, BUT in exacly the same way. as it will be in final CSS 3.
> Unfortunately, CSS 3 will not ne done soon, so this extension should be
> incarnated before it, BUT in exacly the same way. as it will be in final CSS 3.

How exactly are we supposed to know what CSS3 will say before CSS3 is released?

Anyway. See comment 132.
It wouldn't matter anyway...no one at Mozilla wants to implement standards that
they have personal issues with anyway: "Mozilla - it's better than standards
compliant, only *cool* standards compliant!"
What I see in this bug is mozilla people rejecting this bug without any real
reasons.  I see a lot of compelling reasons by a lot of people why this bug
/should/ be fixed, but it's marked as WONTFIX.  It's too bad and funny at the
same time.. mozilla's suppose to be following standards yet it's breaking simple
web page layout all over the place.
i'm a firebird newb, so when i first encountered this issue, i thought it was my
own sites causing it, and looked for hours on what might be the problem. 

asked on firebird forums and was told it was intended to be this way in the
browser itself. i don't get the logic behind this, as some describe in the
comments, for sites where some pages are long and some are short, the entire
page shifts around, back and forth, it's extremely displeasing to the eye and
comes across as a bad bug. 

as silly as it may sound, i don't think i would want to endure having to see the
page bounce back and forth by 20+ pixels all the time, might just be easier to
switch browsers again. dissapointed if there will be no resolution of this.
Hixie mentioned in comment 132 that CSS3 will give authors a way to control this
(and I hope that the scrollbars being always visible is the default on graphical
user agents :-) )
Non-persistant scrollbars in forms also means that forms' wrapping changes when
you go beyond the bottom of the form.

If you look at word processors, they have persistant scrollbars. I believe that
the CSS option should be to turn off persistant scrollbars instead of on.
Persistant bars seems to be the most desirable behavior.
*** Bug 225608 has been marked as a duplicate of this bug. ***
*** Bug 226446 has been marked as a duplicate of this bug. ***
*** Bug 237257 has been marked as a duplicate of this bug. ***
*** Bug 238172 has been marked as a duplicate of this bug. ***
*** Bug 245662 has been marked as a duplicate of this bug. ***
To comment 83: Others have supplied with samples. Here you have another set:

http://www.sonnd.com/mozilla/persistent_scrollbar.html

And real life:

http://www.informationmechanics.com/ In this site we had to extent the length of
every page to make sure Mozilla wouldn't ruin the design.

To comment 88: "Oh come off it. Like users are going to notice that. The home
page looks better when it has no scroll bars, anyway. Big deal."

I do, often enough. And have had to fix this for sites we have don't. Fix it for
Mozilla, that is. IE and now Safari, don't have that problem. David Hyatt
implemented this for Safari 1.2

To comment 99: "Note that the people who would be annoyed if the behavior were
what you want aren't angry about it and aren't adding tons of commentsto the bug."
That majority would still be a minority among users. They would have to be
mainly users of Mozilla with no regard for the majority of IE users.

To comment 104: "I find the disabled scrollbar in IE to be _really_ ugly."
 A question of taste, with which I do agree. But doing websites for a living I
rather have what IE offers. I can disable it whenever I want by <body
scroll="no">, as long as content doesn't exceed viewport height. An @rule would
be a solution, but given IE5.x, IE6 and Safari's general use, we might as well
do the same and allow site owners to remove it, instead of adding it. This would
 not allow you to avoid seeing that scrollbar in the majority of pages... guess
that's were you see the problem?

 Your mention of Powerpoint can be confronted with the mention of IE and Safari.
Far more relevant if you ask me, since we are talking browsers.

 With horizontal scrollbars you are talking about possibility rather than
probability. Taking possibility as a factor for UI issues makes no sense (it
makes no sense for mostly everything under the sun, with the possible exception
of security issues). The probability of the scrollbar appearing on a random page
must be orders of magnitude smaller than the vertical one, which usually changes
within the pages of the same site.

And to comment 132: "so settle down people, your needs will be addressed!"
What about we fix it and then you open a bug for your needs to be addressed? ;)




Seeing all the crap people buy in stores nowadays, I'm beginning to think people
care more about how things look and cutesy things than a lot of other things,
such as quality and security. Little details like this drive some perfectionist
web users crazy. Not to say that Mozilla should abandon quality, but we should
also think about what the average user looks for, and its not security or
standards' compliance, its cutesy little details that a power user usually
wonders, "Why did they waste their time on that?"
OK. I admit that with the long thread, I scanned through it, but here's a
suggestion: why not have the scrollbar enabled/disabled by a simple checkbox in
the browser options. Personally, I would leave it on for myself and my clients,
but those who live by browser compliance can turn off the checkbox to allow the
bar to have the scrollbar come and go. Now everybody can be happy.
One more tidbit. It's stuff like this that keeps that garbage browser MSIE with
95% market share. Mozilla would get better acceptance by regular users if we
followed MSFT's tactics of embrace and extend. If Mozilla could do EVERYTHING
that MSIE could do (except browser hijackings, pop-ups, and system compromises)
your average user would have no reason to use MSIE. I do 99% of all my browsing
on Mozilla nightly builds but there are a few sites that force me to use MSIE.
Could we have something like -moz-persistant-scrollbar: disabled|enabled?
***** PREAMBLE  
The main problem about this thread is that people who wants permanent scroll  
bar will read my comment and will agree with me, but those who don't want  
permanent scroll bar will not even read my comment because they are fed up to  
see comments about this. It seems that those who makes decisions here are the  
people who don't want permanent scroll bars and they won't hear they users  
anymore on this subject. So I have the feeling that my comment is really  
pointless. I have another feeling than even if we can prove that 90% of the  
users wants permanent scroll bar, anything will be done either. I think that  
the "Open source - Closed mind" behavior should stop and that we should find a  
solution that will please everyone.  
END OF PREAMBLE *****  
  
The scroll bar should be always visible. I have to say that the argument of  
the people who wants scroll bar only visible when page is too long is not a  
good argument at all. The scroll bar is a part of the browser, not the  
website. All the website url's that were posted as example of "why mozilla  
shouldn't display scroll bar" didn't convinced me at all. If the scroll bar is  
always there, the user sees it as part of the program and not the website,  
then the user makes an abstraction of the scroll bar when looking at a  
website. People progressively uses more css than before. And a lot of people  
find it more easier to make fixed width layouts using css than extensible  
layouts, so we have to expect more and more centered fixed width layouts to  
come. And if anything is done, this thread will continue to grow for years. I  
talked to a lot of webdesigner about this thread, all of them does agree that  
the vertical bar should be always visible.  
  
The current behavior of mozilla about the scroll bar is very irritating. You  
should see the number of times I'm irritated when surfing on a centered  
website, with multiple pages that I browse quickly (such as results of a  
search or something) on which there's a "Next" button for the next page. I put  
my mouse over the "Next" button and click on it --> page2  then I click again  
--> page3, ... then I click again quickly but the Xth page is longer than the  
other pages,  so the scroll bar appears and the whole site is moving on the  
side and the mouse is not over the "Next" button anymore.  
This is an example of the practice side, but the problem is also esthetic, the  
problem is far more annoying than the pseudo problem people say that it would  
cause if mozilla would keep the scroll bar on the side.  
  
Anyway, I think the better option would be to keep the scroll bar always  
visible and leave an option for the rare people that prefer to have the scroll  
bar only if the page is long. And I repeat it again : there is more people  
that would prefer the scroll bar to be always visible. And the majority of  
people that don't know anything about this thread are people that would prefer  
the scroll bar to be always visible.  
  
I tried some workarounds that were given in this thread, and I had problems  
with them (I can't remember exactly but I can check again) Anyway, these  
workarounds are not interesting in this context, because most of the websites  
are done by people that even don't check on other browser than IE and most of  
them don't know anything about this thread. The result is that even if the  
workarounds were working good, it would be used only by a small amount of  
people who produces web-sites. The final result is that this will always be an  
argument against mozilla from IE users.  
Those who check their centered website on mozilla will just post a duplicate  
of this bug and will land here in this thread, disapointed to see that nothing  
will be done.  
  
PS: I'm sorry about the "Open source - Closed mind" remark. It is a very bad  
remark and I don't really think this. It was just a trick to force people to  
read this comment until the end ;-) So please forgive me about this and  
forgive me about my bad english.  
  
  
It should be nice if someone wrote an extension (xpi) for this. Although I
wonder what layout incombatibilities it would induce on fixed width pages.
If it creates layout problems in pages, then they haven't tested them in IE.
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. There should be moz-* CSS properties
for this, such as:
-moz-scrollbar. Then you could hack it into your userchrome.css

html {overflow: -moz-scrollbars-vertical} doesn't seem to do what we want. In
fact, it appears broken when I fooled around with it. The scrollbars didn't go
the entire length of the page.

Why don't we add:
scrollbar-y: -moz-always-on | auto | -moz-always-off
scrollbar-x: -moz-always-on | auto | -moz-always-off

It also needs to be greyed out when shown but not used. You'll need to create a
new property, and break up the overflow implementation into x and y, but still
honor the existing overflow property.

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

When this is finished in CSS3, we'd only need to modify the code a bit (add
aliases to the identifiers and to the property) if we already had this hacked in. 

Good luck in implementing to whomever decides to take this on.
Ignore comment 154.  CSS3's proposed overflow-x and overflow-y properties are
sufficient.
David: 
Did you read my comment? If you are planning to rewrite the entire CSS code of
Mozilla, you should say so, otherwise I wouldn't advise people implementing a
patch to ignore the entire comment #154 unless they have memorized the code
locations. Most of it is still relevant regardless of what the spec is, only a
few things need to be changed. overflow-x would still be placed in the
nsStyleStruct interface. Since you seem to suggest that a slight modification
needed in a comment requires ignoring the entire comment, here is a rewrite
mentioning the CSS3 properties that I didn't realize were formalized yet:


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.
"only afew things need to be changed. overflow-x would still be placed in the
nsStyleStruct interface" in the above comment should read:
"only a few things need to be changed. overflow-x and overflow-y would still be
placed in the nsStyleStruct class"

Also, replace "implementations" with "references to mOverflow that can show you
where to put mOverflowX and mOverflowY references".

See also bug 76197 (mentioned earlier but hard to find) - Scrollbars should look
disabled when there's nowhere to scroll.

Should all further discussions about the implementation of this aspect of CSS3
be discussed in bug 76197?
Depends on: 72747
Generally the people explaining how things should be done should be the ones who
know what they're talking about.  Please don't clutter this bug with more than
it needs.  You're explaining how to do the easy part without explaining how to
do the hard part, which really doesn't help very much.
Never mind that this bug is WONTFIX, which means we're not interested in a patch.

(We would be interested in a patch to implement -moz-overflow-{x,y}, but that's
a topic for another bug.)
(In reply to comment #159)
> Never mind that this bug is WONTFIX, which means we're not interested in a patch.

See
http://slashdot.org/articles/04/06/06/136235.shtml?tid=126&tid=154&tid=95#9350109
for people's impressions of that attitude.
Re comment #151. Logic does not apply here ...

What Fabien is describing is very true, and the annoying bit applies to many
humans in general.

There are a lot of people who make decisions too easily because they argue with
a type of logic where they choose to ignore 90% of the facts, maybe because they
think they are more qualified in their field of experience than others.

The fact that "Democracy" or "Open Source" is applied as an additional layer to
this anti-logic only obscures the lack of openness.

On the side of those who wish to maintain the status quo in Mozilla, there is a
disturbing lack of plausible facts in any arguments. In act all facts are
avoided as much as possible. The arguments are highly opinionated and egocentric.

This is about more than scrollbars. This is about how it is possible that the
truth, which is in this case is so easily available, and by the way is clearly
reflected in the number of duplicates and in the number of complaints in this
bug, can be easily defeated by hairsplitting and bureaucracy.

I can clearly see that thowse who downright refuse to accept patches that would
fix this issue do not act in the interest of the majority of users. This has
been stated often enough and with undisputable arguments here.

I have experienced this in Mozilla more than once but there is nobody to talk to
who has both enough influence to change things and at the same time has the
capacity to analyse the problem in its entirety.

In this case, it is extremely obvious because none of the problems that exist
because of this bug have been addressed in a way that is compatible with
existing pages and the industry standard browser, which is - as much as I am
sorry to say that - Microsoft Internet Explorer.

The argument that an equal or higher number of dissatisfied users would exist on
the opposite side if this bug was fixed is extremely weak. I think it must first
be supported by some evidence before it can be taken seriously:
There are other browsers that do have bug recording systems and that emulate
IE's behavior. Where please are the requests for the removal of the persistently
reserved scrollbar space in any of these browsers?
Yep, I agree with the latest comments.  There has been far too many reasons,
examples and people FOR fixing this bug.  There has been a large amount of
support, reasons and people giving detailed reasons why this bug should be
fixed.  The people that think this bug shouldn't be fixed simply haven't given
any solid reasons why it shouldn't.

For this reason I've given up spending my time reporting bugs to mozilla.  I
think some of the moz developers have some really bad attitudes and should be
listening to the people that speak this loudly on bugs.

Maybe it's attitudes like this that made people branch off from the XFree86 project.
Look, I don't care about the core team's personalities or any of the political 
**** that always goes on in a development project.  There is a compelling and 
logical reason why this bug must be fixed and why WONTFIX is not an acceptible 
outcome:

The width of the canvas should not depend on the amount of content to be 
displayed.

It defies all common sense that the canvas width could change depending on how 
much text is in a document.  And it is a serious user-interface issue when 
performing a /vertical/ resize of a window can change the /horizontal/ 
positioning of objects.

IE understands this.  Safari understands this.  Opera understands this.  Even 
NN4 understood this - the canvas width was specifically preserved by a 
background-filled area which took the place of the invisible scroll bar.

It doesn't have to be a scrollbar.  It can be anything that the Moz developers 
want, from a solid black box to a tiled strip of dancing hamsters.  But 
something needs to be there to preserve the width of the canvas.

I pointed this in comment 97, and yet the debate is still in exactly the same 
place today as it was two years ago.  Until this issue is acknowledged as a 
serious problem, the Moz devs have no right to talk about usability or 
interface consistency.
Two reminders:
 * Open-source does not imply democracy.  In fact, democracy as a method of
software development is generally a bad idea.
 * Most of the comments on bugs with lots of advocacy come from people who want
the current behavior to change.
(In reply to comment #164) 
> Two reminders: 
>  * Open-source does not imply democracy.  In fact, democracy as a method of 
> software development is generally a bad idea. 
 
I know exactly what you are talking about. I know that talking for age about a 
dev topic can slow down a project. I know that this thread is the lowest 
priority of the mozilla dev team, but I wish it won't because I believe it is 
not a little bug to store in the whishlist. I know that users won't stop 
complaining about everything and I know that from a developper's view it 
quickly become irritating. 
 
I think I won't post comments anymore about this because I respect your work 
too much and I don't want to become irritating and I don't want to loose your 
time, so the last thing I want you to know is that WE (I think I can speak for 
the majority of people in this thread) are fighters ;-) I'm explaining 
myself : I'm not involved in the mozilla development, but I constantly fight 
trying to convince people to use mozilla instead of IE. I'm using Linux at 
home but everyone at my office uses IE except a few that I already converted. 
My "mozilla-converter" speech is ready at anytime of the day, everytime I have 
the opportunity I use it trying to convince someone to use firefox instead of 
IE in 5 minutes. As most of my colleagues are web developper, I start to show 
them how tabs are usefull, how some XPI such as Web-Designer, LiveHTTPheader, 
EditCSS, are essential tools, I show them how easily they can browse their 
cookies, I explain how IE + Outlook is a open Window(tm) to viruses and 
trojans, and how Firefox + Thunderbird is much safer... in short, I show them 
how mozilla is a THE browser to use. But when they give mozilla a try and they 
see the problem related to this bug, I must admit that I'm out of argument and 
I guess I'm not the only one. 
 
So you can see that even if I'm not involved in mozilla development, at my 
little level, I keep trying to make mozilla more used around me, and I wish 
(as everyone here) that mozilla will get better and better. This is the reason 
why I posted these comments so far, and I hope that this problem will be fixed 
one day, so I will know that the next people I'll switch to mozilla will be 
100% pleased of this excellent browser. 
 
Regards. 
In all fairness, David Baron is qualified to make decisions because he knows a
lot about the standards because he frequents the mailing list discussions...

This IS in the specs, though! This reminds me of the table backgrounds not being
rendered without content in it bug back a couple years ago that wasn't fixed for
a year after someone mentioned that the spec errata told us to fix it. There
were still strong hackers giving arguments against fixing it regardless of it
being in the specs. That, imho, is ALL that matters! Its been fun, but its right
there: http://www.w3.org/TR/2002/WD-css3-ui-20020802/#overflow-x

Any advocacy for or against is moot from this point on, aren't they?

With that being said, David: 
> Open-source does not imply democracy.  In fact, democracy as a method of
software development is generally a bad idea.
> Most of the comments on bugs with lots of advocacy come from people who want
the current behavior to change.

Response:
1. My comment 154 and comment 156 was not advocacy, it was patching details that
might mean diddly squat to strong hackers of Mozilla, but allows people to
decide whether they want to tackle this for their first patch (or second, or
third...). See bug  114760 where I describe what I'm talking about.
2. I sure hope it changes or we won't be supporting CSS3, will we?
3. I agree this attitude is not the way to win users and praise from the web
community. I know where you are coming from on the advocacy thing, but a "Take
this to the forums" would at least allow people to disucss it and get their
voices heard by project members.

What you said ignores the fact that overflow-x and overflow-y are already in the
recommendations. You already said it was. Can they not be adopted prior to
adopting other aspects of CSS3? Is overflow{x,y} going to change significantly
within the CSS3 recommendation? I highly doubt it. We can implement
-moz-overflow{x,y} and later alias it to overflow-{x,y}. If I remember
correctly, our CSS2 adoption, it was piecemeal. And if there is no bug for the
-moz-overflow{x,y} to officially discuss IMPLEMETATION details, why not? This
issue CAN'T be WONTFIX any more in the general snese because overflow{x,y} IS in
the standard, isn't it? Either this bug most be reopened, or it must be handled
in a separate bug. Take your pick, will it be this bug, bug 76197, or a new bug?

As for the information I gave... It WOULD be useful to someone writing their
first patch (or second, or third...).

What I submitted on this bug would not be easy for a 3rd party developer to
figure out in a short amount of time after they build Mozilla the first time.
Perhaps this isn't the kind of thing someone with no experience on the Mozilla
project should be tackling as their first bugfix, but who are we to say? True, I
found that stuff in like 10 minutes, but it could take other people days to
figure out. We could use a patch for the -moz-overflow{x,y} and why should we
limit the source of that patch to people who have been on the project for 3 years?

Module owners and patch writers who are not planning to fix a bug right away
SHOULD take the 10 minutes required to give a quick summary of how to fix bugs
so that 3rd party people can decide whether they have the time to fix a bug --
and this is the biggest thing. Sure, many developers have the skills, but don't
have the experience in the Mozilla project and a simple discussion of what's
needed in each important bug can give them an idea of whether they should tackle
it or not.

So do we wait 5 years for this CSS3 aspect to be adopted, or give patchwriters
more information on how to solve it? Remember there are not even close to as
many mail developers on this project as their used to be. Coming from my patch
writer's standpoint, I really don't see the harm in a patchwriter implementing
-moz-overflow-x, and -moz-overflow-y and from my web developer's standpoint,
this would be great and give them the same kinda flexibility they have for other
things like -moz-pre-wrap.
Let's get this discussion off of Bugzilla.

I opened a thread to further discuss the default value of overflow-x and
overflow-y at http://forums.mozillazine.org/viewtopic.php?p=569350#569350

I'd like to simply mention that overflow-x and overflow-y are in the specs for
CSS3 as David pointed out: http://www.w3.org/TR/2002/WD-css3-ui-20020802/#overflow-x

Therefore, the only thing that is up for debate, it seems, is what the value of
those two properties are by default. That is off-topic for a Bug report (this
isn't a thread or newsgroup but a bug reporting tool) and should be moved to the
forums. overflow-x and overflow-y being implemented will probably be handled in
a different bug. The default value will, I imagine, remain such that behavior is
consistent by default with how it used to be. Therefore, discussion should be
taken to the forums on what the default value is.

That I don't see a default value mentioned in the specs (without having paid
attention to a bulk of the discussion on the CSS list) would lead me to assume
that there has been no agreement yet over a default value. Makes sense, as it
should be decided on a browser-by-browser basis.

Therefore, for futher discussion on the default, head to ->
http://forums.mozillazine.org/viewtopic.php?p=569350#569350
URL: http://forums.mozillazine.org/viewtop...
Whiteboard: Take discussion to the forum topic 569350 at the above URL
The default value for those properties is 'visible' and must stay that way ever
for the root element in order for 'overflow' propagation from both HTML and BODY
to work.

And please stop confusing "how to 'fix' this bug" and "how to implement those
properties".
I am just designing a browser based user interface. In the left frame, the
content length might change, depending on user clicks on table cells in that
frame (caused by dynamic font size changes).

How utterly funny and stupid this looks when the user clicks on one cell, and
then the same cell jumps away from the mouse position when the scrollbar
appears/disappears!

Imagine you want to test drive a car and the salesman insists you must wear soap
solution or massage oil on your hands for that. When you object, then he pulls
out his ISO standard sheet and says: Para 97-k77, standards-compliant, WONTFIX.
Of course you go. Mozilla is very much like that. Good luck driving!

Needless to mention that we advise our users not to use Mozilla/Netscape 7.
The whole thread comes down to usability versus standards compliance. I
understand the logic for standards compliance. However, this is such a glaring
issue to Mozilla newbies that it is a MAJOR factor inhibiting its general
acceptance. 

I have put several clients on Firefox and frequently I get requests to shift
back to MSIE because the web pages don't look right under Firefox (or Mozilla).
I hear "It looks right in MSIE. Why doesn't it in Mozilla (Firefox)?" End
clients are more concerned about the operation of a business than a whole
explanation of why it wont work right because of a technical standard. At their
request I shift them back to MSIE. Future clients, I have to give them a verbal
disclaimer telling them that things might not look/work "perfectly", which is
pretty tough to "sell" a "broken" product to a business owner. I bet I could get
25% more of my clients to continue to run Firefox/Mozilla IF I HAD THE OPTION to
set the scroll bar to the permanent "on" position.

Everybody would be happy if we had an option to manually turn on/off the scroll
bar at the browser. Those that want strict browser compliance can leave it off.
Those that deal in the world of asthetics can turn it on. It would be an
EXCELLENT solution instead of just walking away at the expense of the Mozilla
project.
Re: Comment #170

I agree, it would be a great solution for everyone, but I think the people in
charge are just being stubbern and defient.

Just look at some of the silly things they have as user optons:

- Show the about page as a popup or not
- Show emoicons in mail messages
- Make mail and newsgroup messages quoted with graphical lines


They don't care about major concerns such as web page layouts shifting around
and breaking the athstetics of a web-based UI, but they'll make damn sure they
get those smiley faces in the mail client...

Rediculous.
Stop trolling in a closed bug, or your bugzilla accounts will be disabled.  Take
it to the forums or newsgroups.
Why is this bug marked as a wontfix when there is so many votes and people that
want it fixed?
(In reply to comment #170)
> I hear "It looks right in MSIE. Why doesn't it in Mozilla (Firefox)?" End

Are they complaining about the issue in this bug?  If not, then the comment is
irrelevant to this bug.
I'd like to re-iterate that if you post on mozillazine you will be heard.
http://forums.mozillazine.org/viewtopic.php?p=569350#569350

So far only one person has made a comment. Let's have some discussion there.
(In reply to comment #174)
> (In reply to comment #170)
> > I hear "It looks right in MSIE. Why doesn't it in Mozilla (Firefox)?" End
> 
> Are they complaining about the issue in this bug?  If not, then the comment is
> irrelevant to this bug.

Usually yes. Which seems to be the theme of the whole thread. If I have a client
wanting to move off of MSIE, it is because he uses too many "MSIE only" web
sites (like advanced features in msn.com) OR because he is getting too many
layout problems under Mozilla/Firefox when the scroll bar appears/disappears. I
have access to web logs of about 85 web sites and ~95% are using MSIE. Hmmm. Why
is that?

The people keeping this in a VERIFIED WONTFIX status or the people wanting to
censor the comments by dropping us out of bugzilla (comment #172), I think they
propose that it would be easier for us to contact the design firm of every web
site we find and have them bring the site to conform with the web standards at
the time and expense of the company. Many solution providers find it easier to
keep the client on MSIE. At least I am trying to convince clients that MSIE is a
lame browser that invites a host of security/privacy problems and the solution
lies with Mozilla/Firefox.

I find the price the Mozilla orginization pays is that solution proivders (and
evangelists) like me slow the recommendation and implementation of
Mozilla/Firefox because of this issue and others like it.
(In reply to comment #175)
> I'd like to re-iterate that if you post on mozillazine you will be heard.
> http://forums.mozillazine.org/viewtopic.php?p=569350#569350
> 
> So far only one person has made a comment. Let's have some discussion there.

I'm there....


*** Bug 251683 has been marked as a duplicate of this bug. ***
*** Bug 256879 has been marked as a duplicate of this bug. ***
*** Bug 265864 has been marked as a duplicate of this bug. ***
*** Bug 269411 has been marked as a duplicate of this bug. ***
No longer blocks: 158464
*** Bug 285421 has been marked as a duplicate of this bug. ***
*** Bug 265864 has been marked as a duplicate of this bug. ***
Summary: Web pages should have a persistant scrollbar for all pages → Web pages should have a persistent scrollbar for all pages
*** Bug 293723 has been marked as a duplicate of this bug. ***
*** Bug 294087 has been marked as a duplicate of this bug. ***
I have tried my best to thoroughly read this thread and the associated forum
thread produced from it.

However, and I mean absolutely no harm in doing this, I again would like to
bring up a place here to vote for the option to have permanent scrollbars (not
within iframe, but just in main window/tab in Mozilla/Firefox/etc itself (via
Tools->Options->Advanced) in a future release for the developer willing to take
it on. If it is marked as "WONTFIX" then people probably will not vote on it, so
no one will know how important it is to the user community. I am not emotional
about it (really), but I think it is in the best interest of the user experience
to bring this up again in bugzilla. I do this solely from a user's perspective.
I heard a few users last week complain about it to the point where they won't
use it. If our office is a microcosm of society in any way, I will assume there
are a number of others out there (more than the 13 who have voted on this bug)
that would use Firefox, etc. if this option would be implemented (and I might
suggest, have this functionality by default). Please understand that I have read
the request to take this comment to the forum, but my comment relates
specifically to this "bug" which is really a request for new functionality which
will seem to require significant work, but will pay off the effort in a larger
user community.
I currently use "body {overflow-y: scroll;}" to force the vertical scrollbar in browsers that support it. This effectively makes the issue a moot point, no?
(In reply to comment #187)
> I currently use "body {overflow-y: scroll;}" to force the vertical scrollbar in
> browsers that support it. This effectively makes the issue a moot point, no?

I do this too.

However, not all user groups that Firefox (supposedly) targets have the knowledge or skills to use "body {overflow-y: scroll;}" while they browse.

Is Firefox a web browser for IT professionals and CS majors, or a web browser for mere mortals too?
*** Bug 351851 has been marked as a duplicate of this bug. ***
My eye goes to left a little when I change from a short page to a long page. The default vertical scrollbar is good to usablity.
Attached file Work around — 
Attached a short userContent.css file to be placed in your profile directory that will fix this using the method above.
*** Bug 279425 has been marked as a duplicate of this bug. ***
*** Bug 360476 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: