User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051012 Firefox/1.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051012 Firefox/1.6 If the window width is reduced at some point the visible content won't be fitted to the window and will be rendered outside the visible window and there is no way to display it. Well, hard to describe. Take a simple webpage like the sample html vom CSS Zengarden. Then reduce the window width by dragging the right window border to the left. You will see the text being reformatted while you drag the mouse. On a clean profile the reformatting stop if the address bar is reduced almost to zero width. If you then reduce the window width further, the window content will disappear behind the right window border. And there is no way to get to this content because there is no scrollbar at the bottom. The width where the reformatting stops is not fixed. If you remove the search bar of a new profile the reformatting will stop at a smaller window width. The bad thing is that this minimum width can also be bigger. With the web developer extension installed the reformatting stops if the blank space on the web developer toolbar is reduced to zero. That equals more than half of my desktop width (1280 pixels), i.e. i can't tile FF next to another window because then some content won't be visible. On webpages where there is minimum width implied in the design and where this minium width is bigger than the width where the reformatting stops, the result will vary. As soon as the design minimum width is met a scrollbar will be shown. But sometimes you also can't scroll to the right side enough to see all content Reproducible: Always Steps to Reproduce: 1. visit page 2. reduce window width Actual Results: reformatting of the page content will stop at a given window width Expected Results: keep reformatting until the window width is limited by the operating system, and display scrollbar if the content doesn't fit anymore Both Opera and IE do this correctly. They reformat the page until the window can't be made smaller anymore (OS limit). If there are long words that can't be wrapped or pictures, both browsers will display a scrollbar. Here is a picture: Opera vs. FF trunk: http://free.pages.at/mugros/neth.png (page is www.nethack.org and i am not using a clean profile, but that doesn't really matter, and the build was a bit older) Another picture: FF1.5beta vs Opera vs IE: FF1.5beta and 1.0.5 doesn't seem to show this behaviour.

I forgot the second picture link: http://free.pages.at/mugros/ff.jpg

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051012 Firefox/1.4.1 ID:2005101222 Yes, I see what you mean. This is a very recent regression (between these two builds: 1.8b5_2005101207 - 1.8b5_2005101121). It must be something in classic.jar; I don't see it using a theme.

I see this in trunk as well.

In trunk it happened between 1.9a1_2005100612 and 1.9a1_2005100619.

I've noticed the same when opening Console² in the sidebar. I've looked at the toolbars with the DOM-Inspector and it appears that the overflow property somehow gets set to "0px" (instead of "visible", "hidden", etc.). This setting can't be overridden even with "overflow: visible !important;".

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b5) Gecko/20051014 Firefox/1.4.1 ID:2005101403 Confirmed if the windowsize is reduced to less that the minimum widths of the tabs the scrollbars are gone. The tabs minimum width is a lot larger that it used to be. This only happens when the window is resized, adding a bunch of tabs reduces their size again

It has nothing to do with the example page. repro: 1.Open FF 2.Open 10 tabs 3.Open this page in a tab 4.Slowly resize the window width and notice the tabbar and window scrollbars 5.Maximise window 6.Add 10 more tabs 7.repeat step 4 and notice the difference

I don't see what tabs has to do with it....I see the verticle scroll bar disappear on bugzilla pages if the windows is shrunk enough even on beta 1. The horizontal scroll bar is there. And I can't repro on the given test URL or on say, the Fx start page. Maybe what I am seeing isn't this bug. I don't see the horizontal scroll bar disappear.

Tracy, could you please provide a screenshot only of the browser window if you visit csszengarden and reduce the width as far as you can? And i also don't see a difference in Peters repro. It looks always wrong. This bug is not about disappearing horizontal scollbars. It is about the window content not being resized while reducing the width of the window. The vertical scrollbars are inserted as soon as the content doesn't fit the height of the window anymore. And they disappear when reducing the width because the scrollbar will also be rendered outside the window. You'll see it if you slowly reduce the width. A horizontal scrollbar is displayed if the content width doesn't fit the window. But only if the design width limit is greater than the width where the bug comes into play. And even if there is a horizontal scrollbar, reduce the width to a minimum and try scrolling hotizontal. Most likely you won't be able to scroll to see everything. And the test URL doesn't matter. It happens on every page.

Mugros do you see this in a 10/17 branch build? Like Tracy, I'm having a hard time seeing the problem when I resize the window to smallest width possible. The text is wrapped based on that width now.

Please note that the back-out of the patch for bug 243078 on the 1.8 branch got also rid of this regression. It remains thus trunk only.

Excellent. Scott supposed as much. Removing the blocking nomination as this no longer affects the branch. Mugros, please test with this build http://stage.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8/

