content is rendered outside the window if width is reduced

RESOLVED FIXED in Firefox 3 beta3

Status

()

Firefox
General
P3
major
RESOLVED FIXED
12 years ago
8 years ago

People

(Reporter: Mugros, Assigned: dao)

Tracking

(Depends on: 1 bug, {regression})

Trunk
Firefox 3 beta3
regression
Points:
---
Dependency tree / graph
Bug Flags:
blocking-firefox3 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [see comment #7 and #16 for alternative StR], URL)

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

12 years ago
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.
(Reporter)

Updated

12 years ago
Version: unspecified → Trunk
(Reporter)

Comment 1

12 years ago
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.

Updated

12 years ago
Component: General → Layout
Keywords: regression
Product: Firefox → Core
QA Contact: general → layout

Comment 5

12 years ago
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
Flags: blocking1.8rc1?

Updated

12 years ago
Keywords: qawanted

Comment 8

12 years ago
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.
(Reporter)

Comment 9

12 years ago
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

12 years ago
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

12 years ago
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

12 years ago
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/
Flags: blocking1.8rc1?
(Reporter)

Comment 13

12 years ago
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

12 years ago
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.
Depends on: 328040

Comment 16

10 years ago
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?
Flags: blocking1.9?
Whiteboard: [see comment #7 and #16 for alternative StR]
Why is this in Core rather than Firefox?

Comment 18

10 years ago
> 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.
Component: Layout → General
Flags: blocking1.9?
Product: Core → Firefox
QA Contact: layout → general
Flags: blocking-firefox3?

Updated

10 years ago
Flags: blocking-firefox3? → blocking-firefox3+

Updated

10 years ago
Target Milestone: --- → Firefox 3 M10
(Assignee)

Comment 20

10 years ago
Created attachment 283199 [details] [diff] [review]
workaround

With these hacks I can't reproduce the bug.

David, would you suggest a different / better fix?
Assignee: nobody → dao
Status: NEW → ASSIGNED
Attachment #283199 - Flags: review?(mconnor)

Comment 21

10 years ago
> 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.
(Assignee)

Comment 23

10 years ago
(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?
(Assignee)

Updated

10 years ago
Duplicate of this bug: 399142
(Assignee)

Updated

10 years ago
OS: Windows XP → All
Hardware: PC → All

Updated

10 years ago
Target Milestone: Firefox 3 M10 → Firefox 3 M11
David, any suggestions here?
Priority: -- → P4
Duplicate of this bug: 403666
Is this related to bug 204743?
(Assignee)

Comment 28

10 years ago
Yes.
Depends on: 204743
Keywords: qawanted
(Assignee)

Comment 29

10 years ago
Created attachment 292852 [details] [diff] [review]
workaround v2

mainPopupSet triggers the bug, too.
Attachment #283199 - Attachment is obsolete: true
Attachment #292852 - Flags: review?(mconnor)
Attachment #283199 - Flags: review?(mconnor)
(Assignee)

Updated

10 years ago
Duplicate of this bug: 408628
(Assignee)

Updated

10 years ago
Blocks: 395980
Duplicate of this bug: 412063

Updated

10 years ago
Attachment #292852 - Flags: review?(mconnor) → review+
Keywords: checkin-needed

Updated

10 years ago
Priority: P4 → P3
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
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
This really could use a regression test.  It's been fixed in the past, and regressed at least once, if not more than once.
Flags: in-testsuite?
#FindToolbar {
 overflow-x: hidden;
is causing a dot in the find bar here.
Depends on: 412646

Comment 35

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

Comment 36

10 years ago
Created attachment 297723 [details] [diff] [review]
Workaround for View Source rv.1.0
(Assignee)

Comment 37

10 years ago
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.
Attachment #297723 - Flags: review-

Comment 38

10 years ago
(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).
(Assignee)

Comment 39

10 years ago
(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

10 years ago
(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 ?
(Assignee)

Comment 41

10 years ago
(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

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

I'll wait until Bug 412646 is fixed.
Attachment #297723 - Attachment is obsolete: true
Depends on: 425374
(Assignee)

Updated

9 years ago
Duplicate of this bug: 435231
Depends on: 435652
No longer depends on: 435652
(Assignee)

Updated

9 years ago
Duplicate of this bug: 392410
(Assignee)

Updated

9 years ago
Duplicate of this bug: 391358

Comment 46

8 years ago
Fx3.2pre seems to have same problem.
I filed it as bug 478222.
You need to log in before you can comment on or make changes to this bug.