Closed Bug 179692 Opened 18 years ago Closed 14 years ago

Always show scrollbars if needed, ignoring scrollbars=no


(Core :: DOM: Core & HTML, enhancement)

Not set





(Reporter: bugzilla, Unassigned)




(Keywords: access, Whiteboard: [p-opera])

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021108
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021108

Scrollbars appearance in secondary child [popup] window should behave just
exactly like a block-level element with the css declaration overflow:auto : such
behavior should be by default and should override any author's request (explicit
or implicit) in the window features list (scrollbars=no).

A secondary child [popup] window's ability to scroll, to have visible and active
scrollbars when needed, when the document overflows the given browser window
inner viewport dimensions, and this, regardless, despite and notwithstanding
whatever the author requested. 
In other words, a secondary child [popup] window should behave just exactly like
a parent window.

Scrollbars are a normal part of an UI navigational system; when they are
visible, they notify, they inform the user that a part of the document is
clipped, masked, hidden, that it overflows the viewport and that it can be
reached, scrolled to via mouse support thanks to scrollbars. 99% of users know
if they can scroll a document if they see active scrollbars. Visible appearance
of active scrollbars is per se an important element of information.

Right now,
scrollbars=yes       implies that scrollbars will appear ONLY if the document
overflows the browser viewport. Scrollbars will not appear if the document does
not overflow the browser viewport. In other words, scrollbars=yes acts, behaves
like overflow:auto .

scrollbars=no         implies that scrollbars will NOT appear regardless if the
document overflows or not the browser viewport. This setting coupled, combined
with resizable=no makes it hard for the user. In such case, his only safe and
reliable recourse left is to try PgUp/PgDn keys to see if the document is
clipped, if he can scroll up/down furthermore the content. (Mousewheel also
works but is less supported, universal).

It is not in the best interests of both the user and the author to mask, hide,
misinform, deceive or to make difficult the access of the content of an opened
window by the user.
A window which deserves to be opened ought to behave exactly like a normal,
parent window with all of its normal, standard browser
The author should have 100% control over the content; the user should have 100%
control and veto over the normal standard functionality of his browser and his
chrome bars/elements.
Both authors and users should not have concerns, troubles, worries with browser
functionalities and chrome elements: they both should respectively focus on content.

Reproducible: Always

Steps to Reproduce:
Go to the given URL and open a few secondary child [popup] windows with
scrollbars=yes|no and with resizable=yes|no .

An explicit scrollbars=no (or an implicit scrollbars=no) in the window features
list of the method should be ignored all the time.
Scrollbars should appear/disappear depending only, solely on the document
overflow [status] versus browser inner viewport dimensions. A secondary child
popup window should behave like a block-level element with the css declaration
overflow:auto. Always. By default.
When a page uses scrollbars=no but the content is larger than the window, is the
cut-off part of the page usually a few blank pixels, or is it usually useful
content?  If it's usually the latter, fixing this would make sense.

I searched Bugzilla for "scrollbars=" and found bug 130174, an accidental
regression where scrollbar=no was ignored.  The bug has 14 votes and 7 dups even
though it was only open for 2-3 months.  That seems to suggest that many sites
rely on scrollbars=no.
Summary: Scrollbars should appear/disappear (if needed) automatically by default in all secondary child windows regardless of the author's explicit or implicit request (scrollbars=no) → Always show scrollbars if needed, ignoring scrollbars=no
> (...) is the cut-off part of the page usually a few blank pixels,
This bug is about determining the respective control powers and responsibilities
between authors and users and determining who should control what in a browser
window. It's not about a few pixels here or there: it may look like that for
many but it's not. It's more than that. Scrollbars are not just navigational
elements: they convey an important element of information. 
If you believe that a window layout, chrome presence, normal standard chrome
functionality, etc.. should be determined by authors, then you won't vote for
this bug.
- clips overflowed content
- disinforms the user when this happens
- supports furthermore authors' complacency
- does not make website developers focus on content, quite on the contrary, it
supports complacency regarding content
- supports incompetence and lack of knowledge: we don't know, don't bother,
don't care what makes the content grow like that: just clip the rest.

