main pane width tied to status bar (now tied to navbar) width instead of window width; vertical scrollbar disappears

NEW
Unassigned

Status

()

P3
normal
16 years ago
a year ago

People

(Reporter: dsb, Unassigned, NeedInfo)

Tracking

({regression})

Trunk
x86
Windows XP
regression
Points:
---
Dependency tree / graph
Bug Flags:
wanted-next +
blocking1.9.2 -
wanted1.9.2 -
wanted1.9.1 +
blocking1.9 -
wanted1.9 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

16 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401

It appears that the width of the main display pane is tied to the width of 
the button bar (the bar with the Back, etc., buttons, the URL text box, and
the Mozilla Logo button), instead of being tied to the width of the browser
window.  

This causes any vertical scrollbar to disappear and causes wrappable content 
to no longer wrap to fit the window width (and prevents a horizontal scrollbar
from appearing).

Reproducible: Always

Steps to Reproduce:
1.  View a web page full of text that has no minimum width, and with enough 
    content to need a vertical scroll bar.
2.  Narrow the browser window enough so that the Mozilla logo button stops
    moving to the left (assuming your dragging the right edge of the window).
3.  Narrow the window a little more.

Actual Results:  
- The text stops flowing to fit the narrowing window, and starts disappearing
  on the the right as the right edge continues to be dragged left.
- The vertical scrollbar starts disappearing.  Instead of tracking the right 
  edge and moving toward the left, it stops moving and starts disappearing as
  the right edge continues to be dragged left.
- (No horizontal scrollbar appears.)

Expected Results:  
Mozilla should have either (highest preference first):

1. kept reflowing the text and moving the vertical scroll left as the window
   was narrowed (until the width hit some hard limit)

2. added a horizontal scrollbar (if it couldn't kept narrowing the text) and
   kept moving the vertical scrollbar as the window was narrowed (until the 
   width hit some hard limit)

3. prevented the window from being narrowed beyond the point where things
   started breaking
It's tied to the status bar width, not the toolbar width.

This is a regression.

(I'd really like to change the XUL box model so we don't have to add 'min-width'
all over the place, though.)
Assignee: other → blaker
Component: Layout → XP Apps: GUI Features
Keywords: regression
QA Contact: ian → paw
Summary: main pane width tied to button bar width instead of window width; vertical scrollbar disappears → main pane width tied to status bar width instead of window width; vertical scrollbar disappears

Comment 2

16 years ago
This is a long-standing issue with the XUL box model.  By default vertical boxes
stretch all their children horizontally to the size of the largest child.  It
would be useful to attempt to reconcile this behavior with existing CSS
specifications in order to determine what the correct behavior should be.

The correct behavior is probably to think of the boxes themselves as always
being constrained to the window width with their content simply overflowing out
of the boundaries of the box.  Then the "stretch" behavior would never stretch
boxes to be larger than the width of the window.

Comment 3

16 years ago
*** Bug 211988 has been marked as a duplicate of this bug. ***

Comment 5

16 years ago
As a consequence, small windows opened via JS without status bar may not be
properly formatted if the preference "Allow Scripts to ... Hide the Status Bar"
is disabled.

Testcase: attachment 128158 [details] from dup bug 213296.

Comment 6

15 years ago
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20030925]

Testcase attachment 128158 [details] from comment 5 WFM with Mozilla 1.5RC2.
Bug FIXED ?-)

Updated

15 years ago
Status: UNCONFIRMED → NEW
Component: XP Apps: GUI Features → XP Toolkit/Widgets: XUL
Ever confirmed: true

Comment 7

15 years ago
Confirming bug on Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a)
Gecko/20040207

Comment 8

15 years ago
I'm not quite sure if this is quite the same thing, but if it is, here is a live
web page where this same problem shows up:
http://zebra.fh-weingarten.de/~transcode/man1/transcode.1.html

Comment 10

14 years ago
This old chestnut seems to be fixed in Deer Park Alpha 2, and the testcase in
comment 5 now works as expected

Comment 11

14 years ago
I created another bug with an additional scenario (bug 304427) that is 
unhappily not fixed in the post alpha 2 version I use (Gecko/20050801).
Please close it if it is simply a duplicate.
Thanks
*** Bug 333412 has been marked as a duplicate of this bug. ***
*** Bug 330285 has been marked as a duplicate of this bug. ***
*** Bug 304427 has been marked as a duplicate of this bug. ***
*** Bug 336569 has been marked as a duplicate of this bug. ***

