93471 - Find crashes when "cancel" is clicked while searching - Trunk M097 N621 [@ nsEventStateManager::PreHandleEvent]

Status: RESOLVED WORKSFORME

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[nemo]

When searching a large file for a text string, if one clicks on "Cancel" the
browser crashes.
This behaviour does not occur under Windows/Solaris builds. 

Also, the entire application hangs when using Find, this is
something I've noticed with other Mozilla functions.  Does Mozilla
use threading?  
To Reproduce:
1. CTRL-F when a large file is opened
2. type somerandomstring
3. Hit cancel while it is searching 

Expected Behaviour:
Should've cancelled or at least continued the search.

Comment 1

[nemo]

Oh, I tested this on an 07/27 nightly, then an 08/03 build.
Occurs in both, with additional fun of 08/03 having that javascript error that
makes it impossible to file this bug on the main mozilla page.

Comment 2

[matt]

need new netscape sherlock file for mozilla builds

Comment 3

[Con Kolivas]

Confirmed on linux 0.9.3 with talkback build.
Talkback ID TB33788883Y

Comment 4

[Claudius Gayle]

talkback is so cool now...

33788883 and 93471 

                              
                                Show Incident ID 


                              
                                Set Bug ID 

Incident ID 33788883 
  Stack Signature
                             nsEventStateManager::PreHandleEvent() 5752097f 
  Bug ID
                             93471 
  Trigger Time 
                             2001-08-06 07:30:14 
  Email Address 
                             [e-mail] 
  User Comments 
                             Clicking on cancel while doing a text find in a large text file. 
  Build ID
                             2001080104 
  Product ID
                             MozillaTrunk 
  Platform ID
                             LinuxIntel 
  Stack Trace

nsEventStateManager::PreHandleEvent() 
PresShell::HandleEventInternal() 
PresShell::HandleEvent() 
nsView::HandleEvent() 
nsViewManager::DispatchEvent() 
HandleEvent() 
nsWidget::DispatchEvent() 
nsWidget::DispatchWindowEvent() 
nsWidget::DispatchFocus() 
nsWindow::DispatchDeactivateEvent() 
nsWindow::HandleMozAreaFocusOut() 
handle_mozarea_focus_out() 
libgtk-1.2.so.0 + 0x9576c (0x4029776c) 
libgtk-1.2.so.0 + 0xc8f56 (0x402caf56) 
libgtk-1.2.so.0 + 0xc828d (0x402ca28d) 
libgtk-1.2.so.0 + 0xc6035 (0x402c8035) 
libgtk-1.2.so.0 + 0x100af9 (0x40302af9) 
libgtk-1.2.so.0 + 0x109954 (0x4030b954) 
libgtk-1.2.so.0 + 0x9576c (0x4029776c) 
libgtk-1.2.so.0 + 0xc82cd (0x402ca2cd) 
libgtk-1.2.so.0 + 0xc6035 (0x402c8035) 
libgtk-1.2.so.0 + 0x100af9 (0x40302af9) 
libgtk-1.2.so.0 + 0x94794 (0x40296794) 
handle_gdk_event() 
libgdk-1.2.so.0 + 0x17d6f (0x4034dd6f) 

I gave this a spin on a Win98 2001080203 trunk build as was unable to repro. Could try on linux due to technical
difficulties. Over to XPApps:GUI where these bugs belong.
Matt was your comment relevant to this bug or no?

Comment 5

[matt]

no relevance at all.   Wrong bug.  This is a find bug.
Should be law's bug.

Comment 6

[Markus Gerstel]

Confirmed 2001083106 linux and 112 MB text/plain

Comment 7

[selmer (gone)]

-> Peter

Comment 8

[matt]

Peter,

This is a linux only bug.
On window i don't crash but i also can't cancel
Law might know this bug since he had the find dialog.

Comment 9

[Bill Law]

No, I worked on that dialog eons ago.  It is completely different now.  And the
problem probably isn't in the dialog itself, but rather in the underlying
webshell/docshell/document/text-services stuff (of which I know little or
nothing).  Kin would be a more likely source of help than me.

Comment 10

[kinmoz]

The stack points to it crashing in event code.

You can't cancel in the middle of a find since the TextServices find code
executes on the same thread that services the dialog events ... this means any
canceling/closing of the dialog is done after the find has completed.

Comment 11

[kinmoz]

I forgot to add that I couldn't reproduce this crash with my 09/06/01 mozilla
debug build. Is there a specific page/url that crashes all the time?

Comment 12

[Peter Trudelle]

->event handling

Comment 13

[lchiang]

jay, can you search to see if this is a topcrash in talkback? per PDT

Comment 14

[Jay Patel [:jay]]

This appears to be a topcrasher with M093 (MozillaTrunk build 2001080112 for
Win32 and build 2001080104 for Linux), but since then there are only 3 incidents
reported in Talkback.  Here is the most recent crash (which might even be a
different crash than the one reported):

Incident ID 35295973
Stack Signature nsEventStateManager::PreHandleEvent b83572e6
Bug ID
Trigger Time 2001-09-12 11:53:37
Email Address
User Comments
Build ID 2001091109
Product ID MozillaTrunk
Platform ID Win32
Trigger Reason Access violation
Stack Trace
nsEventStateManager::PreHandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 412]
PresShell::HandleEventInternal
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5653]
PresShell::HandleEvent
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5583]
nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 377]
nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 350]
nsViewManager::DispatchEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 2058]
HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 68]
nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 732]
nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 749]
nsWindow::DispatchFocus
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4454]
nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3359]
nsWindow::WindowProc
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 997]
KERNEL32.DLL + 0x3613 (0xbff63613)
KERNEL32.DLL + 0x248f7 (0xbff848f7)

