Closed Bug 51163 Opened 24 years ago Closed 24 years ago

Width of vertical scrollbar ignored until window is resized (causing page to be too wide)

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: burnus, Assigned: eric)

References

(
URL
)

Details

(Keywords: regression, Whiteboard: [nsbeta3+]) 

Mozilla/2000-09-01-21 renders too wide due to ignoring the width of the
scrollbar.
Goto this URL, you will see that a (unneccessary) scollbar appears on the bottom
of that page, which lets you scroll a tiny bit to the right. This is though not
enough, some (few) letters are hidden by the vertical scrollbar and there should
be also a thin widespace on the right (= margin).

Expected: There shouldn't be a horizontal scrollbar (it isn't necessary) and the
width should be smaller, taking account of the width of the (needed) vertical
scollbar.

This worked before and is valid XHTML 1.0/CSS 2.0.
Mozilla renders *every* page too wide on my system.   2000090110
Looks like there is no reflow after the vertical scrollbar is added, causing an
unnecessary horizontal scrollbar.
Severity: major → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
http://www.slashdot.org
http://www.freshmeat.net
Both now have an erronous vertical area in the page, the width of a scrollbar.
Is this related to bug 50940?
*** Bug 51215 has been marked as a duplicate of this bug. ***
Comments from dupe bug 51215:

URL: http://www.mozilla.org/docs/

User-Agent: Mozilla/5.0 (X11; U; SunOS 5.7 sun4u; en-US; m18) Gecko/20000901
BuildID:    2000090109

When I visit a new URL, the text window will sometimes
be a bit too wide, even without any WIDTH stuff.
So there will be a scrollbar at the bottom.
When I resize the browser a bit (either smaller
or wider), the text window gets correct width
and the bottom scrollbare disappears.

Reproducible: Sometimes
Steps to Reproduce:
1. Visit the specified URL.
2. Look.
3. Resize.

Actual Results:  Step 2: Scrollbar at the bottom.

Expected Results:  No scrollbar.
R.K.Aa :    Yes, I think the slashdot problem is directly because of this bug.  
 If you manually resize the window slightly smaller, as described by Diego, the 
problem area on slashdot disappears along with the horizontal scrollbar.
at freshmeat, the page is initially layed out too wide, but it's first when the
images start loading (small icons under submitted stories) - that the page
"compensate" and the white vertical (erronous) stripe appears. (And remains -
till a reflow is forced.)
Notice, however, that the black boxes with icons (underneath each app) remains
with wrong size - they used to have same width as the story-boxes, but are now
slightly narrower, visible on right side.

I still think this smells like a dup of bug 50940..
bug 51194 is similar to this bug.
*** Bug 51512 has been marked as a duplicate of this bug. ***
After doing a reflow manually, I don't see any problems with Freshmeat.   The 
black bars with the icons are the right width for me.

(to force a reflow, I click on View -> My Sidebar twice)
*** Bug 51524 has been marked as a duplicate of this bug. ***
Re-assigning 5 bugs to Harish from Clayton's bug list.  Please triage.  Thanks!
Assignee: clayton → harishd
*** Bug 51198 has been marked as a duplicate of this bug. ***
bug 51198 has some more test cases.  This seems to be a common problem with a 
lot of pages, I'm adding some keywords.  IMHO, this would have to be fixed for a 
Netscape 6 final release, if not before - too many sites are impacted.  Also, in 
embedded situations, the user may not be able to resize the window to force a 
fix.
Keywords: 4xp, correctness
*** Bug 51194 has been marked as a duplicate of this bug. ***
Changing summary and marking as mostfreq and regression.  Should this 
be 'major' because it happens on so many webpages?

Before this regression happened, did the image on www.dmoz.org move around when 
the page was loaded, or would it start out in the correct location?  (see bug 
51194, duplicate of this bug)
Keywords: mostfreq, regression
Summary: Renders too wide due to ignoring the width of scrollbars → Width of vertical scrollbar ignored until window is resized
Summary: Width of vertical scrollbar ignored until window is resized → Width of vertical scrollbar ignored until window is resized (causing page to be too wide)
*** Bug 51789 has been marked as a duplicate of this bug. ***
nominating for beta3, it's a mostfreq and really really really annoying.
Keywords: nsbeta3
*** Bug 51784 has been marked as a duplicate of this bug. ***
Triaging Clayton's list:

Sounds like Eric vaughan's area. Eric, could you please take a look at this. 
Thanx.
Assignee: harishd → evaughan
Based on Linux build of ftp.mozilla.org, this regression occured between the
builds of 2000-08-31-08-M18 and 2000-08-31-21-M18.
*** Bug 51811 has been marked as a duplicate of this bug. ***
evaughan did check into nsBoxFrame and nsBoxToBlockAdaptor in that time frame.

Suspicious checkins I can find in the relevant time period:

* evaughan's fix for bug 44571
* karnaze's fix for bug 27529 and bug 18955 (although I know karnaze runs lots
of automated regression tests that would probably catch this)
*** Bug 51846 has been marked as a duplicate of this bug. ***
nsbeta3+, since is is already fixed as side effect of another bug.
Whiteboard: [nsbeta3+]
Target Milestone: --- → M18
fixed
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Verifying fix w/ linux, CVS from 090817. Thanks.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.