I can override an author's style sheet who would write <html
style="overflow:hidden;"> in a page with an user style sheet. But I cannot
override an author's window features in a popup window.

Authors have the obligation to make their content fit their specifically-sized
container in the first place. When content overflows container, then a normal,
standard fallback mechanism should take over and prevail, period. Despite the
author. Such standard normal fallback mechanism should always prevail. The web
is the only place where secondary child popup browser windows normal
functionality can be turn off by the content provider. You won't see this
anywhere in windows-based applications anywhere.

There is a simple, reliable, 100% infallible way to turn off scrollbars in a
window: you first make the content, that is *your* own content fit within your
own requested sizes of the secondary child popup window you create.
Web developpers should try to make the content fit the browser window. That's
what a web developer should be paid to do in the first place. And when the
document (content) overflows - whatever the reasons why - the given specified
size of the generated window (via, then a normal, standard fallback
[scrolling] mechanism provided by the browser should take over and prevail.
Despite the author. Such scrolling mechanism should be working and visible.

That's how thousands of softwares and applications behave and work for generated
document-based sub-windows. Web developers are 100% in control of the content;
users should have 100% control over normal browser functionalities and normal
chrome UI functionalities.
Dr. Unclear: I don't think an argument involving authors "vs" users is
appropriate for this issue.  There's no "fight" between authors and users here
like there is with whether sites should be allowed to open unrequested pop-ups.
 Few authors would intentionally hide a scrollbar where content has been clipped
just to make the window look better.

If you want to argue for this change, don't say "users should have 100%
control...".  Instead, say something like
- "There are a lot of sites that disable scrollbars where a vertical scrollbars
would be useful at normal font sizes." or
- "Accessibility for users who have set default font zoom to 150% on any site
with pop-ups is more important than a minor compatibility issue with some
existing pop-ups that would affect all users."

Because this is a tradeoff, try to be quantitative where it's reasonable.  It's
hard to quantify accessibility vs aesthetics or user confusion vs author
frustration, but you can get estimates of the number of sites and users affected
by each side of the tradeoff.  Examples of things that might make this decision

- What percent of users set the default font zoom above 100%?
- Is that percent changing due to changing demographics of Web users?

- What percent of pop-up windows (both requested and unrequested) on a sample of
popular sites use scrollbars=no?
- What percent of pop-up windows contain only a large image link filling the
window, and what percent contain text?
- What percent of those pop-up windows would get vertical scrollbars if
scrollbars=no were ignored?
- What percent of those pop-up windows would get horizontal scrollbars, either
directly or as a result of the appearance of vertical scrollbars?

- In a sample of web developers, how many would figure out how to work around
not being able to use scrollbars=no?
- In a sample of web developers, how many would figure out that Mozilla is
trying to be promote accessibility rather than trying to be different?

By the way, thank you for filing this bug about the default behavior rather than
requesting a pref.

First off, I think I would appreciate an open discussion in a mozilla newsgroup
on all related issues and on this issue. As I said before (I have
many bugs filed right now related to the open() method), I've "probed"
newsgroups on these related issues. So, if you could direct me to a particular
mozilla newsgroup (for developers) where I can present this bug and other
related issue, I would appreciate that.

Second, in my mind, this *is* an author vs user issue. In my mind, once the
content overflows the specified sizes of a popup window, then the default,
normal, standard browser fallback mechanism *should* take over and render
active, usable and activated scrollbar(s) where necessary/needed. Even W3C
clearly suggests this as the normal, standard behavior.
Even tens of thousands of softwares in the last 20 years have behave like that,
exactly like that when the content of an application window was wider/longer
than the window application viewport. This enhancement request is really an
enhancement from the user's perspective: the usability idea behind this bug is
to get back to how a normal browser window should react, behave, regardless if
it's a main parent opener window or a sub-window generated by a open() call.

"users should have 100% control...": yes, that's exactly what users should have
and that's exactly what users already have with parent-opener windows. Look at
bug 75158 and tell me why an user should not be able to restore the chrome he
wants or would want. Chrome elements presence, visibility and normal standard
browser functionality should be under the 100% unconditional user's control:
that's exactly what this bug (and many others) is about.

And I'm saying "There are a lot of sites that disable scrollbars where a
vertical scrollbars would be useful at normal font sizes." that too! Those who
want scrollbars=no never use nor see the windows they create from the users'
perspective: they see these windows from another perspective.

I cannot poll or do surveys on the questions you forwarded. But as a regular in
web languages newsgroups, I can assure you that "scrollbars=no" and
"resizable=no" are the most automatic-without-thinking "features" in the scripts
of people requesting help. Even "titlebar=no" and how to remove titlebar are 
regular questions in 2 newsgroups. Many javascripts Cut-N-paste sites have
"scrollbars=no" very often in their scripts and people do not stop thinking a
bit at what they're doing. " I have used the feature list to crop
the page for presentation. This isn't the only time scrollbars show up that are
not wanted. This is basic functionality, learned by anyone who has ever scripted
anything, written about in countless books and tutorials. It needs to work."
coming from
Absolutely true. And the "functionality" he's talking about his disabled scrollbars!
They don't see the users and (often because of their objective position) they
don't relate to the users either. Even several tutorials (even the netscape
documentation had "scrollbars=no" as examples - I could find the precise url
again) give examples with scrollbars=no. 

