70775 - Crash on find in page if you cancel find dialog before 'text not found' alert dialog

Status: VERIFIED WORKSFORME

(SeaMonkey :: UI Design, defect)

Description

[vectro]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16 i686; en-US; 0.8) Gecko/20010218
BuildID:    2001021812

This bug may be a duplicate of bug 67670.

Reproducible: Always
Steps to Reproduce:
1) Hit CTRL-F, or go to Search..Find in this page
2) Search for something which yields no results
3) Ignore the dialog that comes up saying there are no results.
4) Click back on the "find in this page" dialog
5) Hit ESC
6) Click OK on the "no results" dialog.

Actual Results:  Mozilla crashes after step 6. Nothing is printed on the console.

Expected Results:  Probably step 4, should not be allowed, this is definately
the case for step 5.

Comment 1

[Agustín Fernández]

CONFIRMED Linux 20010215
The same thing seems to cause this and bug 67670, but since they don´t describe
the same situation (´there are not results´ does not popup in 67670) I confirm it.

From bug 67670:
Every time i search a string in the page (off-line or not), BeZilla crash: in
depth, Bezilla crash only when there aren't any match, and you select cancel in
the dialog box.

Comment 2

[Craig Tyler]

Mozilla/5.0 (X11; U; Linux 2.2.18pre21-ide i686; en-US; 0.9), build 2001030505

The problem appears to be that keyboard input is not ignored when it should be.
After the Alert window with "The text you entered was not found." appears the
Find in this Page window will properly ignore mouse clicks and attempts to close
it via window manager widgets. However typing enter and escape are not ignored.
Restoring focus to the Find in this Page window while the Alert is displayed and
typing enter or space bar will repeat the search producing additional Alert
windows, while escape will close the window and cause the crash.

Comment 3

[Claudius Gayle]

From the Search component description (click on the link 'Component' in a bug report):
"For bugs associated with the Search button, the Search Results Sidebar panel, the Search menu
(except for Find/Find in page...), and Advanced Search. For bugs involving the "Find" or "Find on
Page..." menu items, use XPApps."

Comment 4

[sairuh (rarely reading bugmail)]

not sure if this is the same as bug 67670... cc'ing danm, jrgm, bill and jag if
they have further input. not sure who should own this puppy... am thinking this
might be due to lack of dialog modality on linux; not a problem on win32 or mac.

Incident ID 27663829 
 Trigger Time                2001-03-12 14:07:51  
 User Comments                bug 70775 
 Build ID                2001031208 
 Platform ID                LinuxIntel 
 Stack Trace

libgkcontent.so + 0x540f7 (0x40a980f7) 
libgkcontent.so + 0x5166e (0x40a9566e) 
libgklayout.so + 0x6186f (0x40d7686f) 
libgklayout.so + 0x61772 (0x40d76772) 
libgkview.so + 0x3969 (0x40fb4969) 
libgkview.so + 0x1296e (0x40fc396e) 
libgkview.so + 0x334d (0x40fb434d) 
libwidget_gtk.so + 0x1a2fa (0x404aa2fa) 
libwidget_gtk.so + 0x1a225 (0x404aa225) 
libwidget_gtk.so + 0x1a380 (0x404aa380) 
libwidget_gtk.so + 0x1a71d (0x404aa71d) 
libwidget_gtk.so + 0x1e9bf (0x404ae9bf) 
libwidget_gtk.so + 0x150b7 (0x404a50b7) 
libwidget_gtk.so + 0x14eae (0x404a4eae) 
libgdk-1.2.so.0 + 0x174db (0x406154db) 
libglib-1.2.so.0 + 0x10186 (0x40642186) 
libglib-1.2.so.0 + 0x10751 (0x40642751) 
libglib-1.2.so.0 + 0x10804 (0x40642804) 
libwidget_gtk.so + 0xd47c (0x4049d47c) 
libnsappshell.so + 0x88d8 (0x403718d8) 
libnsappshell.so + 0xfb7c (0x40378b7c) 
libnsappshell.so + 0x60aa (0x4036f0aa) 
libembedcomponents.so + 0x3937 (0x4085e937) 
libjsdom.so + 0x446b8 (0x403d56b8) 
libjsdom.so + 0x42135 (0x403d3135) 
libnsappshell.so + 0x1845a (0x4038145a) 
libnsappshell.so + 0x174b7 (0x403804b7) 
libnsappshell.so + 0x111ee (0x4037a1ee) 
libwallet.so + 0x54f0 (0x411a14f0) 
libjsdom.so + 0x3fa59 (0x403d0a59) 
libjsdom.so + 0x352fa (0x403c62fa) 
libmozjs.so + 0x2d9a5 (0x4012d9a5) 
libmozjs.so + 0x34d95 (0x40134d95) 
libmozjs.so + 0x2d9f0 (0x4012d9f0) 
libmozjs.so + 0x2dbec (0x4012dbec) 
libmozjs.so + 0x12aaf (0x40112aaf) 
libjsdom.so + 0x2ef40 (0x403bff40) 
libjsdom.so + 0x64436 (0x403f5436) 
libgkcontent.so + 0x4de80 (0x40a91e80) 
libgkcontent.so + 0x4f95c (0x40a9395c) 
libgkcontent.so + 0x124439 (0x40b68439) 
libgklayout.so + 0x61a26 (0x40d76a26) 
libgklayout.so + 0xf6f01 (0x40e0bf01) 
libgklayout.so + 0xf6da6 (0x40e0bda6) 
libgklayout.so + 0x61952 (0x40d76952) 
libgklayout.so + 0x617f0 (0x40d767f0) 
libgkcontent.so + 0x55043 (0x40a99043) 
libgkcontent.so + 0x538e7 (0x40a978e7) 
libgklayout.so + 0x61987 (0x40d76987) 
libgklayout.so + 0x61772 (0x40d76772) 
libgkview.so + 0x3969 (0x40fb4969) 
libgkview.so + 0x1296e (0x40fc396e) 
libgkview.so + 0x334d (0x40fb434d) 
libwidget_gtk.so + 0x1a2fa (0x404aa2fa) 
libwidget_gtk.so + 0x1a225 (0x404aa225) 
libwidget_gtk.so + 0x1a380 (0x404aa380) 
libwidget_gtk.so + 0x1afcf (0x404aafcf) 
libwidget_gtk.so + 0x1e9bf (0x404ae9bf) 
libwidget_gtk.so + 0x150b7 (0x404a50b7) 
libwidget_gtk.so + 0x14eae (0x404a4eae) 
libgdk-1.2.so.0 + 0x174db (0x406154db) 
libglib-1.2.so.0 + 0x10186 (0x40642186) 
libglib-1.2.so.0 + 0x10751 (0x40642751) 
libglib-1.2.so.0 + 0x108f1 (0x406428f1) 
libgtk-1.2.so.0 + 0x8c5b9 (0x4056a5b9) 
libwidget_gtk.so + 0xd40c (0x4049d40c) 
libnsappshell.so + 0xd61a (0x4037661a) 
mozilla-bin + 0x6025 (0x0804e025) 
mozilla-bin + 0x6885 (0x0804e885) 
libc.so.6 + 0x189cb (0x402469cb) 