Most of the comments from M093 data mention canceling out of a search or closing
popup windows.

Comment 15

[Asa Dotzler [:asa]]

0.9.4 is out the door

Comment 16

[saari (gone)]

-> 0.9.6

Comment 17

[Jay Patel [:jay]]

This continues to be a topcrasher with Mozilla 0.9.4 so adding M094  [@
nsEventStateManager::PreHandleEvent] to summary for tracking.  Here is the
latest info from Talkback reports:

nsEventStateManager::PreHandleEvent   32 
BBID range: 36080767 - 36362206
Min/Max Seconds since last crash: 89 - 516605
Min/Max Runtime: 21409 - 516605
Crash data range: 2001-09-30 to 2001-10-06
Build ID range: 2001091311 to 2001091311

Stack Trace: 

	 nsEventStateManager::PreHandleEvent()
	 PresShell::HandleEventInternal()
	 PresShell::HandleEvent()
	 nsView::HandleEvent()
	 nsView::HandleEvent()
	 nsView::HandleEvent()
	 nsViewManager::DispatchEvent()
	 HandleEvent()
	 nsWidget::DispatchEvent()
	 nsWidget::DispatchWindowEvent()
	 nsWidget::DispatchFocus()
	 nsWindow::DispatchSetFocusEvent()
	 nsWindow::SetFocus()
	 GlobalWindowImpl::Focus()
	 CheckForFocus()
	 PresShell::UnsuppressAndInvalidate()
	 PresShell::UnsuppressPainting()
	 DocumentViewerImpl::LoadComplete()
	 nsDocShell::EndPageLoad()
	 nsWebShell::EndPageLoad()
	 nsDocShell::OnStateChange()
	 nsDocLoaderImpl::FireOnStateChange()
	 nsDocLoaderImpl::doStopDocumentLoad()
	 nsDocLoaderImpl::DocLoaderIsEmpty()
	 nsDocLoaderImpl::OnStopRequest()
	 nsLoadGroup::RemoveRequest()
	 PresShell::RemoveDummyLayoutRequest()
	 PresShell::DoneRemovingReflowCommands()
	 PresShell::ProcessReflowCommands()
	 HandlePLEvent()
	 PL_HandleEvent()
	 PL_ProcessPendingEvents()
	 nsEventQueueImpl::ProcessPendingEvents()
	 event_processor_callback()
	 our_gdk_io_invoke()     (36151912)	URL: http://www.builder.com
(36151912)
Comments: I searched for the "Color Convertor" on Builder.comThen I didn't input
a correct color code. I kept on getting alerts (up to number 8 between brackets)
until finally the feedbackagent prompted.

Comment 18

[greer]

Adding topcrash keyword for talkback

Comment 19

[Matthias Versen [:Matti]]

*** Bug 109282 has been marked as a duplicate of this bug. ***

Comment 20

[Jonadab the Unsightly One (Nathan Eady)]

Does this occur only with plaintext, or with HTML as well?

Large pages that could maybe be used as testcases:

339K HTML:  
http://members.kconline.com/kerr/pball.htm  

634K plain text:
http://www.ifarchive.org/if-archive/infocom/compilers/inform6/manuals/old/designers_manual.txt

Comment 21

[nemo]

any large text file. html was what was originally used.
The problem isn't so much in find's parsing of the page, as, it seems in some
thread thing when cancelling a search.

Comment 22

[Jonadab the Unsightly One (Nathan Eady)]

Too late for 0.9.6, this needs retargeting.

Comment 23

[joki (gone)]

0.9.6 has passed, moving to 0.9.7.  Load balancing 0.9.7 list shortly

Comment 24

[joki (gone)]

Moving bugs from 0.9.7 for triaging in 0.9.8

Comment 25

[Jay Patel [:jay]]

Updating summary with Trunk, M097 and N621...this continues to crash with
MozillaTrunk builds, Mozilla 0.9.7 and Netscpae 6.21.  i don't think the stack
has changed much...take a look at bug 118685 (which i think might even be a dup).

Bug 101834 also has the same stack signature, but the stack looks a little
different, so I'm not sure if that's a dup or not.

Comment 26

[Peter Trudelle]

nsbeta1+ per ADT triage

Comment 27

[Jay Patel [:jay]]

Adding testcase keyword, since comments 20 and 21 mention a testcase that leads
to this crash.

Comment 28

[Brian Ryner (not reading)]

I'm not able to reproduce this at all with build 2002022208 (RedHat 7.2, window
manager is sawfish).

Comment 29

[Judson Valeski]

-> 1.0

Comment 30

[nemo]

Re: Bryan's comment
I went back to this bug, now in 7.2 instead of 6.2 of redhat.
(haven't tested it on old machine yet)
As in other operating systems it seems Mozilla once more freezes completely
while searching, all windows unresponsive, including, yes, the Cancel button.
However, since it wasn't even redrawing when the find window, I doubt this was
due to even anything like disabling cancel while searching and simply more of
the one busy window locks up all of Mozilla thing.
Might be sorta fixed though.

Comment 31

[Jay Patel [:jay]]

Marking this bug worksforme.  There haven't been any crashes with this signature
since 2/18.  Please reopen if anyone can reproduce this crash with a more recent
MozillaTrunk build.