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

VERIFIED FIXED

Status

()

--
critical
VERIFIED FIXED
14 years ago
12 years ago

People

(Reporter: ori, Assigned: neil)

Tracking

({crash, fixed-aviary1.0, fixed1.7.5})

Trunk
x86
Windows XP
crash, fixed-aviary1.0, fixed1.7.5
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(2 attachments)

(Reporter)

Description

14 years ago
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)
(Reporter)

Comment 3

14 years ago
(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+
(Reporter)

Updated

14 years ago
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 "?"
Flags: blocking-aviary1.0?
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.
(Reporter)

Updated

14 years ago
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
(Assignee)

Comment 10

14 years ago
Created attachment 164119 [details] [diff] [review]
Proposed patch
Assignee: firefox → neil.parkwaycc.co.uk
Status: NEW → ASSIGNED
(Assignee)

Updated

14 years ago
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+

Updated

14 years ago
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 ]
(Assignee)

Comment 11

14 years ago
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED

Updated

14 years ago
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+
(Assignee)

Updated

14 years ago
Keywords: fixed1.7
Keywords: fixed1.7 → fixed1.7.x

Updated

14 years ago
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 13

14 years ago
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+

Comment 14

14 years ago
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?
(Reporter)

Comment 16

14 years ago
(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.

Comment 17

14 years ago
> 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
(Reporter)

Comment 19

14 years ago
(In reply to comment #17)
Opened bug #268305

Comment 20

12 years ago
*** 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.