182874 - Box with "display" set later is rendered in front of others

Status: RESOLVED WORKSFORME

(Core :: Web Painting, defect)

Description

[HARUNAGA Hirotoshi]

Box which is specified "style.display" later by JavaScript is rendered
in front of other boxes.

Steps;
See the testcase.
http://bugzilla.mozilla.gr.jp/attachment.cgi?id=1385&action=view

Actual result:
The image is displayed in front of the text because 'image'.style.display
is specified later than 'text'.style.display.

Expected result:
The text should be displayed in front of the image regardless of the
order of "style.display".
Win IE and Mac IE do so.

Note:
http://www.w3.org/TR/REC-CSS2/visuren.html#q30
  Boxes with the same stack level in a stacking context are stacked
  bottom-to-top according to document tree order.

Confirming with 2002112800/FreeBSD and 2002112907-MachO/MacOS X.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I can reproduce with 2002112908-trunk/WinXP.

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This seems like a view system problem.  When things work correctly, the view
child list (as shown by "Dump Views" in Viewer) is in the reverse of document
order, but when things are broken it's in document order.  So it seems we depend
on the view child list being in reverse document order, but reframing some
things can break that.

Comment 3

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

OK, the obvious fix is to change nsHTMLContainerFrame::CreateViewForFrame, so
that it finds the view for the next frame in document order and inserts the new
frame before it.

But we don't keep the frame tree in document order, partly because we have the
special child lists.

Do you know of any mechanism that we already use for checking the document order
from layout?

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

WFM on trunk.
this bug was fixed by bug 317375?

-> WFM