[@ nsTextEditorKeyListener::KeyPress] crash typing string to search for in page (find as you type) right after page is loaded; or in MailNews/emailCompose

VERIFIED FIXED in mozilla1.9alpha1

Status

()

Core
Editor
--
critical
VERIFIED FIXED
12 years ago
12 years ago

People

(Reporter: myk, Assigned: neil@parkwaycc.co.uk)

Tracking

(5 keywords)

Trunk
mozilla1.9alpha1
crash, fixed1.7.13, fixed1.8.1, regression, verified1.8.0.2
Points:
---
Bug Flags:
blocking1.7.13 +
blocking-aviary1.0.8 +
blocking1.8.0.2 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [rft-dl], crash signature)

Attachments

(2 attachments)

(Reporter)

Description

12 years ago
In today's nightly, when I load a page and then start typing a string to search for, Firefox crashes after I type the first character.  I can reproduce consistently, and it seems to happen on arbitrary pages (reproduced on a b.m.o bug list and the bouncer admin page).

My Firefox is:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051209 Firefox/1.6a1

Note that if I click in the page after loading it and then type the string to search, Firefox doesn't crash.  The crash only happens if typing to search is the very next thing I do after loading the page.
WFM on 1208 windows trunk build, so it's either a recent regression or Linux only I suppose.
(is there a linux machine available in the office that I can test this on?)
Component: Search → Find Toolbar / FastFind
Looks like this may have been caused by bug 303713.

TB12788714A:

Stack Signature	 nsTextEditorKeyListener::KeyPress() ae1116ed
Product ID	FirefoxTrunk
Build ID	2005120904
Trigger Time	2005-12-09 13:25:53.0
Platform	LinuxIntel
Operating System	Linux 2.6.14-1.1637_FC4
Module	firefox-bin + (00584bcd)
URL visited	http://download.mozilla.org/admin/
Trigger Reason	SIGSEGV: Segmentation Fault: (signal 11)
Source File, Line No.	mozilla/editor/libeditor/text/nsEditorEventListeners.cpp, line 154
Stack Trace 	
nsTextEditorKeyListener::KeyPress()  [mozilla/editor/libeditor/text/nsEditorEventListeners.cpp, line 154]
DispatchToInterface(nsIDOMEvent*, nsIDOMEventListener*, unsigned (nsIDOMEventListener::*)()  [mozilla/content/events/src/nsEventListenerManager.cpp, line 143]
nsEventListenerManager::HandleEvent()  [mozilla/content/events/src/nsEventListenerManager.cpp, line 1034]
nsGenericElement::HandleDOMEvent()  [mozilla/content/base/src/nsGenericElement.cpp, line 2196]
nsHTMLInputElement::HandleDOMEvent()  [mozilla/content/html/content/src/nsHTMLInputElement.cpp, line 1369]
nsEventStateManager::DispatchNewEvent()  [mozilla/content/events/src/nsEventStateManager.cpp, line 848]
nsEventListenerManager::DispatchEvent()  [mozilla/content/events/src/nsEventListenerManager.cpp, line 412]
nsDOMEventRTTearoff::DispatchEvent()  [mozilla/content/base/src/nsGenericElement.cpp, line 848]
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)()  [mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2138]
XPC_WN_CallMethod()  [mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1444]
js_Invoke()  [mozilla/js/src/jsinterp.c, line 1211]
js_Interpret()  [mozilla/js/src/jsinterp.c, line 3757]
js_Invoke()  [mozilla/js/src/jsinterp.c, line 1231]
nsXPCWrappedJSClass::CallMethod()  [mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1376]
nsXPCWrappedJS::CallMethod()  [mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 466]
PrepareAndDispatch()  [mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_gcc_x86_unix.cpp, line 100]
nsEventListenerManager::HandleEventSubType()  [mozilla/content/events/src/nsEventListenerManager.cpp, line 1685]
nsEventListenerManager::HandleEvent()  [mozilla/content/events/src/nsEventListenerManager.cpp, line 1034]
nsXULElement::HandleDOMEvent()  [mozilla/content/xul/content/src/nsXULElement.cpp, line 1931]
nsXULElement::HandleDOMEvent()  [mozilla/content/xul/content/src/nsXULElement.cpp, line 848]
nsXULElement::HandleDOMEvent()  [mozilla/content/xul/content/src/nsXULElement.cpp, line 848]
nsXULElement::HandleDOMEvent()  [mozilla/content/xul/content/src/nsXULElement.cpp, line 848]
nsXULElement::HandleDOMEvent()  [mozilla/content/xul/content/src/nsXULElement.cpp, line 848]
nsXULElement::HandleChromeEvent()  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2590]
nsGlobalWindow::HandleDOMEvent()  [mozilla/dom/src/base/nsGlobalWindow.cpp, line 848]
nsGlobalWindow::HandleDOMEvent()  [mozilla/dom/src/base/nsGlobalWindow.cpp, line 265]
nsDocument::HandleDOMEvent()  [mozilla/content/base/src/nsDocument.cpp, line 4237]
nsGenericElement::HandleDOMEvent()  [mozilla/content/base/src/nsGenericElement.cpp, line 2227]
PresShell::HandleEventInternal()  [mozilla/layout/base/nsPresShell.cpp, line 848]
PresShell::HandleEvent()  [mozilla/layout/base/nsPresShell.cpp, line 5862]
nsViewManager::HandleEvent()  [mozilla/view/src/nsViewManager.cpp, line 848]
nsViewManager::DispatchEvent()  [mozilla/view/src/nsViewManager.cpp, line 2242]
HandleEvent()  [mozilla/view/src/nsView.cpp, line 251]
nsCommonWidget::DispatchEvent()  [mozilla/widget/src/gtk2/nsCommonWidget.cpp, line 219]
nsWindow::OnKeyPressEvent()  [mozilla/widget/src/gtk2/nsWindow.cpp, line 1801]
key_press_event_cb()  [mozilla/widget/src/gtk2/nsWindow.cpp, line 3916]
Assignee: nobody → mozeditor
Component: Find Toolbar / FastFind → Editor
Product: Firefox → Core
QA Contact: search
Summary: crash typing string to search for in page right after page is loaded → crash typing string to search for in page right after page is loaded [@ nsTextEditorKeyListener::KeyPress]

