Crash in nsWindow if mouse clicked before parentWidget is available

RESOLVED FIXED in mozilla1.3alpha

Status

()

Core
Layout
P1
critical
RESOLVED FIXED
15 years ago
15 years ago

People

(Reporter: Angelo Nunes, Assigned: rods (gone))

Tracking

({crash})

Trunk
mozilla1.3alpha
x86
Windows 2000
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0

 HWND parentWnd = ::GetParent(mWnd);
    if (parentWnd) {
      nsWindow* parentWidget = GetNSWindowPtr(parentWnd);
      if (parentWidget->mIMEIsComposing && nsWindow::uWM_MSIME_MOUSE) {

parentWnd is valid but parentWidget is NULL... crashola...
Happens if you click on the gecko view window too soon.

Reproducible: Always

Steps to Reproduce:
1.Launch a gecko viewer
2.click on the window immediately after its viewable
3.

Actual Results:  
Crash

Expected Results:  
return

Comment 1

15 years ago
hey rod

can you take a look at this one?

thanks,
-- rick
Assignee: other → rods
(Reporter)

Comment 2

15 years ago
Patch I applied to my branch:

Index: nsWindow.cpp
===================================================================
RCS file: /cvsroot/mozilla/widget/src/windows/nsWindow.cpp,v
retrieving revision 3.453
diff -u -r3.453 nsWindow.cpp
--- nsWindow.cpp        25 Oct 2002 00:03:47 -0000      3.453
+++ nsWindow.cpp        5 Dec 2002 19:48:20 -0000
@@ -6675,7 +6675,7 @@
     HWND parentWnd = ::GetParent(mWnd);
     if (parentWnd) {
       nsWindow* parentWidget = GetNSWindowPtr(parentWnd);
-      if (parentWidget->mIMEIsComposing && nsWindow::uWM_MSIME_MOUSE) {
+      if (parentWidget && parentWidget->mIMEIsComposing && nsWindow::uWM_MSIME_
MOUSE) {
         if (parentWidget->IMECompositionHitTest(aEventType, &ptPos))
           if (parentWidget->HandleMouseActionOfIME(aAction, &ptPos))
             return PR_TRUE;
(Assignee)

Comment 3

15 years ago
Created attachment 108395 [details] [diff] [review]
patch

Simple fix, just make sure we have a valid pointer
(Assignee)

Updated

15 years ago
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P1
Target Milestone: --- → mozilla1.3alpha
(Assignee)

Updated

15 years ago
Attachment #108395 - Flags: superreview?(jst)
Attachment #108395 - Flags: review?(dcone)
Comment on attachment 108395 [details] [diff] [review]
patch

sr=jst
Attachment #108395 - Flags: superreview?(jst) → superreview+

Comment 5

15 years ago
Comment on attachment 108395 [details] [diff] [review]
patch

r=dcone
Attachment #108395 - Flags: review?(dcone) → review+
(Assignee)

Comment 6

15 years ago
Requesting for inclusion in 1.3a, zero risk, it is an extra valid pointer check.
Flags: blocking1.3a?
Keywords: crash

Updated

15 years ago
Flags: blocking1.3a?

Comment 7

15 years ago
Comment on attachment 108395 [details] [diff] [review]
patch

I assume the "blocking1.3a" was intended as a request to land this patch (which
should be done with the "approval1.3a" flag in the patch manager). Removed
blocking request and a=asa for checkin to 1.3a.
Attachment #108395 - Flags: approval1.3a+
(Assignee)

Comment 8

15 years ago
fixed
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.