"ASSERTION: cannot call on a dirty frame not currently being reflowed" with position: fixed and overflow: scroll

RESOLVED WORKSFORME

Status

()

Core
Layout: Misc Code
RESOLVED WORKSFORME
11 years ago
8 years ago

People

(Reporter: Jesse Ruderman, Unassigned)

Tracking

(Blocks: 1 bug, {assertion, testcase})

Trunk
x86
All
assertion, testcase
Points:
---
Dependency tree / graph
Bug Flags:
wanted-next +
blocking1.9 -
wanted1.9 -
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

11 years ago
Created attachment 271330 [details]
testcase

Loading the testcase triggers:

###!!! ASSERTION: cannot call on a dirty frame not currently being reflowed: '!NS_SUBTREE_DIRTY(this) || (GetStateBits() & NS_FRAME_IN_REFLOW)', 
file mozilla/layout/generic/nsFrame.cpp, line 739

This is the same assertion as in bug 366021 and bug 369563, but this bug has a much simpler testcase.
Flags: blocking1.9?
Does the stack trace resemble either one of the other two bugs?
(Reporter)

Comment 2

11 years ago
Created attachment 271342 [details]
stack trace
(Reporter)

Updated

11 years ago
Attachment #271342 - Attachment description: testcase → stack trace
(Reporter)

Comment 3

11 years ago
The stack trace is similar to the stack trace in bug 366021.
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]

Comment 4

11 years ago
The issue here is that the child fixed-pos frame is somehow ending up on the fixed-pos frame list before the parent fixed-pos frame.  Looks like a frame construction bug.  (Note that this bug does actually have visual effects: the child fixed-pos frame isn't getting positioned in the right place.)
Component: Layout → Layout: Misc Code
QA Contact: layout → layout.misc-code
The testcases on Bug 388058 trigger this assertion as well. 
(see https://bugzilla.mozilla.org/show_bug.cgi?id=388058#c10)
OS: Mac OS X → All
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
Flags: wanted1.9-
Flags: wanted1.9+
Flags: wanted-next+
I'm still seeing this whenever I perform the steps to reproduce on OSX:

1. Go to www.lastfm.com
2. use any band in the "artistSearch" element field and click on go.
3. Notice the assertions on the resulting page.

.. with the following build ids:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090720 Minefield/3.6a1pre ID:20090720081030

and

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1pre) Gecko/20090720 Shiretoko/3.5.1pre ID:20090720080943


There's a number of bugs associated to this bug, so I'm going to update the oldest bug.

I'm talking about bug 448040 and bug 419289 as the other ones found.
(Reporter)

Comment 7

8 years ago
WFM with the testcase in comment 0, and with the steps in comment 6.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 8

8 years ago
Crashtest: http://hg.mozilla.org/mozilla-central/rev/4a4e6dea49bd
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.