Comment 3

12 years ago
I see this in Camino also, so -> All/All.
OS: Linux → All
Hardware: PC → All
Keywords: crash, regression

Updated

12 years ago
Keywords: crash, regression

Updated

12 years ago
Keywords: crash, regression
(Assignee)

Comment 4

12 years ago
Created attachment 205433 [details] [diff] [review]
Possible patch

If this was a regression from bug 303713 then this might or might not fix it.
Summary: crash typing string to search for in page right after page is loaded [@ nsTextEditorKeyListener::KeyPress] → crash typing string to search for in page (find as you type) right after page is loaded [@ nsTextEditorKeyListener::KeyPress]

Comment 5

12 years ago
Hmm; I just re-read the subject, and I haven't been crashing in FAYT, but rather when trying to type in a textarea on a particular page. The stack trace is almost identical, but I figured I should post this comment just in case.
*** Bug 319791 has been marked as a duplicate of this bug. ***
Blocks: 303713
Status: NEW → ASSIGNED
Summary: crash typing string to search for in page (find as you type) right after page is loaded [@ nsTextEditorKeyListener::KeyPress] → [@ nsTextEditorKeyListener::KeyPress] crash typing string to search for in page (find as you type) right after page is loaded; or in MailNews/emailCompose
Oops, I did not mean to Assign this bug :-/
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20051210 Firefox/1.6a1 ID:2005121005
Seeing this too, trying to use find.
- TB12809630H
- TB12809667M
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051210 Firefox/1.6a1
- TB12825487X

Comment 10

12 years ago
*** Bug 319832 has been marked as a duplicate of this bug. ***

Comment 11

12 years ago
Bug 319832 has been marked as a duplicate of this bug.

I am adding two additional Talkback crash ID's related to bug 319832:

TB12827182H
TB12827212X

Due to the number of crashes relating to bug 319832, I have decided not to use this on the web sites listed in Bug 319832.

Comment 12

12 years ago
We've already got enough talkback IDs to last us a lifetime here. No more are needed.

Updated

12 years ago
Attachment #205433 - Flags: superreview?(dbaron)
Attachment #205433 - Flags: review?(dbaron)
Attachment #205433 - Flags: superreview?(dbaron)
Attachment #205433 - Flags: superreview+
Attachment #205433 - Flags: review?(dbaron)
Attachment #205433 - Flags: review+
(Assignee)

