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

RESOLVED DUPLICATE of bug 724978

Status

()

RESOLVED DUPLICATE of bug 724978
7 years ago
7 years ago

People

(Reporter: martin, Unassigned)

Tracking

({regression})

11 Branch
x86
All
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

7 years ago
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

7 years ago
Created attachment 606256 [details]
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.

Updated

7 years ago
Component: Untriaged → Layout
Keywords: regression
OS: Mac OS X → All
Product: Firefox → Core
QA Contact: untriaged → layout

Updated

7 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
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?
Blocks: 718516
tracking-firefox12: --- → ?
tracking-firefox13: --- → ?
tracking-firefox14: --- → ?
Depends on: 724978
[Triage Comment]
Boris can you give an idea of the risks involved in the solutions you propose?
tracking-firefox12: ? → +
tracking-firefox13: ? → +
tracking-firefox14: ? → +

Comment 4

7 years ago
Boris, Ehsan as per #3, which option should we tackle here?
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

7 years ago
(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

7 years ago
I'd be more comfortable with us fixing bug 724978 instead of hacking the frame construction stuff.
Created attachment 609524 [details]
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.
The spec probably doesn't say, but needs to.
If we fix bug 724978 in the obvious way, we won't paginate such abs-pos children. I think that's fine.

Comment 11

7 years ago
(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.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
No longer depends on: 724978
Resolution: --- → DUPLICATE
Duplicate of bug: 724978

Updated

7 years ago
tracking-firefox12: + → ---
tracking-firefox13: + → ---
tracking-firefox14: + → ---
You need to log in before you can comment on or make changes to this bug.