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)

PowerPC
Mac System 8.6
defect

Tracking

()

VERIFIED FIXED

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.
QA Contact: paulmac → pinkerton
Assignee: trudelle → saari
Keywords: dogfood
Priority: P3 → P1
Target Milestone: M13
assigning to saari as p1 for m13, putting on dogfood radar
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.
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.
So what is the difference between the weak refs and the current scheme of delete

observers?
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
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.
Adding crash keyword
Keywords: crash
marking as verified, no crash
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.