Closed Bug 351292 Opened 18 years ago Closed 18 years ago

Crash [@ nsFrameIterator::GetLastChildInner] with position: fixed, position:relative and more stuff

Categories

(Core :: DOM: Selection, defect)

x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: martijn.martijn, Unassigned)

References

Details

(Keywords: crash, regression, testcase)

Crash Data

Attachments

(3 files)

See upcoming testcase, which crashes current trunk builds within 1 second after load.
In order to get the crash, you need to have caret browsing enabled.

Talkback ID: TB22874173H
nsFrameIterator::GetLastChildInner  [mozilla\layout\base\nsframetraversal.cpp, line 486]
nsFrameIterator::GetLastChild  [mozilla\layout\base\nsframetraversal.cpp, line 433]
nsFrameSelection::GetPrevNextBidiLevels  [mozilla\layout\generic\nsselection.cpp, line 1985]
nsFrameSelection::GetPrevNextBidiLevels  [mozilla\layout\generic\nsselection.cpp, line 1934]
nsCaret::GetCaretFrameForNodeOffset  [mozilla\layout\base\nscaret.cpp, line 688]
nsCaret::DrawAtPositionWithHint  [mozilla\layout\base\nscaret.cpp, line 589]
nsCaret::DrawCaret  [mozilla\layout\base\nscaret.cpp, line 988]
nsCaret::StartBlinking  [mozilla\layout\base\nscaret.cpp, line 557]
nsEventStateManager::SetContentCaretVisible  [mozilla\content\events\src\nseventstatemanager.cpp, line 5252]
nsEventStateManager::ResetBrowseWithCaret  [mozilla\content\events\src\nseventstatemanager.cpp, line 5308]
nsEventStateManager::PreHandleEvent  [mozilla\content\events\src\nseventstatemanager.cpp, line 864]
PresShell::HandleEventInternal  [mozilla\layout\base\nspresshell.cpp, line 6255]
PresShell::HandleEvent  [mozilla\layout\base\nspresshell.cpp, line 6033]
nsViewManager::HandleEvent  [mozilla\view\src\nsviewmanager.cpp, line 1665]
nsViewManager::DispatchEvent  [mozilla\view\src\nsviewmanager.cpp, line 1618]
HandleEvent  [mozilla\view\src\nsview.cpp, line 174]
nsWindow::DispatchEvent  [mozilla\widget\src\windows\nswindow.cpp, line 1102]
nsWindow::DispatchFocus  [mozilla\widget\src\windows\nswindow.cpp, line 6178]
nsWindow::ProcessMessage  [mozilla\widget\src\windows\nswindow.cpp, line 4751]
0x7ffdfc00
0x7ffdfc00
0x7ffdfc00
0x7ffdfc00
0x7ffdfc00
0x7ffdfc00
0x7ffdfc00
etc.

This regressed between 2006-08-30 and 2006-08-31, I think a regression from bug 334626.
Attached file testcase
I can't reproduce this on my Mac, neither with a latest-trunk FF build, nor with my debug Seamonkey build. The stack trace posted above is strange in that it seems to miss two frames between nsFrameSelection::GetPrevNextBidiLevels and nsFrameIterator::GetLastChildInner.

Martijn, could you try to reproduce this in a debug build, and post a stack trace containing argument values? It seems like GetLastChild gets called with a null parameter, but I'm not sure how that could happen.
Another talkback ID with a different stack: TB22862625Q
0x00000000
nsCSSFrameConstructor::FindFrameWithContent  [mozilla\layout\base\nscssframeconstructor.cpp, line 11340]
nsCSSFrameConstructor::FindPrimaryFrameFor  [mozilla\layout\base\nscssframeconstructor.cpp, line 11477]
nsFrameManager::GetPrimaryFrameFor  [mozilla\layout\base\nsframemanager.cpp, line 404]
nsTypedSelection::selectFrames  [mozilla\layout\generic\nsselection.cpp, line 5001]

I chose a very big value for the left: 1600px; in the fieldset.
Maybe that one needs to be even bigger for you because you have a bigger screen resolution? (set it to 16000 for instance)
If it doesn't crash directly, you have to press the 'Go' button, if you want to try crashing again.
I tried reducing my window width, and also pressed "go" (and tried "reload") several times, but I still couldn't crash.

This with:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060903 Minefield/3.0a1

The new stack trace seems completely unrelated. What causes you to think this is the same bug?
Attached file unreduced testcase
(In reply to comment #4)
> The new stack trace seems completely unrelated. What causes you to think this
> is the same bug?

Because I get that stacktrace with that testcase, or maybe with a slightly less reduced testcase.
I have now attached the unreduced testcase, do you see the crash with that one?
No, not crashing with this one either, although in a debug build I am getting lots of assertions.
Smontagu did some debugging for me on Windows (he couldn't reproduce the problem on Linux), and it seems that upon reaching GetLastChildInner, when aFrame is the fieldset's nsAreaFrame, aFrame's first child is a deleted frame.

Given this evidence, I tend to think that the root problem is not a result of the fix to bug 334626.
This is worksforme with a 2006-12-07 build and with current trunk build.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@ nsFrameIterator::GetLastChildInner]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: