Closed Bug 424238 Opened 12 years ago Closed 12 years ago

[FIX]Crash when clicking in empty contentEditable BODY element; [@ GetRangeForFrame]


(Core :: DOM: Editor, defect, critical)

Not set





(Reporter: tom, Assigned: bzbarsky)



(Keywords: crash, regression, verified1.9.0.7)

Crash Data


(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4) Gecko/2008030714 Firefox/3.0b4
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b4) Gecko/2008030317 Firefox/3.0b4

A crash occurs when the user tries to edit the content of an empty BODY element, even through contentEditable is true.

I don't have access to the entire stack trace, but the specific function in which the crash occurs is GetRangeForFrame.

Reproducible: Always

Steps to Reproduce:
1. Open the example.
2. Click inside the IFRAME.

Actual Results:  

Expected Results:  
Focus should appear inside the IFRAME, and the user should be able to edit the content.

I have seen this on all platforms, though I have not found a repro path on windows. However, the included repro crashes both OSX and linux.
Instructions included within test case.
Update: You have to click on the lower-half of the IFRAME in the test-case for the crash to occur.
no crash with Firefox 3 Beta4 on windows.
Please run Firefox in the Firefox safemode, let it crash and submit the crash report. After that run Firefox again and type about:crashes and post the ID from the crash report.
Keywords: crash
Crash confirmed with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008032404 Minefield/3.0b5pre
OS: Linux → All
Summary: Crash in GetRangeForFrame when clicking in empty contentEditable BODY element → Crash when clicking in empty contentEditable BODY element; in GetRangeForFrame(nsIFrame*)
Version: unspecified → Trunk
WFM with 2007102504
crash with 2007102604

Probably bug 395340 (no access) or bug 321402.
Signature	GetRangeForFrame(nsIFrame*)
UUID	911d0378-fa34-11dc-aedc-001a4bd43ed6
Time	2008-03-24 23:27:20-07:00
Uptime	68
Product	Firefox
Version	3.0b5pre
Build ID	2008032404
OS	Linux
OS Version	0.0.0 Linux 2.6.22-3-k7 #1 SMP Sun Feb 10 21:04:14 UTC 2008 i686 GNU/Linux
CPU	x86
CPU Info	AuthenticAMD family 1 model 44 stepping 2
Crash Reason	SIGSEGV
Crash Address	0xb75d910c
Crashing Thread
Frame 	Signature 	Source
0 	GetRangeForFrame(nsIFrame*) 	mozilla/layout/generic/nsFrame.cpp:2310
1 	nsIFrame::GetContentOffsetsFromPoint(nsPoint, int) 	mozilla/layout/generic/nsFrame.cpp:2705
2 	nsFrame::HandlePress(nsPresContext*, nsGUIEvent*, nsEventStatus*) 	mozilla/layout/generic/nsFrame.cpp:1810
3 	nsFrame::HandleEvent(nsPresContext*, nsGUIEvent*, nsEventStatus*) 	mozilla/layout/generic/nsFrame.cpp:1516
4 	nsPresShellEventCB::HandleEvent(nsEventChainPostVisitor&) 	mozilla/layout/base/nsPresShell.cpp:1254
5 	nsEventTargetChainItem::HandleEventTargetChain(nsEventChainPostVisitor&, unsigned int, nsDispatchingCallback*) 	mozilla/content/events/src/nsEventDispatcher.cpp:309
6 	nsEventDispatcher::Dispatch(nsISupports*, nsPresContext*, nsEvent*, nsIDOMEvent*, nsEventStatus*, nsDispatchingCallback*) 	mozilla/content/events/src/nsEventDispatcher.cpp:479
7 	PresShell::HandleEventInternal(nsEvent*, nsIView*, nsEventStatus*) 	mozilla/layout/base/nsPresShell.cpp:5945
8 	PresShell::HandlePositionedEvent(nsIView*, nsIFrame*, nsGUIEvent*, nsEventStatus*) 	mozilla/layout/base/nsPresShell.cpp:5833
9 	PresShell::HandleEvent(nsIView*, nsGUIEvent*, nsEventStatus*) 	mozilla/layout/base/nsPresShell.cpp:5686
10 	nsViewManager::HandleEvent(nsView*, nsPoint, nsGUIEvent*, int) 	mozilla/view/src/nsViewManager.cpp:1388
11 	nsViewManager::DispatchEvent(nsGUIEvent*, nsEventStatus*) 	mozilla/view/src/nsViewManager.cpp:1343
12 	HandleEvent(nsGUIEvent*) 	mozilla/view/src/nsView.cpp:168
13 	nsCommonWidget::DispatchEvent(nsGUIEvent*, nsEventStatus&) 	mozilla/widget/src/gtk2/nsCommonWidget.cpp:158
14 	nsWindow::OnButtonPressEvent(_GtkWidget*, _GdkEventButton*) 	mozilla/widget/src/gtk2/nsWindow.cpp:2146
15 	button_press_event_cb(_GtkWidget*, _GdkEventButton*) 	mozilla/widget/src/gtk2/nsWindow.cpp:4636
28 	nsAppShell::ProcessNextNativeEvent(int) 	mozilla/widget/src/gtk2/nsAppShell.cpp:144
29 	nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal*, int, unsigned int) 	mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:146
30 	nsThread::ProcessNextEvent(int, int*) 	mozilla/xpcom/threads/nsThread.cpp:497
31 	NS_ProcessNextEvent_P(nsIThread*, int) 	nsThreadUtils.cpp:227
32 	nsBaseAppShell::Run() 	mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:164
33 	nsAppStartup::Run() 	mozilla/toolkit/components/startup/src/nsAppStartup.cpp:181
34 	XRE_main 	mozilla/toolkit/xre/nsAppRunner.cpp:3154
35 	main 	mozilla/browser/app/nsBrowserApp.cpp:158
Component: General → Editor
Depends on: 395340
Product: Firefox → Core
QA Contact: general → editor
Summary: Crash when clicking in empty contentEditable BODY element; in GetRangeForFrame(nsIFrame*) → Crash when clicking in empty contentEditable BODY element; [@ GetRangeForFrame]
Ever confirmed: true
Flags: blocking1.9?
Keywords: regression
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5pre) Gecko/2008032504 Minefield/3.0b5pre ID:2008032504

