Closed Bug 291222 Opened 19 years ago Closed 19 years ago

Abs. pos. span in document order affect rendering


(Core :: Web Painting, defect)

Not set





(Reporter: bugzilla, Assigned: roc)




(Keywords: regression, testcase, Whiteboard: CSS2 9.9.1)


(3 files)

Depending on the place where abs. pos. <span>s are located in a DHTML layer
(abs. pos. <div>), they will or will not be rendered.

I believe this is a recent regression. I've been working on doing webpages on
DHTML object model properties and just recently noticed that the words
"border-top" and "border-bottom" were not visible.

Steps to reproduce:
1- Load the URL

Actual results in Mozilla 1.8b2 build 2005042005: 
the words "border-top" and "border-bottom" are NOT readable, are NOT viewable,
are NOT highlightable/selectable; these words are with white color on black
background. These "border-top" and "border-bottom" words are abs. pos. <span>
positioned on the thick black border of a <div>.

Expected results: 
the words "border-top" and "border-bottom" should be readable, should be
viewable, should be highlightable/selectable; these words are with white color
on black background, abs. pos. on the thick black borders. I get the expected
results with Opera 8.0 final release build 7561, with Firefox 1.0.3 rv 1.7.7
build 20050414 and with MSIE 6 SV1.

Reproducible: always

XP Pro SP2 here.

Testcase (not minimized though) coming
Load this not-perfectly-reduced testcase.

In the top block box (id="FirstContainer"), you will NOT see the white words
"border-top" and "border-bottom".

In the bottom block box (id="SecondContainer"), you will see the white words
"border-top" and "border-bottom".

The only significant, relevant difference between the 2 block boxes is the
place where the abs. pos. <span>s are located, appear in the document order.

I guess it could be possible to create a more reduced testcase.

What I do not understand at all in that testcase is how come "margin-top" and
"margin-bottom" are viewable, readable, selectable/highlightable in both
container blocks: I have "played" around with the code, checked DOM inspector,
etc. and I can not understand this.
Keywords: testcase
Assignee: nobody → roc
Component: Layout: R & A Pos → Layout: View Rendering
QA Contact: layout.r-and-a-pos → ian
By the way, in builds before this regression occured I cannot select the text in
the green block with testcase2 (happens even with Mozilla1.7).
If I use z-index, I can get the spanned text visible.

Testcase 1, border top: > 0  makes it visible,  0 hides it.
z-index: 1;">border-top</span>

testcase 1, second example, inserting z-index 1 hides it, 0 makes it visible.

		z-index: 1;
attachment 181358 [details] renders the white colored "border-top" and "border-bottom" in
both <div>s in NS 6.1 (rv: 0.9.2), in NS 6.2 (rv:0.9.4), in NS 7.0 (rv: 1.0.1),
NS 7.1 (rv: 1.4), NS 7.2 (rv: 1.7.2), Firefox 1.0.3, Opera 8.0 final build 7561,
MSIE 6 SV1 but not in Safari 1.2.4 v 125.12. Safari 1.2.4 and Mozilla 1.8b2
build 2005042005 renders that testcase identically.

Per se, such browser petition does not mean much: it does not prove that there
is a bug or not. But for the edition of DHTML property pages in Gecko DOM
reference, it means the 2nd (bottom) div is more consistently rendered across
web standards compliant browsers. I will leave the page of the URL
(clientHeight.html) as it is but I will change all other similar+related DHTML
pages to use the code of the 2nd div.

I read carefully
and I believe there is a bug with current Mozilla nightly build... although I
would prefer someone more knowledgeable in this area to confirm all this.
Whiteboard: CSS2 9.9.1
This looks like a pretty serious z-ordering regression (from the scrollframe
Flags: blocking1.8b2?
OS: Windows XP → All
Attached patch fixSplinter Review
I can't remember if it's you or David who's familiar with the sorting code.

In any case, this is an easy one. If we're going to update the display
elements' "topmost" bits because the parent view is topmost and we want to
inherit its topmost-ness into the children, first sort the display elements
taking into account their current topmost-ness so that their relative ordering
is not lost.
Attachment #181803 - Flags: superreview?(bzbarsky)
Attachment #181803 - Flags: review?(bzbarsky)
Comment on attachment 181803 [details] [diff] [review]

I think David's the one who knows this code, but you're right that this is
Attachment #181803 - Flags: superreview?(bzbarsky)
Attachment #181803 - Flags: superreview+
Attachment #181803 - Flags: review?(bzbarsky)
Attachment #181803 - Flags: review+
Comment on attachment 181803 [details] [diff] [review]

Fixes a z-ordering regression
Attachment #181803 - Flags: approval1.8b2?
Comment on attachment 181803 [details] [diff] [review]

Attachment #181803 - Flags: approval1.8b2? → approval1.8b2+
actually marking fixed
Closed: 19 years ago
Resolution: --- → FIXED
I VERIFIED the provided url and both testcases with Mozilla 1.8b2 build
2005042606 and marking as such.
Flags: blocking1.8b2?
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.