403048 - Crash [@ CheckForTrailingTextFrameRecursive] with focusing and position: absolute with caret browsing enabled

Status: RESOLVED FIXED

Description

[Martijn Wargers (zombie)]

Attachment: testcase

See testcase, which crashes when you have caret browsing enabled in current trunk build.

I haven't looked for a regression range (have to go now). Might be useful if someone could find out. Probably a recent regression.

http://crash-stats.mozilla.com/report/index/f601dce6-8e26-11dc-8e65-001a4bd46e84
0  	CheckForTrailingTextFrameRecursive  	 mozilla/layout/base/nsCaret.cpp:623
1 	AdjustCaretFrameForLineEnd 	mozilla/layout/base/nsCaret.cpp:647
2 	nsCaret::GetCaretFrameForNodeOffset(nsIContent*, int, nsFrameSelection::HINT, unsigned char, nsIFrame**, int*) 	mozilla/layout/base/nsCaret.cpp:690
3 	nsCaret::DrawAtPositionWithHint(nsIDOMNode*, int, nsFrameSelection::HINT, unsigned char, int) 	mozilla/layout/base/nsCaret.cpp:570
4 	nsCaret::DrawCaret(int) 	mozilla/layout/base/nsCaret.cpp:1020
5 	nsCaret::CaretBlinkCallback(nsITimer*, void*) 	mozilla/layout/base/nsCaret.cpp:1185
6 	nsTimerImpl::Fire() 	mozilla/xpcom/threads/nsTimerImpl.cpp:400
7 	nsTimerEvent::Run() 	mozilla/xpcom/threads/nsTimerImpl.cpp:487
8 	nsThread::ProcessNextEvent(int, int*) 	mozilla/xpcom/threads/nsThread.cpp:490
9 	NS_ProcessNextEvent_P(nsIThread*, int) 	nsThreadUtils.cpp:227
10 	nsBaseAppShell::Run() 	mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:154
11 	nsAppStartup::Run() 	mozilla/toolkit/components/startup/src/nsAppStartup.cpp:170
12 	XRE_main 	mozilla/toolkit/xre/nsAppRunner.cpp:3142
13 	main 	mozilla/browser/app/nsBrowserApp.cpp:153
14 	WinMain 	mozilla/browser/app/nsBrowserApp.cpp:166
15 	__tmainCRTStartup 	crtexe.c:589
16 	BaseProcessStart

Comment 1

[Steve England [:stevee]]

Works: 20071107_1904_firefox-3.0b2pre.en-US.win32
Crash: 20071107_2009_firefox-3.0b2pre.en-US.win32

Checkins to module PhoenixTinderbox between 2007-11-07 19:04 and 2007-11-07 20:08 : 
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1194491040&maxdate=1194494939

Comment 2

[Martijn Wargers (zombie)]

Ok, thanks, I guess it's a regression from bug 336408.

Comment 3

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

Probably the same as bug 403060.

Comment 4

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

Attachment: fix

Here's the fix for this nasty regression.

The main issue is to gracefully handle cases where the line is not found. A secondary issue is that we shouldn't search for any old block ancestor, we should only search up through eLineParticipants. We don't want to look up through a table, for example.

Comment 5

[Blake Kaplan (:mrbkap) (inactive, use needinfo)]

Comment on attachment 287900 [details] [diff] [review]
fix

Same nit about { on its own line applies here too.

Comment 6

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

Attachment: better patch

Slight improvement on the last patch --- don't convert the result for FindLineFor to nsLineBox* right away, since if we're at end_lines() (i.e., not found) that causes an assertion.

Comment 8

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

Checked in

Comment 9

[Mats Palmgren]

https://hg.mozilla.org/integration/mozilla-inbound/rev/a36ecd20889e

Comment 10

[Gregory Szorc [:gps]]

https://hg.mozilla.org/mozilla-central/rev/a36ecd20889e