Closed
Bug 24124
Opened 25 years ago
Closed 25 years ago
[Crash] Focused widgets cause crash when going to another page
Categories
(Core :: XUL, defect, P1)
Tracking
()
VERIFIED
FIXED
M13
People
(Reporter: beard, Assigned: saari)
Details
(Keywords: crash)
Here's a simple way to make this happen: 1. Go to bugzilla.mozilla.org and click in the "Show Mozilla bug no." text field. 2. Type in some bug number (e.g. 11625). 3. Hit return to go to that bug. 4. Click in a popup menu or text field. Boom, you will crash. I believe the problem is caused by a dangling pointer used in nsMacEventDispatchHandler::SetFocus(), and the dangling pointer is the field mActiveWidget. Somehow the widget is getting deleted w/o the DeleteObserver logic getting invoked.
Reporter | ||
Updated•25 years ago
|
QA Contact: paulmac → pinkerton
Updated•25 years ago
|
Comment 1•25 years ago
|
||
assigning to saari as p1 for m13, putting on dogfood radar
Reporter | ||
Comment 2•25 years ago
|
||
Here's a patch that seems to fix the problem. nsMacEventHandler::SetActivated() wasn't guarding against a changing activated widget. It wasn't telling the previously active widget to deactivate itself. I also changed nsDeleteObserved::~nsDeleteObserved() to count down from (count - 1) to 0. Index: mozilla/widget/src/mac/nsMacEventHandler.cpp =================================================================== RCS file: /cvsroot/mozilla/widget/src/mac/nsMacEventHandler.cpp,v retrieving revision 1.79 diff -r1.79 nsMacEventHandler.cpp 147a148,155 > // tell the old widget it is not focused > if (mActiveWidget) > { > mActiveWidget->ResetInputState(); > mActiveWidget->RemoveDeleteObserver(this); > DispatchGuiEvent(mActiveWidget, NS_LOSTFOCUS); > } > Index: mozilla/widget/src/mac/nsDeleteObserver.cpp =================================================================== RCS file: /cvsroot/mozilla/widget/src/mac/nsDeleteObserver.cpp,v retrieving revision 1.3 diff -r1.3 nsDeleteObserver.cpp 45c45 < for (PRInt32 i = 0; i < mDeleteObserverArray->Count(); i ++) --- > for (PRInt32 i = mDeleteObserverArray->Count() - 1; i >= 0; --i) If you'll review, I'll check them in.
Reporter | ||
Comment 3•25 years ago
|
||
I've checked this in, and click in form elements now works. However, I just saw another crash, when selecting menu items. So, there's still a potential problem lurking. I think the real fix might be to use weak references, because you are potentially holding dangling refs right now. Thus, nsWindow or nsBaseWindow would need to implement nsWeakReferent, and we'd use nsIWeakReference to hold the pointer to the focused widget.
Assignee | ||
Comment 4•25 years ago
|
||
So what is the difference between the weak refs and the current scheme of delete observers?
Assignee | ||
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 5•25 years ago
|
||
I checked a fix for this. The focus code was forgetting a release, and thus when a windows parent chain went away, it wouldn't and we'd die when trying to go back up the parent chain.
You need to log in
before you can comment on or make changes to this bug.
Description
•