Updated

12 years ago
Assignee: mozeditor → neil.parkwaycc.co.uk
Status: ASSIGNED → NEW
(Assignee)

Comment 13

12 years ago
Fix checked in to the trunk.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
(Assignee)

Comment 14

12 years ago
Comment on attachment 205433 [details] [diff] [review]
Possible patch

Need this on the same branches as bug 303713.
Attachment #205433 - Flags: approval1.8.0.1?
Attachment #205433 - Flags: approval1.7.13?
Attachment #205433 - Flags: approval-aviary1.0.8?

Comment 15

12 years ago
The fix that was checked in:
http://tinderbox.mozilla.org/bonsai/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2005-12-11%2001:26&maxdate=2005-12-11%2001:26
There's reports of this still happening on trunk (2005121105), even after the checkin.

TB12842788X, TB12842768Z, TB12843474K, TB12843393Q
(In reply to comment #16)
> There's reports of this still happening on trunk (2005121105), even after the
> checkin.

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051211 SeaMonkey/1.5a] (nightly) (W98SE)

Not fixed confirmed: TB12848241G.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 18

12 years ago
Wevah, could you see if you could create a minimized testcase with a <textarea> that causes the crash?

Comment 19

12 years ago
the crash happens when you type in the serch box relly fast

Comment 20

12 years ago
Typing in wikipedia, placing the cursor in the main editing textbox causes typing to appear in the edit summary textbox, and vice=versa
(Assignee)

Comment 21

12 years ago
So confusingly you can't specify NS_PRIV_EVENT_UNTRUSTED_PERMITTED when removing an event listener because nsEventListenerManager.cpp only masks the flag on the listener struct before performing the compare, so if aFlags includes that flag then the removal never happens. If this is intended behaviour, then I obviously need to exclude that flag in the call to remove the event listener, but I feel that looks ugly.
(Assignee)

Comment 22

12 years ago
Created attachment 205611 [details] [diff] [review]
Fix RemoveEventListener
Attachment #205611 - Flags: superreview?(jst)
Attachment #205611 - Flags: review?(jst)
*** Bug 319966 has been marked as a duplicate of this bug. ***
Comment on attachment 205611 [details] [diff] [review]
Fix RemoveEventListener

>Index: nsEventListenerManager.cpp

>@@ -806,6 +806,7 @@ nsEventListenerManager::RemoveEventListener
> 
>   PRBool listenerRemoved = PR_FALSE;

Nit: Here and a few lines below, this var is useless as it is currently.
*** Bug 320213 has been marked as a duplicate of this bug. ***
Comment on attachment 205611 [details] [diff] [review]
Fix RemoveEventListener

r+sr=jst, and yeah, remove listenerRemoved while you're at it.
Attachment #205611 - Flags: superreview?(jst)
Attachment #205611 - Flags: superreview+
Attachment #205611 - Flags: review?(jst)
Attachment #205611 - Flags: review+
(Assignee)

Comment 27

12 years ago
Fix checked in. Fingers crossed!
Status: REOPENED → RESOLVED
Last Resolved: 12 years ago12 years ago
Resolution: --- → FIXED
(Assignee)

Comment 28

12 years ago
Comment on attachment 205611 [details] [diff] [review]
Fix RemoveEventListener

Ditto from previous patch.
Attachment #205611 - Flags: approval1.8.0.1?
Attachment #205611 - Flags: approval1.7.13?
Attachment #205611 - Flags: approval-aviary1.0.8?
*** Bug 320365 has been marked as a duplicate of this bug. ***

Comment 30

12 years ago
*** Bug 320366 has been marked as a duplicate of this bug. ***
Talkback shows the last crash with MozillaOrgThunderbirdTrunkWin322005121407, which makes sense.  The fix landed post-landing of that build.

Thunderbird trunk version 1.6a1 (20051216)

SeaMonkey 1.5a;Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051216 Mozilla/1.0

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051216 Firefox/1.6a1

This is now Verified FIXED.

http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=nsTextEditorKeyListener%3A%3AKeyPress&vendor=MozillaOrg&product=All&platform=All&buildid=&sdate=&stime=&edate=&etime=&sortby=build
Status: RESOLVED → VERIFIED
(In reply to comment #28)
> (From update of attachment 205611 [details] [diff] [review] [edit])
> Ditto from previous patch.

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8) Gecko/20051217 SeaMonkey/1.0b] (nightly) (W98SE)

