Closed Bug 1542441 Opened 2 years ago Closed 2 years ago

Assertion failure: mFloats.ContainsFrame(nif)


(Core :: Layout, defect, P3)




Tracking Status
firefox-esr60 --- wontfix
firefox66 --- wontfix
firefox67 --- wontfix
firefox68 --- fixed


(Reporter: violet.bugreport, Assigned: mats)


(Keywords: assertion, testcase)


(3 files, 1 obsolete file)

Attached file testcase.html

Open the testcase to see the assertion failure.

Let |F| be an nsBlockFrame with float |f| in its pushed float list,
let |F1| be the prev-in-flow of |F|, let |f2| be the prev-prev-in-flow
of |f| which is inside |F1|.

If at this point, |F1| restarts a reflow without the next-in-flow of
|F| having the chance to reflow, and the restarted reflow makes |f2|
overflow w.r.t |F1|. Then |nif| will still be inside the pushed float
list of |F|. The original assertion is incorrect in this sense.

Attached file frame trees

Here's the relevant frames before / after the ASSERTION.
So, if we just update the assertion as suggested we end
up with a PushedFloatsList float that doesn't have
the NS_FRAME_IS_PUSHED_FLOAT bit set. (My gut feeling
is that this frame tree is wrong. Maybe we should move
these to mFloats too?)

(I've highlighted the PUSHED_FLOAT bit in the state.)

Assignee: nobody → violet.bugreport
Priority: -- → P3

Gentle ping... In case the patch update was missed....

Flags: needinfo?(mats)

I think pushing the existing float continuations forward
might be a better approach (i.e. moving them from mFloats
to the PushedFloat list). Removing and inserting frames
into a frame list is O(1). Like so:
I think that should satisfy the invariants we have regarding
pushed floats.

Flags: needinfo?(mats)
Pushed by
When we pull in floats from a prev-in-flow then move any next-in-flows of those that we own to our PushedFloat list.  r=dholbert
Assignee: violet.bugreport → mats
Flags: in-testsuite+
Keywords: assertion, testcase
OS: Unspecified → All
Hardware: Unspecified → All
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
Attachment #9056291 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.