Open Bug 55368 Opened 25 years ago Updated 7 years ago

Right and bottom scrollbars disappear! (Regression)

Categories

(SeaMonkey :: Themes, defect)

Product:
SeaMonkey
Component:
Themes
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: eric, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(7 files)

patch that fixed the problem for me in the classic skin
5.46 KB, patch
Details | Diff | Splinter Review
works in classic, statusbar still problem in modern & blue
9.11 KB, patch
Details | Diff | Splinter Review
latest patch
4.14 KB, patch
Details | Diff | Splinter Review
Scrollbars still pushed out in RC2
17.69 KB, image/png
Details
patch to fix status bar problem
1.94 KB, patch
jag+mozilla
: review+
bryner
: superreview+
asa
: approval1.5b+
Details | Diff | Splinter Review
Width of window is ok, scrollbar is visible
210.73 KB, image/jpeg
Details
Width of window is shrinked, scrollbar is invisible
201.49 KB, image/jpeg
Details
Ok this is a simple 1 - 2 line css fix. I have made it my self at least 3 times and it has been undone everytime the skin has been mucked with. I'm tired of fixing it. Ben please do the honors. :) To reproduce: to make the right scrollbar disappear 1) Open a page 2) resize the window's width to get smaller and smaller 3) eventually the right scrollbars will be pushed off the window. This happens because the toolbar and status bar hit their min widths and prevent the content are from shrinking. To fix set a min width of 1px on the toolbox and status bar. to make the bottom scrollbar disappear 1) Open page 2) open sidebar 3) shrink height very small 4) the bottom scrollbar will be pushed off the window to fix just set a min height of 1px on the horizontal splitter. And 1px width on the vertical splitter.
Is this related to bug 20318 ?
Reporter : Do you confirm that this is a dup of bug 20318? If not, then please post the differences you see with bug 20318. Thank you, Fabian.
Yeah, sure. It's the same as bug 20318. As Eric says, it's always some broken or missing style rule, and it will always return after its exorcism.
This doesn't belong in Skinability, but I'm not sure where it does.
Component: Skinability → XP Apps: GUI Features
QA Contact: blakeross → sairuh
*** Bug 20318 has been marked as a duplicate of this bug. ***
Blocks: 41994
nav triage team: accepting. its a skin issue - so over to hangas.
Assignee: ben → hangas
Keywords: nsbeta1
skin qa->patty or blake.
QA Contact: sairuh → pmac
*** Bug 65580 has been marked as a duplicate of this bug. ***
Reporter, Does this occur in Classic or Modern?
It occurs in both, and in both cases it looks like the problem is with the menubar. (It would be nice if they'd wrap. Is there a bug on that somewhere?)
I tried to fix the problem in modern and blue by doing the same thing, but it didn't work there. There are also some fixes for a few other CSS errors in that patch. evaughan: "//" does not begin a comment in CSS.
*** Bug 68762 has been marked as a duplicate of this bug. ***
The duplicate bug says that this is also a problem in mailnews compose.
I'm running Solaris build 2001021209. It happens in the browse window at about 400 pixels wide Mail compose at about 635 pixels wide Mail reading at about 660 pixels wide
Reporter, this bug is not belonged to themes since it occurs in both classic and skins. Please assign to another component.
I meant it occurs in both classic and modern skins. This is not a themes issue.
*** Bug 70044 has been marked as a duplicate of this bug. ***
Moving to "Themes".
Assignee: hangas → hewitt
Component: XP Apps: GUI Features → Themes
Themes Triage Team marking nsbeta1+ and 0.9
Keywords: nsbeta1 → nsbeta1+
Target Milestone: --- → mozilla0.9
Status: NEW → ASSIGNED
Shouldn't we be applying these min-widths in xul.css, not in the Themes? I think this symptom should be prevented by default.
*** Bug 70784 has been marked as a duplicate of this bug. ***
Anyway, the reason my patch didn't work / stopped working was evaughan's non-CSS comments in toolbar.css. He wrote "//" which caused the declaration marked with "DON'T DELETE" to be ignored. (I just found the omission in my CSS parser error reporting that causes that to show up as an error... it's not checked in yet though.) I'll attach another patch after testing it with all themes, although I agree it should probably move to xul.css.
sr=hewitt on the last patch.
r=andreww
OK, the problem is now fixed for the shrinking horizontally (fix checked in 2001-03-09 19:16). However, the issue with the sidebar/sidebar splitter still remains.
What exactly is the problem with the sidebar? Are you implying that the sidebar should give way to the browser when the window is resized so that the browser is not visible?
No, the problem with the sidebar is that it causes the bottom scrollbar to disappear when the window is resized to be very small vertically. (See evaughan's original comment.)
There also may be other problems in duplicates of this bug that aren't fixed (such as similar problems in mail, etc.).
As far as I can see, the horizontal scrollbar disappears when the window is small because the vertical scrollbar appears, not because of the sidebar. I think this should be mark fixed. What do you think, David?
*** Bug 17092 has been marked as a duplicate of this bug. ***
I still see problems with the sidebar splitter (related to the size of the image) and we also need to look at mail, etc.
The problem with the sidebar is only happening for me in classic. I have a fix which is in the forthcoming patch. As far as mailnews, it's ugly. Currently, neither the thread pane nor the message header have a min-width set, so the scrollbar disappears when they hit their self-determined min-width. Forthcoming patch fixes this. However, even with the patch the problem isn't 100% solved. The subject field in the expanded header is stored in a <html> element. This <html> wraps the subject if it needs to, and it doesn't seem to play well with the min-width: 1px that is set on #expandedHeaderView. Not only does it refuse to allow #expandedHeaderView to shrink, but it causes some nasty slowdown when you resize the window past the point where it can no longer wrap the subject. Try the patch and see. I'm not sure what to do about this problem, it may be a layout bug. BTW, the patch is only for classic. Modern will include the fix when I land Modern3.
Attached patch latest patch — — Splinter Review
r = andreww
Just checked in the patch above. Navigator is now fixed in both themes. Mail is now 90% fixed in both themes. The problem remains with the html block not allowing it's ancestral box to get smaller when it can no longer word-wrap. Me thinks that's a separate bug - the min-width: 1px is there, it's just not being obeyed. Fixed.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Marking verified on windows 98 (2001-04-25-09-Mtrunk).
Status: RESOLVED → VERIFIED
I have bug 83503 open for the mailnews cases where the expanded mail headers have a really wide min width -- if your mail message is addressed to someone with a long address and/or it has attachments, this is still ugly.
Is this bug back even for the very basic browser window cases? At least in this screenshot both the vertical and the horizontal scrollbar are already partly "pushed out" of the window. Making the window even smaller makes the respective one disappear completely. This is in 2002051006 (RC2) on Win2k, Classic theme obviously. To comment #31: don't think so, here no vertical scrollbar appears. It is shown all the time in my example from the very beginning. But still the horizontal scrollbar (and before that the status bar) disappear. Even if about:blank is shown in the browser window and all sidebar tabs are hidden, the status bar is getting hidden when the window gets vertically too small to display the sidebar splitter toggle grippy (grippy-horizontal-before.gif) completely.
The horizontal scrollbar is hidden behind the sidebar when I resize the navigator window with 2002111704-trunk/Linux, both in Modern and Classic. Reopening.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Looks like the sidebar grippy needs a min-height of 1px.
In Mozilla 1.4 20030624 Win32, when I first launch Mozilla, the scrollbars can be scrolled off the Navigator window by resizing the window. However if I use File->New Navigator Window (Ctrl-N), the problem is fixed on the newly-opened window. I use the prefbar which is what is causing my toolbar to be so wide. I tried to add the patches on this bug to my CSS files, but they still don't seem to work on the first instance of Mozilla, only subsequently-opened windows.
Attachment #129239 - Flags: review?(jaggernaut) → review+
Attachment #129239 - Flags: superreview?(bryner) → superreview+
Comment on attachment 129239 [details] [diff] [review] patch to fix status bar problem a=asa (on behalf of drivers) for checkin to 1.5beta
Attachment #129239 - Flags: approval1.5b? → approval1.5b+
should this be resolved?
No, there are other problems still to fix.
anyone still having problems with this bug?
*** Bug 251941 has been marked as a duplicate of this bug. ***
(In reply to comment #50) > *** Bug 251941 has been marked as a duplicate of this bug. *** But it is still not a dup.
*** Bug 280487 has been marked as a duplicate of this bug. ***
This bug happens all the time in firefox v2.0.0.1 for me. The problem is exagerated the more icon there are on the status bar at the bottom f the browser window. Enabling an add-in like forcastfox where there are lots of icons stps the scrollbar from ever apearing when the loaded page is thinner than the width of all the icons on the status bar.
Assignee: hewitt → nobody
Status: REOPENED → NEW
OS: Windows NT → All
QA Contact: pmac → themes
Hardware: PC → All
Product: Core → SeaMonkey
Priority: P3 → --
Target Milestone: mozilla0.9 → ---
Hi. Problem appear again in Firefox 10.0.2.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: