736072 - FF Won't render position:absolute elements when the parent has -moz-column-count set

Status: RESOLVED DUPLICATE of bug 724978

(Core :: Layout, defect)

Description

[Martin Koistinen]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20100101 Firefox/11.0
Build ID: 20120312181643

Steps to reproduce:

Updated FF to v11.  This used to work fine in previous versions.

See: http://jsfiddle.net/n3Ncx/ for a clear example of the issue.


Actual results:

Elements where are positioned absolutely whose relative parent has -moz-column-count set will disappear.


Expected results:

As it has done in v10 and in other browsers, Firefox should render the position:absolute elements accordingly.

Comment 1

[Alice0775 White]

Attachment: standalone reporter's sample html

I can confirm on Firefox 11.0 to 14.0a1.

Regression window(m-i)
Works:
http://hg.mozilla.org/integration/mozilla-inbound/rev/87a5ed480992
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120210 Firefox/13.0a1 ID:20120210070814
Fails:
http://hg.mozilla.org/integration/mozilla-inbound/rev/053d3cc103cb
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120209 Firefox/13.0a1 ID:20120210090714
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=87a5ed480992&tochange=053d3cc103cb


Triggered by:
053d3cc103cb	Scott Johnson — Bug 718516: Replace call of FinishReflowWithAbsoluteFrames() with FinishAndStoreOverflow() for nsColumnSetFrame to prevent crash. [r=ehsan]

Bug 718516 also landed on Firefox11 & 12.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Er, yes.  This is bad.  Bug 724978 never got fixed, so right now we're parenting the abspos frames to the columnset but not actually laying them out or anything, as far as I can tell.  That's broken, and is a regression from Fx10...

We need to either fix bug 724978 or change the frame constructor code that deals with abspos kids of a relpos columnset to behave more like they did before Ehsan's changes, right?

I'm a little confused as to why we didn't get test failures for this.  Or was that what the "disable failing test" bit in bug 718516 was about?

Comment 3

[Lukas Blakk [:lsblakk] use ?needinfo]

[Triage Comment]
Boris can you give an idea of the risks involved in the solutions you propose?

Comment 4

[JP Rosevear [:jpr]]

Boris, Ehsan as per #3, which option should we tackle here?

Comment 5

[Boris Zbarsky [:bzbarsky]]

I wasn't cced...  Sorry about that.

Both courses of action are probably medium-risk, in my estimation.  I suspect that fixing bug 724978 is less risky than trying to hack around the problem in frame construction, but someone who understands the overflow container stuff would probably be better able to judge how difficult (and hence risky) that's likely to be.  roc?  fantasai?

Comment 6

[(no longer active)]

(In reply to Boris Zbarsky (:bz) from comment #2)
> I'm a little confused as to why we didn't get test failures for this.  Or
> was that what the "disable failing test" bit in bug 718516 was about?

It was, I believe.

Comment 7

[(no longer active)]

I'd be more comfortable with us fixing bug 724978 instead of hacking the frame construction stuff.

Comment 8

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

Attachment: testcase

One question is whether abs-pos children of an abs-pos container with columns are laid out in the columns (and subject to pagination) or not.

Before FF regressed, we paginated them. Webkit doesn't. I'm not sure what IE10 does.

Comment 9

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

The spec probably doesn't say, but needs to.

Comment 10

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

If we fix bug 724978 in the obvious way, we won't paginate such abs-pos children. I think that's fine.

Comment 11

[(no longer active)]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #10)
> If we fix bug 724978 in the obvious way, we won't paginate such abs-pos
> children. I think that's fine.

I submitted a patch over there which does that.  It should basically take us back to the Firefox 10 behavior.  We should file a new bug when we figure out what we need to do about comment 8.

There really isn't much to be done here besides bug 724978, so I'm duping this and I'll move over the tracking flags.