Closed
Bug 23806
Opened 25 years ago
Closed 25 years ago
no borders on absolutely positioned, overflow:scroll divs
Categories
(Core :: XUL, defect, P3)
Tracking
()
VERIFIED
FIXED
M18
People
(Reporter: jrohlf, Assigned: eric)
References
Details
(Keywords: css2, Whiteboard: absolute/fixed position bug)
Attachments
(2 files)
M12:
The following does not display a red border unless the position:absolute
is removed.
<html>
<body>
<div id="div0" style="overflow:scroll; position:absolute; background-color:
#000080; width:100; height:100; border: ridge red 4">
</div>
</body>
</html>
|
||
Updated•25 years ago
|
Assignee: vidur → attinasi
|
|
||
Comment 1•25 years ago
|
||
It looks like a Style issue: the new guy will look into it.
|
|
||
Comment 2•25 years ago
|
||
If I use non-GFX ScrollFrame for this by spoofing the if(IsGfx) check in
nsCSSFrameConstructor::BeginBuildingScrollFrame() then it works fine. I'll get
back to this one later.
|
||
Comment 3•25 years ago
|
||
|
|
||
Comment 4•25 years ago
|
||
The problem is more generic than described: it also happens if you remove the
"overflow:scroll". It looks like borders are never drawn around absolutely
positionned elements, but I haven't done enough testing to confirm it.
Style seems correct: the position is set to 'absolute', all the border attributes
seem ok.
Frame construction and Layout seems correct: if you dump the frames, you can see
that the GfxScroll frame has a height/width of 108 pixels (or 1620 twips on the
Mac), which means that the border was included in the frame construction.
Could it be a rendering problem? Something like clipping the PlaceHolder frame
instead of the out-of-flow frame when drawing the border?
|
|
||
Comment 5•25 years ago
|
||
I get a border when the overflow:scroll is removed... it still is looking like a
scrollframe problem to me. Again, it works fine if we use native scrollbars,
suggesting further that it is a GfxScrollFrame problem.
Status: NEW → ASSIGNED
|
|
||
Comment 6•25 years ago
|
||
The problem is that the view is bound to the ScrollPortFrame, and the Scrollport
Frame does not resolve the style (and has the wrong bounds). Either the view
needs to be bound to the GfxScrollFrame (the parent of the ScrollPortFrame) or
the ScrollPortFrame needs to utilize the GfxScrollFrame's style and bounds in
its Paint method. I have tried the latter and it causes the border to paint,
however the size of the border is incorrect. I need to find out which is the
correct path: change the frame that the view is bound to or leave the view bound
to the ScrollPortFrame and fix the Paint to use the GfxScrollFrame's style and
size (to include the scrollbars, of course).
|
|
||
Updated•25 years ago
|
Target Milestone: M16
This bug is also true for the 'overflow: auto' style. In case it helps finding
the fix: this has been broken since M12, everything worked fine in M11.
Another example demonstrating this bug is on http://capsi.cx/browser.html. The
main and sidebar DIV's have no border where the others do. This page also shows
M11's correct rendering.
|
|
||
Comment 8•25 years ago
|
||
Eric, this appears to be a GfxScrollBar-related problem. If I disable GFX
Scrollbars in the Viewer it works correctly. I spent some time tracing down the
problem (see my previous comments) but I don't know where to go wih this since I
am not very familiar with the way views interact with the scrollport. Can you
please look into it?
To reiterate, the style appears to be resolved correctly, and it works fine with
native scrollbars. Thanks. Also, I'll attach another (simpler) testcase.
Assignee: attinasi → evaughan
Status: ASSIGNED → NEW
Component: DOM Level 2 → XP Toolkit/Widgets: XUL
|
|
||
Comment 9•25 years ago
|
||
|
||
Comment 10•25 years ago
|
||
Mass-moving all M16 non-feature bugs to M17, which we still consider to be
part of beta2
Target Milestone: M16 → M17
|
Assignee | |
Comment 11•25 years ago
|
||
targeting
Status: NEW → ASSIGNED
Whiteboard: absolute/fixed position bug
Target Milestone: M17 → M18
|
|
Assignee | |
Comment 12•25 years ago
|
||
fixed
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
|
||
Comment 13•25 years ago
|
||
As per meeting with ChrisD yesterday, taking QA.
QA Contact: vidur → py8ieh=bugzilla
|
|
||
Comment 14•24 years ago
|
||
VERIFIED FIXED with Windows 2000 and Linux Commercial builds 20000090808
using http://bugzilla.mozilla.org/showattachment.cgi?attach_id=7276 .
Status: RESOLVED → VERIFIED
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: ian → xptoolkit.widgets
You need to log in
before you can comment on or make changes to this bug.
Description
•