Asa, on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051017 Firefox/1.4.1 it is fixed. Latest trunk is still buggy, like reported.

Correct me if I'm wrong. But this is a really old bug. (Althoug I don't know which) Use Thunderbird! To reproduce: Go to "Options/Preferences"->"General"->"Select the window layout you prefer..." Select the second radio button. Restart. Resize the window and the window border will start to paint over the status bar. Spy++ tells me that the window (the message) is larger than what is shown.

This bug would have been fixed with a userChrome.css or a toolbar.css: toolbar { min-width: 1px; } But alas, later on (between 1.9a1_2006020906 and 1.9a1_2006020913) it regressed again in spite of the .css. http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-02-09+05%3A00&maxdate=2006-02-09+13%3A00 Bug 328040 seems related or a duplicate.

Another pair of StR: 1. Install the latest version of Console² from http://console2.mozdev.org/ 2. Go to View -> Sidebar -> Error Console and hit the All button 3. If the console is empty, hit the Alt key (generating a "Key eveent not available on GTK2" warning) or perform a Google search (leading to a CSS warning) Expected result: Either the whole warning is visible or horizontal scroll bars appear. Actual result: The warnings take the minimal width the console needs (which is too wide for the sidebar) but doesn't offer scroll bars as Firefox 2 did. Is that expected (and extensions such as Console² have to work around this) or an issue yet to be fixed?

Why is this in Core rather than Firefox?

> Why is this in Core rather than Firefox? See Comment #14

Unless we want to make significant changes to the behavior of XUL (maybe not a bad idea, but not the path we took the last few times this bug appeared), this is a front-end bug. If it happens in different apps, then they need separate bugs. And if we're going the change-XUL route, it's definitely not 1.9 material. It might be worth having a bug on file, though.

With these hacks I can't reproduce the bug. David, would you suggest a different / better fix?

> With these hacks I can't reproduce the bug. Shouldn't these be either in /toolkit/themes/ or in xul.css?

Why did you need overflow-x: hidden. That creates a bunch of extra frames to make things scrollable.

(In reply to comment #21) > Shouldn't these be either in /toolkit/themes/ or in xul.css? I think the fix isn't good enough to be applied to these elements under all circumstances and for all XUL apps. (In reply to comment #22) > Why did you need overflow-x: hidden. That creates a bunch of extra frames to > make things scrollable. Because the findbar triggers this bug, too, and min-width:1px didn't work there. Neither does overflow:-moz-hidden-unscrollable. Other suggestions?

David, any suggestions here?

Is this related to bug 204743?

Yes.

mainPopupSet triggers the bug, too.

Checking in browser/base/content/browser.css; /cvsroot/mozilla/browser/base/content/browser.css,v <-- browser.css new revision: 1.47; previous revision: 1.46 done

This really could use a regression test. It's been fixed in the past, and regressed at least once, if not more than once.

#FindToolbar { overflow-x: hidden; is causing a dot in the find bar here.

I think, same fix is needed for global/content/viewSource.css.

Comment on attachment 297723 [details] [diff] [review] Workaround for View Source rv.1.0 viewsource.css is used in the actual source document, not the chrome of the view-source window.

(In reply to comment #34) > #FindToolbar { > overflow-x: hidden; > is causing a dot in the find bar here. > I think it is not cause of dot. Because after deleting it using DOM Inspector, dot is still reproduced. I think dot in find bar text box is caused by incorrect height of blinking caret. When caret is drawn by reflow, window expose, moving caret by text input, its height is correct. But when automatic blinking, its height is not valid (top is valid. But bottom is not valid).

(In reply to comment #38) Yes, it does look like a caret bug. Any valuable information should be added to bug 412646, though.

(In reply to comment #37) > (From update of attachment 297723 [details] [diff] [review]) > viewsource.css is used in the actual source document, not the chrome of the > view-source window. > Should I fix /toolkit/components/viewsource/content/viewSource.xul or (toolkit/components/viewsource/content/viewSource.css instead of /layout/style/viewSource.css ?

(In reply to comment #40) > Should I fix /toolkit/components/viewsource/content/viewSource.xul or > (toolkit/components/viewsource/content/viewSource.css > instead of /layout/style/viewSource.css ? toolkit/components/viewsource/content/viewSource.css, although doing that for all toolkit apps is a little bit scarier than doing it for Firefox only, especially with bug 412646 in mind.

Comment on attachment 297723 [details] [diff] [review] Workaround for View Source rv.1.0 I'll wait until Bug 412646 is fixed.

Fx3.2pre seems to have same problem. I filed it as bug 478222.