Comment 16

13 years ago
Created attachment 224349 [details]
Scrollbars lost and contents truncated, both horizontally and vertically, on resizing window to lower resolution.

Comment 17

13 years ago
Comment on attachment 224349 [details]
Scrollbars lost and contents truncated, both horizontally and vertically, on resizing window to lower resolution.

This happens in version 1.5.0.4. This severly affects browser use and limits in-development page testing to higher resolutions.
*** Bug 340637 has been marked as a duplicate of this bug. ***
*** Bug 261205 has been marked as a duplicate of this bug. ***
*** Bug 341623 has been marked as a duplicate of this bug. ***
*** Bug 344518 has been marked as a duplicate of this bug. ***
*** Bug 346653 has been marked as a duplicate of this bug. ***
*** Bug 336248 has been marked as a duplicate of this bug. ***
Flags: blocking1.9?
This bug worksforme on trunk, until bug 328040 happens.  The recent dups are all duplicates of that bug, not this one.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Flags: blocking1.9? → blocking1.9-
Resolution: --- → WORKSFORME
Er, actually this might not be worksforme; I can't figure out how to test.  But the recent bugs are still bug 328040.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
*** Bug 341623 has been marked as a duplicate of this bug. ***
*** Bug 344518 has been marked as a duplicate of this bug. ***
*** Bug 336248 has been marked as a duplicate of this bug. ***
Wanted for 1.9.
Whiteboard: [wanted-1.9]
Assignee: bross2 → nobody
Status: REOPENED → NEW
QA Contact: pawyskoczka → xptoolkit.xul

Comment 30

12 years ago
This bug is here in the 2.0 release - and it does have to do with the status bar.  When the page is loading, and there is a lot of stuff in the status bar, the "Loading http://whatever.here.org/this/is/a/really/long/path" Causes the window to overflow, but when it is "Done" it reverts to normal.  If there are even more status bar icons, even "Done" causes issues.
There is an especially nasty side of this bug (pretty sure it's this one) where if the window is maximized, and the status bar is too full, the window contents (reload icon, search box, and (most annoyingly) the extra tabs/tab close button) disappear off the right side of the screen.  This is very bad, as it makes it impossible to switch to some tabs with the mouse, and to close tabs easily if you have it configured that way (Tab Mix Plus, and no, TMP is NOT the issue).
I'll add an attatchment showing this behavior.

Comment 31

12 years ago
Created attachment 244709 [details]
An image showing the overflow of the window when maximized

This shows the horizontal overflow of the window when maximized. This is with TabMixPlus (once again, NOT an issue) removing close buttons on tabs and putting in on the right, the way I like it.  Note that with the plethora of status bar extensions, I can not see my rightmost tab(s), the tab close button, the load icon, or much of the search bar.
To reproduce, get a lot of status bar extensions.  A good way to quickly bloat the statusbar is ForecastFox, with all text and label, and adding a lot of FoxClocks.  FoxyTunes detects that it is too wide, and shrinks, but you can force it to show.

Comment 32

12 years ago
Sorry for the three comments in a row, but I needed to specify my firefox version more specifically:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
After two years, this bug is still open?
*** Bug 361316 has been marked as a duplicate of this bug. ***

Comment 34

12 years ago
Similar to the report in Bug 361316.

The widths are being reported incorrectly on small popup windows (via window.open) when there's even a single extension installed in the status bar. In my test I only have the MeasureIt extension installed in the status bar.

To test, open a 150x150 window:
window.open("testpuw.htm", "asdf", "width=150,height=150,top=500,left=500,resizable=1,toolbar=no,menubar=no,scrollbars=0,location=no,directories=no");

In the popup's onload event:
alert(self.innerWidth + " " + self.outerWidth);

This case does appear to produce a 150x150 window, but the widths are being reported incorrectly. My result shows the outerWidth is probably being reported correctly (always 8px more than the set window width). The innerWidth is always 161 for any width under 161, and is correct at 161 or larger. The space taken by the extension appears to be around 40 pixels. Adding more extensions increases the innerWidth.

This appears to be in all versions including Gran Paradiso.

Comment 35

12 years ago
It's not Windows specific, I got it on Linux too. Please change OS to "All".
By the way, I can workaround this on Linux by resizing the popup by hand (Window Managers on Linux doesn't care about "noresize" stuff).

Updated

12 years ago
Duplicate of this bug: 368433

Comment 37

12 years ago
Can be fixed on a skin level by putting "overflow: hidden;"
inside "statusbar" tag style in global.css

Not sure how to fix it for all skins.

Comment 38

12 years ago
I cant believe this bug has gone on so long! 

to m_vitaly ... I cannot find the global.css file anywhere in my firefox 2.0 installation. Is this pre 2.0 specific?

Also .. more details on the problem.
1) it is caused by extensions that put themselves or icons on the status bar.
2) If "Hide status bar" is UNCHECKED in "Advanced Javascript Settings", it will cause the problem when a pop-up is displayed. since most pop-ups request hiding of the status bar, it is not a problem for the majority of people.

