Closed Bug 179692 Opened 23 years ago Closed 19 years ago

Always show scrollbars if needed, ignoring scrollbars=no

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: bugzilla, Unassigned)

References

(
URL
)

Details

(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 non-window.open() 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 non-window.open() window with all of its normal, standard browser functionalities. 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 window.open() 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. scrollbars=no - 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 window.open), 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 easier: - 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.
Jesse, First off, I think I would appreciate an open discussion in a mozilla newsgroup on all window.open() 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 window.open 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 http://bugzilla.mozilla.org/show_bug.cgi?id=130174#c18 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 and View/Scroll bars Ctrl+F7 Right now scrollbars=no resizable=no titlebar=no 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: javascript:window.open("http://mozilla.org/", "", "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, netscape.com, dictionary.com results, real.com, cnn.com, and fool.com had pop-ups without scrollbars or with necessary scrollbars that also appear in other browsers. aol.com and jobsonline.com 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 (aol.com).
Whiteboard: [p-opera]
*** Bug 186461 has been marked as a duplicate of this bug. ***
Note that scrollbars=no can be overridden by Bug 107949. user_pref("dom.disable_window_open_feature.scrollbars",false);
I already knew that "scrollbars=no" can be overridden with user_pref("dom.disable_window_open_feature.scrollbars",false); 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.
Status: UNCONFIRMED → NEW
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: javascript:void(window.open ('http://www.washingtonpost.com/wp-srv/photo/world/iraq/2002-12-12/1.htm', 'iraq','toolbar=no,location=no,directories=no,status=no,menubar=no, scrollbars=no,resizable=no,copyhistory=no, 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 issue. 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.
References: ----------- Gecko DOM reference (obviously needing to be updated) http://www.mozilla.org/docs/dom/domref/dom_window_ref76.html#1019331 "scrollbars: If yes, creates horizontal and vertical scrollbars when the Document grows larger than the window dimensions." http://developer.netscape.com/docs/manuals/js/client/jsref/window.htm#1202828 "When the viewport is smaller than the document's initial containing block, the user agent should offer a scrolling mechanism." http://www.w3.org/TR/CSS2/visuren.html#q2 http://www.w3.org/TR/CSS21/visuren.html#q2 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="http://www.mapquest.com/..." 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 mapquest.com page was opened in the small popup window which had no scrollbars. A good example of impractical, unwise approach to popup. newsgroup: netscape.netscape7.windows 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. At http://www.cnn.com/ you can find the link "Click here to make CNN.com your Home Page" and the code behind the link is this: <a href="javascript:CNN_openPopup('/feedback/help/homepage/frameset.exclude.html', '620x364', 'toolbar=no,location=no,directories=no,status=no,menubar=no,scrollbars=auto,resizable=no,width=620,height=430')"> 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 http://www.cnn.com/ when I clicked on the link "Click here to make CNN.com 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 javascript:CNN_openPopup('/feedback/help/homepage/frameset.exclude.html', '620x364','toolbar=no,location=no,directories=no,status=no,menubar=no, scrollbars=auto,resizable=no,width=620,height=430') [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: http://www.cnn.com/feedback/help/homepage/top.exclude.html Looking at the source and the page info (what a wonderful feature this is!), the http://i.a.cnn.net/cnn/feedback/help/homepage/images/cnn.new.gif 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 dom_bugs@netscape.com
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 newsgroup: netscape.netscape7.windows 3/27/2003 2:29 AM Go to http://www.colorgraphic.net/newsite/products/multiscreen_faqs.asp# 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() { MM_openBrWindow('../products/multiscreen_comparison.asp','pop','status=yes, menubar=yes,scrollbars=auto,resizable=yes,width=750,height=520') } function MM_openBrWindow(theURL,winName,features) { //v2.0 window.open(theURL,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.
Status: NEW → RESOLVED
Closed: 19 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 window.open() 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. While: 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 window.open()) 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 window.open 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" http://www.w3.org/TR/UAAG10-TECHS/topics.html#frame-techniques 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.