Closed Bug 2180 Opened 26 years ago Closed 25 years ago

scrollbar width not passed to layout

Categories

(Core :: Layout, defect, P2)

x86
All
defect

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: akkzilla, Assigned: rickg)

References

()

Details

On Example 0, the long line ("This line demonstrates the :first-line pseudo
element") is too wide and ends up getting drawn behind the scrollbar; apparently
the scrollbar width isn't getting passed to layout to decrease the canvas width
accordingly.
Assignee: kmcclusk → rods
Added me to cc list.  i will look into this.
Assignee: rods → michaelp
Assignee: michaelp → ramiro
i think this is somewhat bogus. the device context *does* pass back scrollbar
sizes, but they may not be entirely accurate (so layout may disagree with the
area actually occupied by the scrollbar).
Inserting Milestone info.
Setting all current Open/Normal to M4.
does this happen under win32?  I don't see any good reason why this is
happening.
QA Contact: 4137
cpratt, could you check this problems with latest build on Win32, Mac and Linux.
 Letus know what you find.  Thanks!
I'm not seeing this problem on example 0 in win32, however there is a similar
sounding problem on
   http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/htmlbodyrendering6.html
...where the inner scroll bars are being added *after* the inner width is
decided, and so horizontal scrolling is required when it shouldn't be.
BTW, I am pretty sure this bug I am seeing (reported 02/24/99 13:30 above) is
not a widget set bug but a layout bug.
Waiting for a stable seamonkey build to test this against; bear with me...
i know the scrollbar width is passed to the layout, so this is most definatly a
layout bug...
OS: Linux → All
Bug also occurs on Win98 with the first scrollable DIV of
  http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/floatgrowth.html

Changing OS from Linux to All. I believe this is probably a layout bug too.
We should probably remove the [PP] radar, as this appears to be cross platform.
Target Milestone: M4 → M5
m5
Target Milestone: M5 → M6
m6
Assignee: ramiro → kmcclusk
Kevin,

Since this bug is now an XP thing, can you take a quick look ?  It might be
bogus.  thanks.

Reassign to kmcclusk@netscape.com
Assignee: kmcclusk → rickg
Component: Widget Set → Layout
I don't see any problem in 5-19-99 10:00am build on WIN32. with Example 0.
http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/htmlbodyrendering6.html,
does display horizontal scrollbars on WIN32, so I am leaving this bug open.
I am changing to component to Layout, and reassigning the bug to a Layout person

Rick, I am reassigning to you because it looks like a layout problem.
Summary: [PP] scrollbar width not passed to layout → scrollbar width not passed to layout
Removing [PP] radar as per comments above.
Assignee: rickg → chrisd
Hey Chris. Can you please tell me if you still see this on our tier1 platforms?
Assignee: chrisd → rickg
Tested using 5/19 Apprunner on Tier 1 platforms (Win32, Win98, Win NT4.0 - Win
NT5.0 not available).

In the resource:/res/samples/test0.html test, the long line is NOT drawn beyond
the scrollbar - all platforms tested are okay

In the
http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/htmlbodyrendering6.html
test, there are scroll bars as indicated by the overflow: scroll value but they
are disabled as they should be because the BODY is sufficiently contained within
the HTML element - all platforms tested are okay

WORKSFORME.
Agreed WORKSFORME on Win98. What about other platforms?
Looks like this problem no longer exists on Linux.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Marking WORKSFORME since it appears to now work on every platform tested with
every test page tested.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.