hope this gets fixed soon!
Duplicate of this bug: 403002

Updated

11 years ago
Blocks: 312247

Updated

11 years ago
Severity: minor → normal
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
Duplicate of this bug: 419876
Flags: wanted1.9-
Flags: wanted1.9+
Flags: wanted-next+

Updated

11 years ago
Blocks: 444268

Updated

11 years ago
Blocks: 435652
Flags: wanted1.9.1?

Updated

10 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.xul → xptoolkit.widgets
Most of the recent duplicates look like they're not actually duplicates of this bug.
Flags: wanted1.9.1? → wanted1.9.1+
Priority: -- → P3

Comment 42

10 years ago
Created attachment 366527 [details] [diff] [review]
Patch v1.0 Wallpaper over the problem.

The core bug 204743 was reported in 2003 and nobody seems to have worked on it until today. Firefox chose to wallpaper over it in Bug 312247. I suggest that we do the same until the core bug is fixed.
Assignee: nobody → philip.chee
Attachment #366527 - Flags: superreview?(neil)
Attachment #366527 - Flags: review?(neil)

Comment 43

10 years ago
Oops. Sorry wrong bug. Too many tabs.
Assignee: philip.chee → nobody

Updated

10 years ago
Attachment #366527 - Flags: superreview?(neil)
Attachment #366527 - Flags: review?(neil)

Updated

10 years ago
Blocks: 484325

Updated

10 years ago
Flags: blocking1.9.2?

Updated

10 years ago
No longer blocks: 484325
Flags: wanted1.9.2-
Flags: blocking1.9.2?
Flags: blocking1.9.2-

Updated

9 years ago
Duplicate of this bug: 260277

Updated

9 years ago
Duplicate of this bug: 554299
Duplicate of this bug: 282468
I have just found that this issue only occurs on https sites.  If i visit the same site without http, i can shrink windows down to near zero width before the vertical scrollbar dissapears.
Summary: main pane width tied to status bar width instead of window width; vertical scrollbar disappears → main pane width tied to status bar (now tied to urlbbar) width instead of window width; vertical scrollbar disappears
Summary: main pane width tied to status bar (now tied to urlbbar) width instead of window width; vertical scrollbar disappears → main pane width tied to status bar (now tied to navbar) width instead of window width; vertical scrollbar disappears
(In reply to comment #47)
> I have just found that this issue only occurs on https sites.  If i visit the
> same site without http, i can shrink windows down to near zero width before the
            ^^^^^^^^^^^^
            with http

> vertical scrollbar dissapears.
This is being triggered by displaying the identity indicator.  Setting browser.identity.ssl_domain_display to 0 avoids the issue.
Bill, this bug has always been triggered by random theme bits. It predates the SSL display in the location bar.
(In reply to comment #50)
> Bill, this bug has always been triggered by random theme bits. It predates the
> SSL display in the location bar.

I realize that.  I was just trying to update the bug with information abut the current state since I had recently duped bug 282468 to this bug and without further info it was probably not at all clear why it is the same.

I also thought that perhaps the info on what is currently triggering this might help someone else determine what is really going wrong here.

Updated

8 years ago
Duplicate of this bug: 416560

Updated

7 years ago
Duplicate of this bug: 604077

Updated

7 years ago
Duplicate of this bug: 430605
still see this issue?

I cannot reproduce on win7 using nightly build
Flags: needinfo?(reast)
Flags: needinfo?(chung808)

Comment 56

a year ago
Cannot repro using Win10 and 32-bit FF 54.0.1
I suppose that 14 years later bad things just go away   J
Flags: needinfo?(reast)
You need to log in before you can comment on or make changes to this bug.