Closed Bug 204743 Opened 21 years ago Closed 5 years ago

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

Categories

(Core :: XUL, defect, P3)

x86
Windows XP
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: dsb, Unassigned)

References

Details

(Keywords: regression)

Attachments

(3 files)

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
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.
*** Bug 211988 has been marked as a duplicate of this bug. ***
*** Bug 213296 has been marked as a duplicate of this bug. ***
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.
[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 ?-)
Status: UNCONFIRMED → NEW
Component: XP Apps: GUI Features → XP Toolkit/Widgets: XUL
Ever confirmed: true
Confirming bug on Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a)
Gecko/20040207
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
This isn't about web pages.  It's about the browser.
This old chestnut seems to be fixed in Deer Park Alpha 2, and the testcase in
comment 5 now works as expected
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 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
Closed: 18 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
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.
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.
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. ***
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.
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).
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.
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!
Blocks: 312247
Severity: minor → normal
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
Flags: wanted1.9-
Flags: wanted1.9+
Flags: wanted-next+
Blocks: 444268
Blocks: 435652
Flags: wanted1.9.1?
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
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)
Oops. Sorry wrong bug. Too many tabs.
Assignee: philip.chee → nobody
Attachment #366527 - Flags: superreview?(neil)
Attachment #366527 - Flags: review?(neil)
Blocks: 484325
Flags: blocking1.9.2?
No longer blocks: 484325
Flags: wanted1.9.2-
Flags: blocking1.9.2?
Flags: blocking1.9.2-
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.
still see this issue?

I cannot reproduce on win7 using nightly build
Flags: needinfo?(reast)
Flags: needinfo?(chung808)
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)

Thanks for the test

Status: NEW → RESOLVED
Closed: 18 years ago5 years ago
Flags: needinfo?(chung808)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.