Closed
Bug 205566
Opened 22 years ago
Closed 20 years ago
Vertical Window Resizing Cuts Off Component/Status/Scrollbars
Categories
(Core Graveyard :: GFX, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: 73kbq4e02, Assigned: kmcclusk)
References
Details
(Keywords: regression)
Attachments
(3 files)
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.
Comment 1•22 years ago
|
||
Yup, I see it, too, with Phoenix build 20030511, WinXP.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•22 years ago
|
||
This is worse in 1.4b, now the first started window acts like this.
Updated•22 years ago
|
Severity: trivial → normal
Updated•22 years ago
|
Keywords: regression
Reporter | ||
Comment 3•22 years ago
|
||
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.
Reporter | ||
Comment 4•22 years ago
|
||
...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.
Reporter | ||
Comment 5•22 years ago
|
||
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.
Reporter | ||
Comment 6•22 years ago
|
||
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.
Reporter | ||
Comment 7•22 years ago
|
||
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
Reporter | ||
Comment 8•22 years ago
|
||
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...
Reporter | ||
Comment 9•21 years ago
|
||
(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
Comment 11•21 years ago
|
||
I have this problem with all windows in Firebird 0.7.
Reporter | ||
Comment 12•21 years ago
|
||
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?
Comment 13•21 years ago
|
||
*** Bug 242131 has been marked as a duplicate of this bug. ***
Comment 14•21 years ago
|
||
*** Bug 208995 has been marked as a duplicate of this bug. ***
Comment 15•21 years ago
|
||
*** Bug 206652 has been marked as a duplicate of this bug. ***
Comment 16•21 years ago
|
||
*** Bug 244844 has been marked as a duplicate of this bug. ***
Comment 17•21 years ago
|
||
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
Comment 18•20 years ago
|
||
This worksforme now, build 20041012, Windows XP. Can anyone reproduce this bug? If not, we should close it.
Comment 19•20 years ago
|
||
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).
Comment 20•20 years ago
|
||
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.
Comment 21•20 years ago
|
||
WFM based on comments, please reopen if you can reproduce with a nightly trunk build.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Comment 22•20 years ago
|
||
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).
Comment 23•20 years ago
|
||
(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.
Comment 24•20 years ago
|
||
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.
Reporter | ||
Comment 25•20 years ago
|
||
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]
Reporter | ||
Comment 26•19 years ago
|
||
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]
Updated•16 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•