Relatively VERY few people know, understand that "scrollbars=yes" does not mean
permanent scrollbars but rather "if-needed" scrollbars, like css overflow:auto.
Most people think that "scrollbars=yes" behaves like css overflow:scroll when in
fact it behaves overflow:auto.

I invite you to go at bug 149077 and then try, play with the test case
attachment 104694 [details] I did on popup windows. Now, this demo has 3 types of popups.
I mention this demo case because in comment 1 you suggested that "the content is
larger than the window, (...) [just] usually a few blank pixels" and I am sure
it's because these authors ignore the default browser values of margins, borders
and padding on the document root element, html and body of their own page and in
different rendering modes. FYI, MSIE 6 in standards compliant rendering mode the
document root element has this css declaration 
html {medium #000000 inset; overflow:scroll; overflow-y:scroll;}
body {margin:15px 10px; overflow:visible; overflow-y:visible;}
while Mozilla 1.0+ has 
html {overflow:visible;}
body{margin:8px; overflow:visible;}
This margin:8px is basically what is involved in bug 149077: I believe it is
fair to say I have demonstrated that already.

If several years ago, this window feature had been named
overflow=auto      instead of    scrollbars=yes
overflow=clip      instead of    scrollbars=no,
then people would have understood this differently and I'm pretty sure that this
enhancement would have been already implemented in Mozilla.

You asked
- What percent of those pop-up windows would get horizontal scrollbars, either
directly or as a result of the appearance of vertical scrollbars?
The unavoidable question is still why authors cannot figure out how to size
properly their windows when generating popup? If they cannot be assure, in full
control of the result at the other end on the user's monitor screen - whatever
the reason why their careful planning failed - , then what's the safest,
cautious option left available? Clip content or render visible, active
scrollbars? What would be the wise reasonable choice here?
- In a sample of web developers, how many would figure out how to work around
not being able to use scrollbars=no?
That's not the point. Your question is a very author-oriented perspective.
"scrollbars=yes" behaves like overflow:auto. So, all they need to do to work
around this would be to make their content fit their generated window: they
control both. They decide and control the content and the initial size of the
windows: what more do they need in order to work, compose with such reality?
FYI, I submitted 2 enhancements bugs regarding the sizeToContent() method: to
make sizeToContent a window feature ( bug 179704 ) and an UI prefs setting ( bug
179711 ). I submitted these 2 bugs on the same day I submitted *this* 179692
bug: in my mind, these 3 bugs go hand-in-hand together without any user vs
author contradiction. If just 1 of these 2 ever become reality in Mozilla, then
sizeToContent as a window feature will override,  bypass any "scrollbars=???"
request in the open() method argument. Then one can make it a DevEdge technote
and the snowball gets rolling and the news gets spreading.
Opera 7 gives the user the ability to override, overrule the author's request to
disable scrollbars.

File/Preferences... Alt+P/Windows/Browser windows/Show scrollbars
View/Scroll bars Ctrl+F7

Right now
are all ignored;
status=yes|no is also ignored on popup
Only location=no works and I suspect this is due to a bug in the prefs.

There are bugs right now with some these commands but it is utterly clear that
the intent of Opera dev. software was to give the users full control and the
last word on all window features (chrome bars, windows functionalities).
Adding [p-opera].  As Dr. Unclear pointed out, Opera 7 beta (but not Opera 6)
ignores scrollbars=no by default.  Example:"", "",
"width=300,height=300,scrollbars=no"); void 0