Confirmed with today's Mac nightly:

Given the age of this bug and the lack of dups I'm not sure how severe it is.  Taking off the list for now - PeterV/Bz/Dbaron please re-nom with rational if that's wrong.
Flags: blocking1.9? → blocking1.9-
It basically depends on what sort of crash this is and how easy it is to trigger from content...  If it's a deleted-object crash and content can trigger it, it needs to be a somewhat high priority.  Otherwise, we should probably try to fix it in a stability release.
Flags: wanted1.9.0.x?
So I just checked, and we're doing a virtual call on a null pointer.  Not sure how much of an issue that is; suspect it's not stop-ship but is good to fix in a point release.
Boris, can you own this for a point release? If not, any suggestions?
Flags: wanted1.9.0.x? → wanted1.9.0.x+
So this is great fun.  When we load the document.written page, we create the body in the sink, call OpenBody, call NotifyAppend.  The end of the update in that NotifyAppend triggers editor init, and creation of the CreateBogusNodeIfNeeded <br> node.  However, we've incremented mInNotification so we don't update child counts during this whole procedure.  Then we double-construct frames for the <br>, later we remove it, which removes _one_ of the frames, and voila!  A frame with a content node pointer which has a null parent.

We should probably make NotifyAppend behave like FlushTags does...
Attached patch Like soSplinter Review
Assignee: nobody → bzbarsky
Attachment #334905 - Flags: superreview?(jonas)
Attachment #334905 - Flags: review?(jonas)
Summary: Crash when clicking in empty contentEditable BODY element; [@ GetRangeForFrame] → [FIX]Crash when clicking in empty contentEditable BODY element; [@ GetRangeForFrame]
Attachment #334905 - Flags: superreview?(jonas)
Attachment #334905 - Flags: superreview+
Attachment #334905 - Flags: review?(jonas)
Attachment #334905 - Flags: review+
Pushed changeset 1e368c1ce94a.

I guess I should figure out an automatic test for this...
Closed: 12 years ago
Resolution: --- → FIXED
Comment on attachment 334905 [details] [diff] [review]
Like so

Does this patch also apply to the 1.9.0 branch?
Attachment #334905 - Flags: approval1.9.0.6?
Flags: in-testsuite?
Comment on attachment 334905 [details] [diff] [review]
Like so

Guess not. if wanted on 1.9.0 request approval on an appropriate patch.
Attachment #334905 - Flags: approval1.9.0.6?
Comment on attachment 334905 [details] [diff] [review]
Like so

Er... I must have missed that question somehow.  Yes, this patch applies just fine to the 1.9.0 branch.
Attachment #334905 - Flags: approval1.9.0.6?
Comment on attachment 334905 [details] [diff] [review]
Like so

Let's get this in
Attachment #334905 - Flags: approval1.9.0.6? → approval1.9.0.7?
Attachment #334905 - Flags: approval1.9.0.7?
Attachment #334905 - Flags: approval1.9.0.7?
Blocks: 395340
No longer depends on: 395340
Attachment #334905 - Flags: approval1.9.0.7? → approval1.9.0.7+
Comment on attachment 334905 [details] [diff] [review]
Like so

Approved for, a=dveditz for release-drivers.
Fixed on 1.9.0 branch.
Keywords: fixed1.9.0.7
Flags: wanted1.8.1.x-
Verified for with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/2009021304 GranParadiso/3.0.7pre. Crashed nicely.
This is also fixed in 1.9.1 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090213 Shiretoko/3.1b3pre.
Crash Signature: [@ GetRangeForFrame]
You need to log in before you can comment on or make changes to this bug.