Closed Bug 60499 Opened 25 years ago Closed 23 years ago

[FIX POS]Fixed-Position containing block ignores scrollbars

Categories

(Core :: Layout, defect, P1)

Product:
Core
Component:
Layout
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 130002
Milestone:
Future

People

(Reporter: CatamountJack, Assigned: attinasi)

References

(
URL
)

Details

(Whiteboard: ask CSS WG?)

Fixed-Position elements are not aligned correctly in the browser. For example, when setting the right-side position of a block element (right: 1em), the element will overlap any scroll bars on the page. In the above URL (using the default stylesheet), the menu is positioned 2em from the right side, but appears only 1em inside the scroll bar. This also applies to elements with a specified distance from the bottom or when the page is small enough that the element exceeds the page length. If I understand correctly, these elements must be children of the body (area where a page is rendered) and not the viewport (which includes the scrollbars).
--> over to stylesystem
Component: Browser-General → Style System
really reassigning. sorry for the SPAM.
Assignee: asa → pierre
QA Contact: doronr → chrisd
could you attach a simplified testcase?
Based on CSS2 9.1.1 and 10.1 (which say that fixed positioned elements *are* positioned relative to the viewport), I'd say our current behavior is correct, but I'm not sure if it should be that way.
Assignee: pierre → buster
Component: Style System → Layout
Summary: Fixed-Position Elements Not Aligned Correctly (Incorrect Inheritance) → [FIX POS]Fixed-Position containing block ignores scrollbars
Whiteboard: ask CSS WG?
Does the viewport contain the scrollbars? Or are the scrollbars outside the viewport? (And what _should_ it be?)
Something made me think the viewport contained the scrollbars, but now I can't find it anymore...
I'm not sure what stance the spec takes (if any). However, I think the scrollbar *should* be considered to be outside the viewport and I hope CSS3 will define it this way. If the scrollbar was inside the viewport it would be impossible * to make a box to fit exactly the space between the right edge of the sidebar and the left edge of the scrollbar * to make left and right margins appear equally wide (unless you could assume the width of the scrollbar to be universally constant and you always knew whether your page was displayed with a scrollbar). I can't come up with any good reason why the scrollbar should be considered to be inside the viewport.
Status: UNCONFIRMED → RESOLVED
Closed: 25 years ago
Resolution: --- → WONTFIX
Marking WONTFIX. Our Behavoir is correct and if CSS3 is decided to include scrollbars inside the viewport well we will cross the bridge if and when we have to come to it. Marking WONTFIX in the mean time.
I'd rather leave this open. I'm not so sure our behavior is correct according to CSS2, and I don't think it makes that much sense in many cases.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
setting bug status to New.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Netscape's standard compliance QA team reorganised itself once again, so taking remaining non-tables style bugs. Sorry about the spam. I tried to get this done directly at the database level, but apparently that is "not easy because of the shadow db", "plus it screws up the audit trail", so no can do...
QA Contact: chrisd → ian
*** Bug 64085 has been marked as a duplicate of this bug. ***
Moving to m1.0.1 and reassigning to attinasi.
Assignee: buster → attinasi
Target Milestone: --- → mozilla1.0.1
a testcase site: http://joachim.borup.com/pics/
Moving Mozilla 1.01 bugs to 'future' milestone with priority P1 I will be pulling bugs from 'future' milestones when scheduling later work.
Priority: P3 → P1
Target Milestone: mozilla1.0.1 → Future
So... how is this bug different from bug 130002? I should note that the site listed in the URL field does not exhibit the problem described anymore -- the fixed div is correctly positioned with respect to the scrollbar.....
*** This bug has been marked as a duplicate of 130002 ***
Status: NEW → RESOLVED
Closed: 25 years ago → 23 years ago
Resolution: --- → DUPLICATE
Marking a bug as a dup of one filed 18 months later isn't really fair on the reporter, guys...
Can't recall *ever* seeing a bug marked as a dupe of one filed after it, what's the deal? If it was fixed shouldn't it have been marked so?
Brett, the bug it was marked a duplicate of is the one with the patch and reviews... my apologies for not finding this bug when I searched before filing that one and attaching the patch. In general, bugs should be dupped to the one with more relevant information and progress, which is _usually_ the older one.... And if the patch in the other bug had not had reviews yet when this one got marked a duplicate, I would just have reopened this one, then dupped the other to it and moved the patch over.
You need to log in before you can comment on or make changes to this bug.