I went to 8 sites with unrequested pop-ups in Opera and 2 had unnecessary
scrollbars.  (Ebert search,, results,,, and had pop-ups without scrollbars or with necessary
scrollbars that also appear in other browsers. and had
pop-ups with unnecessary scrollbars.)

Opera 7 does some sketchy things with pop-ups, so I wouldn't trust their
judgement on the scrollbar issue.  For example, it opens pop-ups as MDI child
windows that look like normal (non-MDI) windows, but it also adds a tab for each
pop-up.  You can't drag a pop-up out of the Opera content area and maximizing a
pop-up turns it into a normal tab.  Opera avoids putting horizontal scrollbars
on pop-ups even when a vertical scrollbar make a horizontal scrollbar necessary
Whiteboard: [p-opera]
*** Bug 186461 has been marked as a duplicate of this bug. ***
Note that scrollbars=no can be overridden by Bug 107949.

I already knew that "scrollbars=no" can be overridden with
when I filed the bug. This will only work for Mozilla users who are aware of how
to use the user.js file, are aware of this user_pref. 

I'd like scrollbars to appear, disappear, re-appear, re-disappear [by itself]
only because the content is wider/longer/narrower/shorter than what the browser
viewport offers. Isn't that the way all kinds of softwares have been working in
the last 20 years? 
No setting to select, no user pref to choose, no option button to click, no
user_pref instruction to paste: just plain common usability sense.

I'm amazed that an unconfirmed bug can be resolved as a duplicate of another
unconfirmed bug. 
Ever confirmed: true
The Washington Post uses lots of fixed windows with code that disables
scrollbars and window-resizing. For some of us old guys who need larger print,
we can't see the whole window. The web designers don't think about that.

There is no reason for them to put in those codes--for example:
width=468,height=550,left=0,top=0,screenX=0,screenY=0')) [spaces added to fit
example in text window]. There is no reasonable ground not to make Moz
impervious to such lousy design. I, too, use the user_pref codes to override the
website's design, but it took me a long time to learn how. Moz should have this
setting by default.
>The Washington Post uses lots of fixed windows with code that disables
scrollbars and window-resizing. For some of us old guys who need larger print,
we can't see the whole window.