While having theses patches on the branch(es) would seem fine,
I wanted to mention that I don't get (duplicated) bug 319791 with SMv1.0b nightlies.
Target Milestone: --- → mozilla1.9alpha

Comment 33

12 years ago
i think that BeOS dup (https://bugzilla.mozilla.org/show_bug.cgi?id=320213) is gone with last patch. At least SeaMonkey build from 2005-12-15 trunk sources don't crash on BeOS anymore

Comment 34

12 years ago
confirming Sergei's comments.  last patch fixed Firefox bug under BeOS.
See bug 303713 comment 26.

/be

Comment 36

12 years ago
*** Bug 321113 has been marked as a duplicate of this bug. ***

Comment 37

12 years ago
*** Bug 321194 has been marked as a duplicate of this bug. ***
Comment on attachment 205611 [details] [diff] [review]
Fix RemoveEventListener

a=dveditz for 1.8/1.8.0.1 branches. Please add the fixed1.8.1 and fixed1.8.0.1 keywords when checked in.
Attachment #205611 - Flags: approval1.8.1+
Attachment #205611 - Flags: approval1.8.0.1?
Attachment #205611 - Flags: approval1.8.0.1+
Comment on attachment 205433 [details] [diff] [review]
Possible patch

a=dveditz for 1.8/1.8.0.1 branches. Please add the fixed1.8.1 and fixed1.8.0.1 keywords when checked in.
Attachment #205433 - Flags: approval1.8.1+
Attachment #205433 - Flags: approval1.8.0.1?
Attachment #205433 - Flags: approval1.8.0.1+
Comment on attachment 205433 [details] [diff] [review]
Possible patch

Missed 1.8.0.1 code freeze -> 1.8.0.2
Attachment #205433 - Flags: approval1.8.0.2+
Attachment #205433 - Flags: approval1.8.0.1-
Attachment #205433 - Flags: approval1.8.0.1+
Attachment #205611 - Flags: approval1.8.0.2+
Attachment #205611 - Flags: approval1.8.0.1-
Attachment #205611 - Flags: approval1.8.0.1+
(Assignee)

Comment 41

12 years ago
Fix checked into the branches (no fixed 1.8.0.2 yet?)
Keywords: fixed1.8.1
Whiteboard: fixed1.8.0.2

Updated

12 years ago
Keywords: fixed1.8.0.2
Whiteboard: fixed1.8.0.2
Flags: blocking1.8.0.2+
Flags: blocking1.7.13+
Flags: blocking-aviary1.0.8+
Comment on attachment 205433 [details] [diff] [review]
Possible patch

a=dveditz for drivers, please add fixed-aviary1.0.8 and fixed1.7.13 keywords when checked in.
Attachment #205433 - Flags: approval1.7.13?
Attachment #205433 - Flags: approval1.7.13+
Attachment #205433 - Flags: approval-aviary1.0.8?
Attachment #205433 - Flags: approval-aviary1.0.8+
Comment on attachment 205611 [details] [diff] [review]
Fix RemoveEventListener

a=dveditz for drivers, please add fixed-aviary1.0.8 and fixed1.7.13 keywords when checked in.
Attachment #205611 - Flags: approval1.7.13?
Attachment #205611 - Flags: approval1.7.13+
Attachment #205611 - Flags: approval-aviary1.0.8?
Attachment #205611 - Flags: approval-aviary1.0.8+
(Assignee)

Comment 44

12 years ago
Fix checked into the aviary and 1.7 branches.
Keywords: fixed-aviary1.0.8, fixed1.7.13

Comment 45

12 years ago
v.fixed on 1.0.1 Aviary branch with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060213 Firefox/1.0.8, per Talkback data and also because I was unable to reproduce using various cases mentioned here.
Keywords: fixed-aviary1.0.8 → verified-aviary1.0.8

Updated

12 years ago
Whiteboard: [rft-dl]

Updated

12 years ago
Keywords: fixed1.8.0.2 → verified1.8.0.2
Crash Signature: [@ nsTextEditorKeyListener::KeyPress]
You need to log in before you can comment on or make changes to this bug.