Last Comment Bug 312247 - content is rendered outside the window if width is reduced
: content is rendered outside the window if width is reduced
Status: RESOLVED FIXED
[see comment #7 and #16 for alternati...
: regression
Product: Firefox
Classification: Client Software
Component: General (show other bugs)
: Trunk
: All All
P3 major (vote)
: Firefox 3 beta3
Assigned To: Dão Gottwald [:dao]
:
:
Mentors:
http://www.csszengarden.com/zengarden...
: 391358 392410 399142 403666 408628 412063 (view as bug list)
Depends on: 204743 328040 412646 425374
Blocks: 395980
  Show dependency treegraph
 
Reported: 2005-10-12 17:12 PDT by Mugros
Modified: 2009-02-12 07:53 PST (History)
21 users (show)
mconnor: blocking‑firefox3+
dbaron: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
workaround (2.33 KB, patch)
2007-10-02 08:47 PDT, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
workaround v2 (789 bytes, patch)
2007-12-12 14:15 PST, Dão Gottwald [:dao]
mconnor: review+
Details | Diff | Splinter Review
Workaround for View Source rv.1.0 (679 bytes, patch)
2008-01-18 02:27 PST, Masahiro YAMADA
dao+bmo: review-
Details | Diff | Splinter Review

Description User image Mugros 2005-10-12 17:12:26 PDT
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.
Comment 1 User image Mugros 2005-10-12 17:13:52 PDT
I forgot the second picture link:
http://free.pages.at/mugros/ff.jpg
Comment 2 User image Ria Klaassen (not reading all bugmail) 2005-10-13 05:20:25 PDT
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.
Comment 3 User image Ria Klaassen (not reading all bugmail) 2005-10-13 05:22:58 PDT
I see this in trunk as well.
Comment 4 User image Ria Klaassen (not reading all bugmail) 2005-10-13 05:33:49 PDT
In trunk it happened between 1.9a1_2005100612 and 1.9a1_2005100619.
Comment 5 User image Simon Bünzli 2005-10-14 08:04:21 PDT
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;".
Comment 6 User image Peter van der Woude [:Peter6] 2005-10-14 08:08:27 PDT
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
Comment 7 User image Peter van der Woude [:Peter6] 2005-10-14 08:12:08 PDT
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
Comment 8 User image Tracy Walker [:tracy] 2005-10-17 12:36:07 PDT
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.
Comment 9 User image Mugros 2005-10-17 13:09:58 PDT
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.
Comment 10 User image Scott MacGregor 2005-10-17 14:05:38 PDT
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. 
Comment 11 User image Simon Bünzli 2005-10-17 14:10:41 PDT
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.
Comment 12 User image Asa Dotzler [:asa] 2005-10-17 14:23:10 PDT
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/
Comment 13 User image Mugros 2005-10-18 01:43:21 PDT
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.
Comment 14 User image Jochen 2005-10-25 11:58:22 PDT
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. 
Comment 15 User image Ria Klaassen (not reading all bugmail) 2006-03-16 06:49:11 PST
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.
Comment 16 User image Simon Bünzli 2007-08-04 19:07:54 PDT
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?
Comment 17 User image David Baron :dbaron: ⌚️UTC-8 2007-08-27 15:31:01 PDT
Why is this in Core rather than Firefox?
Comment 18 User image Philip Chee 2007-08-27 18:00:21 PDT
> Why is this in Core rather than Firefox?
See Comment #14
Comment 19 User image David Baron :dbaron: ⌚️UTC-8 2007-08-28 16:56:05 PDT
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.
Comment 20 User image Dão Gottwald [:dao] 2007-10-02 08:47:28 PDT
Created attachment 283199 [details] [diff] [review]
workaround

With these hacks I can't reproduce the bug.

David, would you suggest a different / better fix?
Comment 21 User image Philip Chee 2007-10-02 08:58:54 PDT
> With these hacks I can't reproduce the bug.

Shouldn't these be either in /toolkit/themes/ or in xul.css?
Comment 22 User image David Baron :dbaron: ⌚️UTC-8 2007-10-02 09:17:58 PDT
Why did you need overflow-x: hidden.  That creates a bunch of extra frames to make things scrollable.
Comment 23 User image Dão Gottwald [:dao] 2007-10-02 09:25:41 PDT
(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?
Comment 24 User image Dão Gottwald [:dao] 2007-10-12 06:36:42 PDT
*** Bug 399142 has been marked as a duplicate of this bug. ***
Comment 25 User image Mike Connor [:mconnor] 2007-11-10 09:32:22 PST
David, any suggestions here?
Comment 26 User image Reed Loden [:reed] (use needinfo?) 2007-11-13 14:45:31 PST
*** Bug 403666 has been marked as a duplicate of this bug. ***
Comment 27 User image Martijn Wargers [:mwargers] 2007-11-21 05:53:33 PST
Is this related to bug 204743?
Comment 28 User image Dão Gottwald [:dao] 2007-11-21 06:03:47 PST
Yes.
Comment 29 User image Dão Gottwald [:dao] 2007-12-12 14:15:11 PST
Created attachment 292852 [details] [diff] [review]
workaround v2

mainPopupSet triggers the bug, too.
Comment 30 User image Dão Gottwald [:dao] 2007-12-18 09:09:14 PST
*** Bug 408628 has been marked as a duplicate of this bug. ***
Comment 31 User image Reed Loden [:reed] (use needinfo?) 2008-01-12 04:30:58 PST
*** Bug 412063 has been marked as a duplicate of this bug. ***
Comment 32 User image Reed Loden [:reed] (use needinfo?) 2008-01-15 18:07:30 PST
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
Comment 33 User image David Baron :dbaron: ⌚️UTC-8 2008-01-15 21:51:40 PST
This really could use a regression test.  It's been fixed in the past, and regressed at least once, if not more than once.
Comment 34 User image Ria Klaassen (not reading all bugmail) 2008-01-16 10:19:25 PST
#FindToolbar {
 overflow-x: hidden;
is causing a dot in the find bar here.
Comment 35 User image Masahiro YAMADA 2008-01-18 02:15:51 PST
I think, same fix is needed for global/content/viewSource.css.
Comment 36 User image Masahiro YAMADA 2008-01-18 02:27:34 PST
Created attachment 297723 [details] [diff] [review]
Workaround for View Source rv.1.0
Comment 37 User image Dão Gottwald [:dao] 2008-01-18 02:40:33 PST
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.
Comment 38 User image Masahiro YAMADA 2008-01-18 02:48:42 PST
(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).
Comment 39 User image Dão Gottwald [:dao] 2008-01-18 02:54:10 PST
(In reply to comment #38)
Yes, it does look like a caret bug. Any valuable information should be added to bug 412646, though.
Comment 40 User image Masahiro YAMADA 2008-01-18 03:04:35 PST
(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 ?
Comment 41 User image Dão Gottwald [:dao] 2008-01-18 03:15:41 PST
(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 42 User image Masahiro YAMADA 2008-01-18 03:32:27 PST
Comment on attachment 297723 [details] [diff] [review]
Workaround for View Source rv.1.0

I'll wait until Bug 412646 is fixed.
Comment 43 User image Dão Gottwald [:dao] 2008-05-23 11:08:49 PDT
*** Bug 435231 has been marked as a duplicate of this bug. ***
Comment 44 User image Dão Gottwald [:dao] 2008-07-30 03:11:55 PDT
*** Bug 392410 has been marked as a duplicate of this bug. ***
Comment 45 User image Dão Gottwald [:dao] 2008-07-30 03:24:06 PDT
*** Bug 391358 has been marked as a duplicate of this bug. ***
Comment 46 User image Masahiro YAMADA 2009-02-12 07:53:58 PST
Fx3.2pre seems to have same problem.
I filed it as bug 478222.

Note You need to log in before you can comment on or make changes to this bug.