312247 - content is rendered outside the window if width is reduced

Status: RESOLVED FIXED

(Firefox :: General, defect, P3)

Description

[Mugros]

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

[Mugros]

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

Comment 2

[Ria Klaassen (not reading all bugmail)]

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

[Ria Klaassen (not reading all bugmail)]

I see this in trunk as well.

Comment 4

[Ria Klaassen (not reading all bugmail)]

In trunk it happened between 1.9a1_2005100612 and 1.9a1_2005100619.

Comment 5

[Simon Bünzli]

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

[Peter van der Woude [:Peter6]]

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

[Peter van der Woude [:Peter6]]

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

[Tracy Walker [:tracy]]

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

[Mugros]

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

[Scott MacGregor]

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

[Simon Bünzli]

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

[Asa Dotzler [:asa]]

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

[Mugros]

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

[Jochen]

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

[Ria Klaassen (not reading all bugmail)]

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

[Simon Bünzli]

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

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Why is this in Core rather than Firefox?

Comment 18

[Philip Chee]

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

Comment 19

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

[Dão Gottwald [:dao]]

Attachment: workaround

With these hacks I can't reproduce the bug.

David, would you suggest a different / better fix?

Comment 21

[Philip Chee]

> With these hacks I can't reproduce the bug.

Shouldn't these be either in /toolkit/themes/ or in xul.css?

Comment 22

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 23

[Dão Gottwald [:dao]]

(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 25

[Mike Connor [:mconnor]]

David, any suggestions here?

Comment 27

[Martijn Wargers (dead)]

Is this related to bug 204743?

Comment 28

[Dão Gottwald [:dao]]

Yes.

Comment 29

[Dão Gottwald [:dao]]

Attachment: workaround v2

mainPopupSet triggers the bug, too.

Comment 32

[Reed Loden [:reed]]

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

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

[Ria Klaassen (not reading all bugmail)]

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

Comment 35

[Masahiro YAMADA]

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

Comment 36

[Masahiro YAMADA]

Attachment: Workaround for View Source rv.1.0

Comment 37

[Dão Gottwald [:dao]]

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

[Masahiro YAMADA]

(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

[Dão Gottwald [:dao]]

(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

[Masahiro YAMADA]

(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

[Dão Gottwald [:dao]]

(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

[Masahiro YAMADA]

Comment on attachment 297723 [details] [diff] [review]
Workaround for View Source rv.1.0

I'll wait until Bug 412646 is fixed.

Comment 46

[Masahiro YAMADA]

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