351238 - position: relative and something else screws up frame order

Status: RESOLVED WORKSFORME

(Core :: Layout: Positioned, defect)

Description

[James Ross]

This bug will be useless until I've worked out what CSS is needed to reproduce, so bear with me. The result of the bug is that the XUL elements render in completely the wrong order.

http://localhost/temp/silver/xul/tab_position_relative.xul

This does not currently show the bug, as I've not figured out the key cause. It will be updated as and when I find out more.

The key issue is that as a tab is selected, it is given position: relative and some other CSS effects. This is when its position jumps (or would). Each element only jumps once, the first time it is selected. The resultant ordering is a bit weird, but seems to be something like this:
  1  3  5  7  2  4  6  8

When I find the layout test app and make it work, I'll see if I can dump some frame lists, but it likely still wont mean much until I figure out the triggering items.

Comment 1

[James Ross]

Attachment: Example before-and-after picture

This is a before-and-after picture of a standard tab strip. All I did to cause the re-order was click each tab in turn. This affects all normal tab strips, but not the tabbrowser's - I have no idea why (maybe that'll make more sense after I reproduce it standalone).

Comment 2

[James Ross]

Whops, correct URL from comment 0 is:

http://twpol.dyndns.org:82/temp/silver/xul/tab_position_relative.xul

Comment 3

[James Ross]

The following two attachments are the dumped frame tree for the following testcase when affected by the CSS in my local build:

http://twpol.dyndns.org:82/temp/silver/xul/tab_position_relative_real.xul

Comment 4

[James Ross]

Attachment: Frame tree before

Comment 5

[James Ross]

Attachment: Frame tree after

Comment 6

[Eli Friedman]

Probably works on trunk because we no longer create views for position: relative elements.  Try retesting?

Comment 7

[James Ross]

The example seems to work on trunk now, but doesn't that just mean anything that does still create a view will still be broken? Or are views history? (Want bug#s.)

Comment 8

[Eli Friedman]

The bug in question here is bug 371536.  The remove views bug is bug 337801.

With that fix (and another fix to not require views for opacity), views are a lot less frequent; there's iframes, object frames, children of deck frames, anything with overflow: auto or hidden, popups, titlebars, sliders, and splitters.  (I think that's everything.)

That said, I'm not completely sure what fixed your bug; it might also have been a frame construction fix sometime in the last 6 months. It's hard to tell without seeing the code.

Comment 9

[Markus Stange [:mstange]]

I also had a problem with position:relative and XUL frame order (in bug 471325), and that has been fixed by bug 307394.
Let's resolve this.