291222 - Abs. pos. span in document order affect rendering

Status: VERIFIED FIXED

(Core :: Web Painting, defect)

Description

[Gérard Talbot]

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

Comment 1

[Gérard Talbot]

Attachment: 2 divs helping pinpointing the cause of differential layout

Instructions:
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.

Comment 2

[Martijn Wargers (dead)]

Attachment: Testcase2

This is somewhat more minimal.
The testcase works with 2005-04-03 trunk build, fails in 2005-04-04 trunk
build:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-04-03+06%3A00%3A00&maxdate=2005-04-04+09%3A00%3A00&cvsroot=%2Fcvsroot

Comment 3

[Martijn Wargers (dead)]

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).

Comment 4

[Hermann Schwab]

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.

#DivNestedInSecondContainer
		{
		z-index: 1;

Comment 5

[Hermann Schwab]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050417

Testcase 1 regressed between BuildID 2005041719 (working) and 2005041806

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-04-17+00%3A00&maxdate=2005-04-18+07%3A00&cvsroot=%2Fcvsroot

Comment 6

[Gérard Talbot]

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 
http://www.w3.org/TR/CSS21/visuren.html#propdef-z-index
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.

Comment 7

[Boris Zbarsky [:bzbarsky]]

This looks like a pretty serious z-ordering regression (from the scrollframe
landing?)

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

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.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 181803 [details] [diff] [review]
fix

I think David's the one who knows this code, but you're right that this is
straightforward.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 181803 [details] [diff] [review]
fix

Fixes a z-ordering regression

Comment 11

[Asa Dotzler [:asa]]

Comment on attachment 181803 [details] [diff] [review]
fix

a=asa

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

checked in

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

actually marking fixed

Comment 14

[Gérard Talbot]

I VERIFIED the provided url and both testcases with Mozilla 1.8b2 build
2005042606 and marking as such.