Closed Bug 205566 Opened 22 years ago Closed 20 years ago

Vertical Window Resizing Cuts Off Component/Status/Scrollbars

Categories

(Core Graveyard :: GFX, defect)

Product:
Core Graveyard
Component:
GFX
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: 73kbq4e02, Assigned: kmcclusk)

References

Details

(Keywords: regression)

Attachments

(3 files)

Screenshot
(deleted), image/gif
Details
Fully-Compressed / Initial / Secondary Windows
(deleted), image/png
Details
Initial / Secondary Windows (Scrollbar Cropping)
(deleted), image/png
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425

If the browser window is resized small enough, the component toolbar, status
toolbar, and/or scrollbars (depending on what's visible at the time) will be cut
off, instead of just shrinking the actual viewing area of the browser window to
the point where it cannot be seen (which is when it should cut off the
component/status/scrollbars).

This does not happen when resizing the window horizontally - The
toolbar/bookmark buttons will get cut off if you make the window too small
horizontally, but unlike with vertical resizing, the component toolbar/status
toolbar/scrollbars won't disappear, and will only get cut off if the browser
window's size is shrunk too small to hold them.

This only affects secondary windows (either opened with the "New Window" command
or by switching profiles).  The initial window (the first one created when the
mozilla.exe process is started up), for some reason, is not affected by this
bug, and will only get cut off if the browser window's size is shrunk too small
to hold them.  All other windows will be affected, even if the original window
is closed.  Removing the mozilla.exe process and starting it up again will fix
this, but again, only for the initial window - All other windows opened during
this time (including those created when switching profiles) will still be
affected by this bug.

Reproducible: Always

Steps to Reproduce:
1. Start up Mozilla.
2. Resize this window (the initial window) vertically.
3. Open a new window (or switch to another profile).
4. Resize that window (the secondary window) vertically.

Actual Results:  
The initial window only cuts off the status/component bars if it's resized too
small to hold them, but the secondary window cuts off the status/component bars
before the viewing area is resized too small to hold them.

Expected Results:  
The first window only cuts off the status/component bars if it's resized too
small to hold them, and the secondary window should work exactly the same way.
Yup, I see it, too, with Phoenix build 20030511, WinXP.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached image Screenshot (deleted) — 
This is worse in 1.4b, now the first started window acts like this.
Severity: trivial → normal
Keywords: regression
I should've included these screenshots when posting the bug...But it completely
slipped my mind when I was typing it up (sorry about that!).  On the following
pictures, the blue border and red fill show the area the
component/status/scrollbars (which will be referred to as "bars" from now on in
my comments here, unless specified otherwise) should be taking up.

In this comment's picture, there are three windows.  From top to bottom:

1) This window is a fully-compressed window.  It shows how small the window can
be shrunk vertically before it *should* begin cutting off the bars at the
bottom of the window.

2) This is the initial window (the previous one was too, but fully-compressed,
and an example window only - This one is a *normal* initial window).

3) This is the secondary window.  Notice how there is a gap in the top of the
red area now - This is the area that the bars *should* be occupying, but
instead is cut off from the bottom a little too early.
...And in this comment's picture, I'm showing how it affects the scrollbars too
(the component/status bars *are* enabled in the second picture, but cannot be
seen, due to having been cut off as a result of shrinking the window):

1) The initial window is shown first, and it looks normal.

2) The secondary window, shown below the first, not only has the component and
status bars cut off, but also has cut off the *entire* horizontal scrollbar,
and part of the vertical scrollbar as well.
Here's what I noticed with window resizing after trying out Mozilla Firebird 0.6:
[Build Information - Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b)
Gecko/20030516 Mozilla Firebird/0.6]

1) The initial window is no longer immune to this bug - *ALL* windows are now
affected by it.  I was unable to test if switching profiles affects this, as the
option for it is not in Firebird, at least when I had tried it out.
(I doubt it would have any effect anyway, as the switched profile's window
appears to be a secondary window itself).

2) If you change to another theme, it fixes this problem for all of the windows
that are open *at the moment*.  If you open any other windows _after_ changing
themes (or if the "MozillaFirebird" process is closed and restarted), those
windows will be affected by this cropping bug until theme is changed again.
Just got Mozilla 1.4 today...
[Build Information: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4)
Gecko/20030624]

Similar to what I noticed when trying out Firebird 0.6, *ALL* windows are
affected by this bug.  Also, due to how Mozilla handles themes, changing your
theme no longer fixes this bug.
I am now changing the category for this bug from "Browser-General" to "GFX", as
it would be a more appropriate category for it to be in.