I stumbled across several posts in various newsgroups where both scrollbars and
resizability were turn off by the web designer. And yes, just increasing a bit
the font-size makes content overflow. 
In most cases, if there is just 1 matter which was forgotten or underestimated
by the web designer, then, on the other end, the user is sadly cornered
(litterally) by a rigid window which cannot be resized, which does not indicate
visually if the content overflows and which cannot be scrolled by normal,
intuitive means (scrollbars). 
For instance, Gecko-based browsers have a default margin of 8px set to the body
node while MSIE 6 has a default margin of 15px and 10px set to the body node and
a medium #000000 inset border set to the html node. Now, if the web designer is
ignorant of that, his "precise" window size calculations will miss these values
and scrollbars will be generated and he will NOT know/understand why. And this
web author is most likely going to resort (as a shortcut, easy way out) to
scrollbars=no when he should not. In comment #1, Jesse said: "is the
cut-off part of the page usually a few blank pixels": now we know where those
few pixels come from. 
Attachment 104694 [details] of bug 149077 is a good example of how scrollbars are
generated without taking into consideration the [hidden] default margin values
of the browser.
There are other cases which plead for fixing this bug (I found several
problem-pages just by answering posts in newsgroups and I'll eventually list a
few in here). The main common denominator of all these
problem-pages-with-scrollbars=no is that the web designer missed something (or
didn't test enough) when he went on with rigid size values, and then "finished"
off his work (and his webpage usability with it) with scrollbars=no; at the
other end, the user is confused, irritated, does not know what happens, what to
do... when it can be proven that by just setting scrollbars=yes, half of the
user problems (and irritation, helplessness, confusion) would have been reduced.
I can document this.
Setting scrollbars=no is like using scissors on a jigsaw puzzle piece because it
does not fit the spot where the web designer would like it to fit ... and the
web designer does not have time to figure out where is the correct jigsaw puzzle
fitting that spot.

>There is no reasonable ground not to make Moz impervious to such lousy design.
I've spoken in several bugfiles to make invincible, unchangeable, unscriptable
many (if not all) chrome UI elements (which affect, determine the browser window
functionality). Browser window resizability, scrollbars presence/absence and
even presence of menu bar (see bug 75158) should always have an unchangeable,
unscriptable browser default functionality. I think some chrome bars could be
controlled, vetoed by an user setting; on the other hand, resizing, scrollbars,
statusbar, titlebar and menubar should always be there as unchangeable standard
default browser functionalities/UI elements.
Blocks: useragent
Personally, I'd vote against this request.  I'm making a personal "note to self"
app and use popups for notes and tasks.  The calendar I show in the task window
sometimes is a little larger for those months that span 6 weeks, and is causing
scrollbars to appear (that let me scroll a whopping 8 or 9 pixels).  Yes, I
could resize the popup to be a little larger, but I'd rather Mozilla just
respect the "scrollbars=no" instructions that I have in there.  I'm the only
user of this app (for personal notes) so this isn't always a developer vs. user

While Dr Unclear does raise some valid points, particularly concerning how this
might have been avoided earlier, now I'd rather we maintain backwards
compatability.  If we suddenly ignore "scrollbars=no", then we no longer match
the published javascript specs, and Mozilla looks flakier than it deserves.  As
far as I'm concerned, a browser that ignores documented instructions is buggy.

Gecko DOM reference (obviously needing to be updated)

"scrollbars: If yes, creates horizontal and vertical scrollbars when the
Document grows larger than the window dimensions."

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

There is nothing on scrollbars in Javascript ECMA-10262 3rd edition and
Javascript 2.0 ECMA 4th edition.

There is no known DHTML or javascript or DOM standard on scrollbars. MSDN
supports scrollbars=yes|no while Opera ignore scrollbars=yes|no and renders
scrollbars if needed.
brianb may construct his own app, but website designers are not as talented as
he is. Instead, they make one-size-fits-all fixed windows that disallow
scrollbars and resizing, so that if you can't see it all--tough. With the
proposed change, the browser would obey the code and make the window of the
stated size. If the content fits, there will be no scrollbars. If the window is
too small and scrollbars appear, th user can adjust the window size so that the
scrollbars disappear. This is just basic, polite behavior that the web designer
should have allowed in the first place.
Here's a post that gives me another reason why scrollbars=no should be ignored:
it's rigid, impractical and limitative for the user. Popup with scrollbars=no
(and w/o other disabled features) are meant to be used, viewed once and then
disposed of, closed... otherwise the user cannot really surf to another url with
such crippled, "broken" browser window. Scripts cannot bring back normal window
functionality like scrollbars once a popup has been created with scrollbars=no.
Now, what if such crippled window has clickable links? leading to documents with
content of different sizes? What if the user closes the parent/opener instead
and tries to surf from/with the popup?

newsgroup: comp.lang.javascript
Subject line: Need help adding scrollbars to window
date: 12/26/2002 8:26 PM

"I've got a pop-up window that starts its life with no scrollbars, but I only
want it to look that way for the first page. When a visitor clicks a link, I'd
like to be able to add the scrollbars to the window again once the new page loads."


Here's another post where a popup had <area href=""
target="_blank"> and clicking on the area could not open another maximized
window because it was prevented by the user pref setting in NS 7 ("Open a link
in a new window" was disabled). So, the page was opened in the
small popup window which had no scrollbars. A good example of impractical,
unwise approach to popup.

Subject line: popups cutoff on right side
date: 11/25/2002 7:46 PM

"I have been having an annoying problem with popups with non-resizable borders,
in that the right side is usually cutoff.  This seems to occur in Javascript and
Java popups.  For instance, if I open a window with a game in Java, I can't see
the extreme right side of the window."

"Your irritations would have cut in half if they had put scrollbars=yes: I'm
sure of this." 
The other half was resizable=no.
See also bug 170454, "Pref to disable scrollbars=no".
Keywords: access
Here's another example supporting this bug enhancement request.
you can find the link "Click here to make your Home Page"
and the code behind the link is this:

Now, scrollbars=auto will be ignored because not valid, not recognized.
scrollbars=auto is intuitive (like HTML 4 frame attribute scrolling="auto" and
css property overflow:auto) and more meaningful than scrollbars=yes but that's
not the point here. The programmer wanted the popup to display scrollbars if
they are needed but his coding ends up always with an opposite result. (Btw,
note the resizable=no feature: so, if something goes wrong with content overflow
and/or scrollbars, then the user is sadly stuck with a crippled, unusable popup
window: this has happened before.) In my scr. res. and font-size, the whole
frameset of the popup is displayed within the  620x430 client area. But that's
not really the point of this bugfile. Ignoring scrollbars=no or
scrollbars=whatever is the safe and cautious alternative 
- which is to be preferred over to its counter-part, 
- which is the least damaging in case something goes wrong, 
- which is the normal usability expectation of any document-based application
- which is the recommended and suggested normal outcome as defined by official
W3C TRs and
- which will meet both the author and the users' perspective and best interests.
I use Phoenix with user_pref("dom.disable_window_open_feature.scrollbars", true);
in user.js. Up until today, this leaves me with scrollbars when the popup window
is too small. Yet at when I clicked on the link "Click here
to make your Home Page" no matter how small I made the window (I have
prefs in user.js that override the no-resize setting) I don't get scrollbars. 

This is unsettling. Indeed the code behind the link is
[spaces added for clarity]. 

There is, in fact, additional content to the right of the main title in the
popup window -- useless, but present -- that cannot be seen in its entirety
because I cannot make the window wide enough. Clearly an example of a situation
where having those scrollbars would make a difference.
True, Ed!
This is the popup code. frameset has cols="*"; frames have scrolling=no
everywhere possible. That explains why no matter how small you make the window
you don't get scrollbars.

<frameset rows="64,*,66" cols="*" border="0" frameborder="NO">

  <frame src="top.exclude.html" name="topbanner" scrolling=NO frameborder="NO"
noresize marginwidth="0" marginheight="0">
  <frame src="content.html" name="content" scrolling=no noresize
frameborder="NO" marginwidth="0" marginheight="0">
  <frame src="bottom.exclude.html" name="back" scrolling=no noresize
marginwidth="0" marginheight="0" frameborder="NO">

This is the file that makes it so wide:

Looking at the source and the page info (what a wonderful feature this is!), the
is supposed to use 645 pixels wide only. The background image is tiled
horizontally as well thanks to the background attribute ... therefore making the
document client area wider.

As you rightly said, in case of a content overflow, the browser should always
allow the content to be accessed. Here, what's even worse is that despite
absence of scrollbars, one could <PgUp>/<PgDn> if the overflow was vertical. But
there is no way to do this horizontally (see comment #16 for a similar story).
I have been running Phoenix with a number of prefs in user.js that--with one
exception previously noted--force popup windows to have all toolbars, to have
access to all menus, to be resizable and to have scrollbars. This does not
detract from the browsing experience at all. These should be the default settings.
Mass-reassigning bugs to
Assignee: jst → dom_bugs
I stumbled across a post which is worth mentioning in this bugfile.
Subject line: When link opens new window only part of URL is there
3/27/2003 2:29 AM

Go to
And then click on the Product Comparison Chart link in the left side menu

This is the call:
<td width=158 height=22 align="right" bgcolor=#BCC6F9 class="leftNavText"><a
href="#" onClick="popupComparisonA();">Product
              Comparison Chart</a></td>

and these are the related functions:

// popupComparisonA() - popup window for the Multiscreen Comparison Chart 
function popupComparisonA() {

function MM_openBrWindow(theURL,winName,features) { //v2.0,winName,features);

Now, notice that the windowFeature is "scrollbars=auto" and not
"scrollbars=yes". So, the result is that the popup comes up but without
horizontal scrollbar and no vertical scrollbar in NS 7 and in Mozilla 1.3final.
Not so in Opera 7.03: both scrollbars are visible and active. So, everyone can
see how fixing this bug could have made the difference here.
If mozilla is interpreting non-"no" values of of scrollbars as "no" please file
a separate bug with testcase (if one isn't filed already). That is not this bug,
even if it is in the same spirit as this bug.

[for the record, i don't think browsers should ignore page authors, but instead
provide some method of recovery from author screw ups. As such I'd like to see
this bug wontfix'd and any effort go into providing a mechnism to restore all
defaults (scolling, resizing, toolbars, etc) to a given window. I think this is
already filed as well I just can't be bothered to look for a bug #]
Anything that is not "scrollbars=yes" or "scrollbars=1" will be considered and
treated de facto for practical reasons as "scrollbars=no". Maybe I should
re-word the summary here. I submit, claim that "scrollbars=no" should never
work, never be possible in all browsers.

I think all browsers should ignore authors' requests when these involve normal
and standard browser functionalities like window resizability, scrollbars
presence/activity and statusbar. I did not say page content here.
In my mind, only the browser should determine if scrollbars are needed in a page
because the content overflows window's dimensions. No setting to choose, no
prefs to make, no checkbox to check, no Edit/preferences to manage or to
remember, no user stylesheet with 
html {overflow:auto !important;}
to edit and implement, no View/Show-Hide menu to use. It's been like this for 20
years or so in thousands of document-based software applications.

Why should I have to check or uncheck a setting in the View/Show-Hide sub-menu
possibly every time a popup arrives on my screen? Because this is what bug 75158
suggests and is about as far as I'm concerned. 
Should we add a "scrollbars if needed" menu item in the View/Show-Hide
sub-menu?? or a checkbox somewhere in the user pref for "Show scrollbars if
needed"??? Ridiculous!
Either your proposal of mechanism is a permanent setting (and that is bug
170454) only modifiable by the user or a temporary one (in the spirit of bug
75158) or a permanent default setting of the browser like I'm proposing.
The intention of my last comment was merely to refer to comment 23 and point out
that the following are two different bugs:

(1) Ignoring a page authors valid (by definition of the scripting language)
request for purposes of accessability.

(2) Changing the handling of an erroneous value for a given parameter of a
script (by definition of the scripting language).

[p.s. Ignore the aside in my last comment if you'd like, it was just my stance
on this bug, and an asside not the purpose of comment 24. I will not reply to
any further comments wrt to my stance on the resolution of this bug,  I'm not
planning on working on this bug so any more comments I make will serve only as
spam for the folks assigned & CC'd]
> Why should I have to check or uncheck a setting in the View/Show-Hide sub-menu
> possibly every time a popup arrives on my screen? Because this is what bug 75158
> suggests and is about as far as I'm concerned.

Manually adding toolbars to a popup (using a method from bug 69099, bug 75158,
or elsewhere) would almost certainly make scrollbars appear if necessary.

Please stop repeating your entire stance on this bug every time someone makes a
useful technical comment.  It is annoying and hurts your credibility.
Summary: Always show scrollbars if needed, ignoring scrollbars=no → Always show scrollbars if needed, ignoring scrollbars[=string]
"scrollbars=[string]" is both incorrect (see comment 26) and harder to search
for than "scrollbars=no".  Reverting summary.
Summary: Always show scrollbars if needed, ignoring scrollbars[=string] → Always show scrollbars if needed, ignoring scrollbars=no
OS: Windows XP → All
Hardware: PC → All
Flags: blocking1.9a1?
Flags: blocking-aviary2.0?
Flags: blocking-aviary2? → blocking1.8.1?
Clearing, want input from UE folks.
Flags: blocking1.8.1?
Flags: blocking1.9a1? → blocking1.9-
Doing this would cause serious web compat issues.  See bug 160627 for the problems Camino is having because it accidentally ended up with this behavior.

Wontfix, since doing this would actually be a disservice to most of our users.
Closed: 14 years ago
Resolution: --- → WONTFIX
> Doing this would cause serious web compat issues.  See bug 160627 for the
> problems Camino is having because it accidentally ended up with this behavior.
> Wontfix, since doing this would actually be a disservice to most of our users.

"most of our users": I think you mean web authors using/relying on calls, right?

I strongly disagree with WONTFIX here. 
Not knowing (no visual cue) there is more content available via scrolling laterally or vertically, 
not being able to scroll with scrollbar(s) (and with keyboard PgUp/PgDn/left arrow, right arrow, etc), 
not being able to restore scrollability easily 
are *_objectively_* far more damaging the user experience (and the author's objective interests) than the annoyance of having to scroll.

You have not provided any kind of compensation for resolving this bug as WONTFIX. It's widely admitted and acknowledged that about:config interface is not user friendly and is not well documented (it's not always obvious to know what this or that preference name does or means; no documentation on how/if changes are persistent changes, how changes can affect profile, etc). Creating and editing an user.js is a "road" far more away/difficult (or to expect) from the normal/avg user. 

No tech evangelism either on this issue. No tech evangelism on what may cause scrollbar(s) to appear.

scrollbar=yes, scrollbar=auto, scrollbar=always, scrollbar=horizontal, scrollbar=vertical, scrollbar=1, scrollbars=auto,  scrollbars=horizontal, scrollbars=vertical, scroll=yes, scroll=always, scrolling=yes, scrolling=always (...) are all resolved as scrollbars=no: the working of the default favors removal scrollbar, not the accessibility of showing them when needed.
scrollbar=no, scrollbar=never, scrollbar=0, scroll=no, scroll=never, scroll=0, scrolling=no, scrolling=never, scrolling=0 are all resolved as scrollbars=no

No UI for imposing scrollbar(s) when needed, when content overflows window dimensions, by overriding scripter's "scrollbars=no" demand: no bugfile on that anyway (despite whatever people may think of bug 107949).

Boris, I see no balance, no careful level-headed decision here.

Removing via script scrollbar(s) when the interface/page/document requires scrollbar(s) is just as dumb as removing the Back and Forward buttons (inter-history-session-page navigation).
Removing via script scrollbar(s) when the interface/page/document requires scrollbar(s) is breaking normal, standard intra-page/intra-document navigation.
Bug 170454 (Pref to disable scrollbars=no) was resolved on the basis that bug 107949 (pref for ignoring window feature options on was fixing this scrollbar issue. This can not be true unless one believes that about:config is a good enough UI for a wide majority of new/current Firefox users. So, no compensation here.

Bug 75158 ('View' > 'Show/Hide' menu items can't override flags) covers the current viewable/selectable toolbars. It does not cover scrollbars presence if needed. So, even if bug 75158 was fixed today, it would still not provide in any way a simple interface for users. So, no compensation here.

UAAG 1.0 clearly recommends browser vendor/manufacturer to provide users a mechanism to override scrolling="no" to frame-based webpage. What is so far fetched when considering that a non-framed webpage is in fact a single frame webpage?
"In order to ensure that content is accessible, allow the user to override some attributes of the FRAME element of HTML 4: (...) scrolling"

K-Meleon 1.0 (a light, ultra-fast, fully customizable Gecko-based browser) and Opera 7.x, Opera 8.x and Opera 9.x have an UI for forcing rendering of scrollbars (if/when required by content overflowing window dimensions): I can upload screenshots of their UI if we need to go this far. Are they all missing the point?
UI for forcing rendering is different from ignoring scrollbars=no by default.  If you want such UI, please file bugs on the relevant products (Firefox, Seamonkey, etc).  That's not a Gecko issue.
"most of our users" means "people who go to a news site, click a link to an image, and expect to see the image, not have to scroll to see the bottom left of it".  Did you even read the bug I cited?

Again, if your issue is that the UI sucks, please file bugs on the UI.
Note: this bug is not about always showing scrollbars in popup windows, even when there is no overflow, it's about threating "scrollbars=no" as if there was overflow:auto on the canvas (as opposed to the current behavior overflow:hidden, or the misunderstood behavior of overflow:scroll).
oops, s/threating/treating/
You need to log in before you can comment on or make changes to this bug.