Comment 5

[Dan M]

Seems like a problem with our current modality implementation: you can't dismiss 
the parent (the find dialog) of the modal window (the alert) using the mouse, but 
the window still takes keystrokes. So ESC can close the windows out of order, and 
it's not surprising bad things happen.

The fix for bug 65521 (which does prevent keystrokes from making it to the parent 
of a modal window) nearly fixes this. It *should* fix it. Anyway, I'm pretty sure 
this is my bug. I'll take it, unless Ben objects.

Comment 6

[peter]

I looked more into this bug. My patch for 65521 doesn't block the keyset events
that are defined in js. You can easily check this(with my patch for 65521) by
seeing that you can still scroll up and down with the save dialog box up.

But the patch for 65521 blocks all of the native events that are coming through.
But it looks as though the keyset events maybe considered mozilla events and
thus I never get them with my patch in 65521(which also may be why with 65521
you can only yield this crash when you are on the title bar). 

Another this to consider...this will also crash on any dialog that spawns
another dialog...or hell anything that has "ESC" to close the window. An example
is the print dialog box.

That is just the conclusion I reached by looking at it a little bit. But the
keyboard events that seem to be yielding the problem come from the keyset tag in
mozilla.

Peter Hsu

Comment 7

[peter]

Alright I looked a little bit more at this. 

Well the reason why we are having problems with this bug( and it doesn't show up
under windows). Is that with or without the patch for 65521, you can still focus
on the parent window and thus the keyset keys will work. Under windows(with its
proper modality setup) you cannot give focus to the parent window and thus...you
cannot yield this bug.(or scroll up and down while a modal dialog box is open)

So I guess the real solution would be to expand the patch for 65521 to make sure
that the parent couldn't have focus. So that if you tried to focus the parent it
would just yield a focus on the modal dialog box. However I am not sure what
gtk/gdk call will be able to do this. I have tried a whole bunch of them...and I
cannot seem to be able to do it. Perhaps someone who is an expert at such things
could help me out. I even tried all of the nsWindow->SetFocus() and
nsWindow->Activate calls to see if I could reroute the focus events for the
parent to the dialog. 

Peter Hsu

Comment 8

[peter]

I posted a fix for this bug as part of a patch for 65521. 

It throws the keyboard events out(I was wrong about the mozilla events and the
gtkEventHandler never getting them) of the parent window.

Peter Hsu

Comment 9

[Chase Tingley]

Using 0.9 (2001050521) on Linux, this does not crash for me.  I can still ESC
out of the parent ("Find in this page") dialog before closing the alert, but
Mozilla survives.

Fixed?

Comment 10

[Peter Trudelle]

What happens with this on current trunk builds (I'd try it, but I have to revert 
num several libraries first).  adding qawanted keyword.

Comment 11

[vectro]

In 2001050521 Linux, this bug appears to be fixed.

Comment 12

[Peter Trudelle]

yup, resolving wfm using latest (051015) build.

Comment 13

[sairuh (rarely reading bugmail)]

and vrfy --the "text not found" dialog now appears modal on linux.