If anyone here has a system that is NOT running a Windows OS, could you check
and see if this bug exists on your OS as well?  I was just about to set the
category to "GFX: Win32", but I do not want to do so without confirming whether
or not that this bug affects non-Windows systems (which I do not have available
here)...
Component: Browser-General → GFX
This is interesting: With Mozilla 1.4, in some (rare) cases, the browser window
is somehow able to fix itself - As usual, the component/status/scrollbars
(referred to as "bars" from now on) will be cut off if the window resized too
small vertically, but if I mess around with the browser window long enough, it
somehow fixes the problem, allowing me to resize the window properly, without
cutting off any of the bars.  This only affects the current window (which stays
fixed until it is closed), and I've been unable to get it to work on any
secondary windows.

I've tried resizing the window, maximizing/minimizing the window, showing/hiding
bars of all types, and so on - Just about everything I can think of; I am at a
loss as to how (or why) this fixes itself for the window I'm using, and why it
does so at random...
(I should've done this awhile back...)

I have removed the "for New/Switched Profile Windows" portion of this bug's
description, as it no longer affects just those windows, but instead, affects
all windows.
Summary: Vertical Window Resizing Cuts Off Component/Status/Scrollbars for New/Switched Profile Windows → Vertical Window Resizing Cuts Off Component/Status/Scrollbars
--> Default owner
Assignee: general → kmcclusk
QA Contact: general → ian
I have this problem with all windows in Firebird 0.7.

It seems it's not just limited to the browser...After trying out Thunderbird 0.6
on my computer (did a clean installation and created a new profile), its windows
are also affected by this bug =(

I'd change the "Product" field to something that would fit better here (since
it's not just the browser that's affected), but I'm not sure what it should be
set to...Any suggestions?

(I've also considered changing the "Hardware" and "OS" fields as well - If you
are a non-Windows/non-PC user, could you please try reproducing the symptoms of
this bug?  I have a feeling other systems are affected, but I don't have any
other systems available to test out.)

Also, the person it's assigned to is marked as being gone - Should I reassign
this bug to someone else right now, and if so, to who?
*** Bug 242131 has been marked as a duplicate of this bug. ***
*** Bug 208995 has been marked as a duplicate of this bug. ***
*** Bug 206652 has been marked as a duplicate of this bug. ***
*** Bug 244844 has been marked as a duplicate of this bug. ***
happens on Linux too. And with all windows actually, to some degree or other.
Some mail issues are in bug 41994. Dup of bug 128198?
Similar: bug 220261
This worksforme now, build 20041012, Windows XP. Can anyone reproduce this bug?
If not, we should close it.
Works for me, too, with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.8a5) Gecko/20041013 Firefox/0.9.1+ (but not with Mozilla/5.0 (Windows; U;
Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1).
I ran the test given at bug 242131 with Mozilla 1.8a5 build 2004101405 under XP
Pro SP2 and the statusbar and horiz. scrollbar appeared: so bug 205566 seems to
be fixed. But, in that same test, innerHeight value of the secondary window was
82px which is under the security constraint of 100px and that is bug 176320.

I did not try with Firefox 0.10.1 build 20040913 because I couldn't find that build.
WFM based on comments, please reopen if you can reproduce with a nightly trunk
build.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
According to my reading of https://bugzilla.mozilla.org/bug_status.html, this
should be resolved as FIXED rather than WORKSFORME (but I can't change the
resolution).
(In reply to comment #22)
> According to my reading of https://bugzilla.mozilla.org/bug_status.html, this
> should be resolved as FIXED rather than WORKSFORME (but I can't change the
> resolution).

This is most probably a duplicate. FIXED is used when a patch has been written,
applied to the bug, and checked in. I dont see any patch on this bug.
It seems gray to me, since the WORKSFORME characterization ("All attempts at
reproducing this bug were futile") is clearly not true.  It's easily reproduced
with affected versions of the browser.  On the other hand, as José points out,
we can't really say, "A fix for this bug is checked into the tree," because we
can't point to a specific patch.

I only raised the question in case it made a difference as to whether and how
this gets verified.
Though what I'm using isn't a nightly, I want to say that I've just tried out
Firefox 1.0 RC1 (tested with my current profile, and a new one), and this bug is
still there.

[User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3)
Gecko/20041026 Firefox/1.0RC1]
I have just tried this out again, in Firefox 1.5, and I can now say that this bug appears to be fixed.

[User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 - Build ID: 2005111116]
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: