Closed Bug 266822 Opened 18 years ago Closed 18 years ago

crash if right-clicking on a text box, wait for text box to go away, press escape [@ nsMenuListener::KeyPress]; affects find bar in Firefox

Categories

(Core :: DOM: Events, defect)

x86
Windows XP
defect
Not set
critical

Tracking

()

VERIFIED FIXED

People

(Reporter: ori, Assigned: neil)

References

Details

(Keywords: crash, fixed-aviary1.0, fixed1.7.5)

Crash Data

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0RC1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0RC1

This crash was originally reported in the second comment of bug 258781 by Jordan
Liggit. Since it didn't get a response from devs (it was out of context, and the
actual reported bug was dismissed), I now create a new entry for it.


Reproducible: Always
Steps to Reproduce:
1. Navigate to any website
2. Make the Find Toolbar appear either by searching something.
3. When the toolbar appears, right-click in the textbox to display the 
context menu
4. Wait for the toolbar to disappear
5. Hit the 'Esc' key

Actual Results:  
Browser crashes.


I only tested this on Windows XP
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-aviary1.0?
Talkback ID 1636197
I crashed here:
http://lxr.mozilla.org/aviarybranch/source/layout/xul/base/src/nsMenuListener.cpp#203

handled = 0
theChar = 27
mMenuParent = 0x02bf3448
 nsISupports = {...}
  __vfpt = 0xdddddddd
this = 0x02c8ffe0
 (the rest of "this" looks fine)
(In reply to comment #0)

After more reseach and realizing I had some typos:

1) It only works when the timeout is enabled, which means you can't use ctrl+F.
2) Possible fix:
 toolkit/components/typeaheadfind/content/findBar.js :
 When right clicking on the find text-box, set gFindMode to FIND_NORMAL.
 It is logical, because if the user wants to edit something in the text box, it
should not disappear in the middle of the task, and it will prevent the crash.
Flags: blocking-aviary1.0? → blocking-aviary1.0+
Summary: crash if right-clicking on the find text box,, waiting for find bar to go away, and escaping → crash if right-clicking on the find text box, waiting for find bar to go away, and escaping
only ADT has the right to + bugs. You can set ?
Flags: blocking-aviary1.0+
Summary: crash if right-clicking on the find text box, waiting for find bar to go away, and escaping → crash if right-clicking on the find text box,, waiting for find bar to go away, and escaping
err, i wasn't clear. you can set "?"
The problem appears to be that somebody (nsMenuPopupFrame?) creates a
nsMenuListener, and after the timer expires the parent of the menu listener is
deleted, so the next time the listener dereferences it's parent, crash.
Summary: crash if right-clicking on the find text box,, waiting for find bar to go away, and escaping → crash if right-clicking on the find text box, waiting for find bar to go away, and escaping
As I recall, trunk got some patches to handle menu teardown properly in the 1.8a
cycle.  So this is probably fixed on trunk, if someone can test it (I'm not sure
the find toolbar is on trunk, of course).
->Browser
Testcase coming in a moment.
Component: Find Toolbar / FastFind → DOM: Events
Product: Firefox → Browser
Summary: crash if right-clicking on the find text box, waiting for find bar to go away, and escaping → crash if right-clicking on a text box, wait for text box to go away, press escape
Version: unspecified → Trunk
Attached patch Proposed patchSplinter Review
Assignee: firefox → neil.parkwaycc.co.uk
Status: NEW → ASSIGNED
Attachment #164119 - Flags: superreview?(roc)
Attachment #164119 - Flags: review?(roc)
Attachment #164119 - Flags: superreview?(roc)
Attachment #164119 - Flags: superreview+
Attachment #164119 - Flags: review?(roc)
Attachment #164119 - Flags: review+
Keywords: crash
Summary: crash if right-clicking on a text box, wait for text box to go away, press escape → crash if right-clicking on a text box, wait for text box to go away, press escape [@ nsMenuListener::KeyPress ]
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Attachment #164119 - Flags: approval1.7.x?
Attachment #164119 - Flags: approval-aviary?
Comment on attachment 164119 [details] [diff] [review]
Proposed patch

Looks like a nobrainer for 1.7. email aviary for aviary
Attachment #164119 - Flags: approval1.7.x? → approval1.7.x+
Keywords: fixed1.7
Summary: crash if right-clicking on a text box, wait for text box to go away, press escape [@ nsMenuListener::KeyPress ] → crash if right-clicking on a text box, wait for text box to go away, press escape [@ nsMenuListener::KeyPress]; affects find bar in Firefox
Comment on attachment 164119 [details] [diff] [review]
Proposed patch

a=asa for aviary checkin. Time is very short for Firefox 1.0 so please land
this quickly.
Attachment #164119 - Flags: approval-aviary? → approval-aviary+
Checked into aviary.
Flags: blocking-aviary1.0?
Keywords: fixed-aviary1.0
what happens using 2004110609-0.11 on linux fc2:

1. bring up find toolbar (I hit the / FAYT command)
2. bring up context menu for textfield in find toolbar
3. wait a few seconds for FAYT to time out.

results: both the find toolbar *and* context menu go away (no chance to hit Esc
key to dismiss context menu). is this expected now?
(In reply to comment #15)
> results: both the find toolbar *and* context menu go away (no chance to hit Esc
> key to dismiss context menu). is this expected now?

To this problem, my suggestion on comment #3 would suffice: Whenever the user
interacts with a find toolbar that has a timer (one which was invoked using
FAYT), disable it, and turn the toolbar into a regular CRTL+F one (gFindMode =
FIND_NORMAL in the findBar.js code).
It is not a necessity, just a UI improvement.
> results: both the find toolbar *and* context menu go away (no chance to hit Esc
> key to dismiss context menu). is this expected now?
I think so. If the find bar is gone, there is nothing to cut/copy/paste anymore.
Ori is right IMHO: The find bar shouldn't go away in the first place if you
opened a context menu. But that's another (find-bar) bug.
Steffen, thanks for the clarification! vrfy'ing this particular bug as fixed.
Status: RESOLVED → VERIFIED
(In reply to comment #17)
Opened bug #268305
*** Bug 204041 has been marked as a duplicate of this bug. ***
Crash Signature: [@ nsMenuListener::KeyPress]
You need to log in before you can comment on or make changes to this bug.