Crash using mouse scroll wheel on unfocused browser page when running mfcembed and mozilla build at the same time.

VERIFIED FIXED in mozilla1.0

Status

()

Core
Embedding: APIs
VERIFIED FIXED
16 years ago
16 years ago

People

(Reporter: michael wendell, Assigned: Adam Lock)

Tracking

({crash, topembed+})

Trunk
mozilla1.0
x86
All
crash, topembed+
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt2 rtm])

Attachments

(1 attachment)

1.75 KB, patch
Brian Ryner (not reading)
: review+
Alec Flett
: superreview+
Details | Diff | Splinter Review
(Reporter)

Description

16 years ago
I have seen this on Win 2k and Win XP.

If you have Mozilla trunk build and a mfcembed build running at the same time,
and try to use the scrolling mouse wheel over the non focused page, you will get
a crash.

Steps to Reproduce:
1. Install and launch a Mozilla build (non-maximized)
2. Install and launch an MFCEmbed build (non-maximized)
3. Position both screens so that you can see part of the webpages displayed by
each build
4. Click on the title bar of the Mozilla build to bring focus to it
5. Position your mouse over the page within the MFCEmbed build and without
clicking, use the mouse scroll wheel

Actual Results:
Crash   Talkback ID: TB5139992G

Expected Results:
No crash, the page should scroll.  

Note:
This may sound rather obscure, but I think it is definitely an issue that people
will run into.
0x00eb944c
nsWindow::WindowProc
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 1131]
USER32.DLL + 0x3eb0 (0x77e13eb0)
USER32.DLL + 0x401a (0x77e1401a)
USER32.DLL + 0x92da (0x77e192da)
nsAppShellService::Run
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 309]
main1 [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1431]
main [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1766]
WinMain [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1784]
WinMainCRTStartup()
KERNEL32.DLL + 0x7903 (0x77e87903) 
question: 
What is crashing : MFCEmbed or Mozilla
is MFCEmbed using the same profile ?
Component: Browser-General → Embedding: APIs
(Reporter)

Comment 3

16 years ago
Either one will crash depending on which one has focus.  In my above case it was
Mozilla that crashed, but I just did that to get the talkback. 

No, I am not using the same profile for each.

One more thing to note is that this does not happen if the MFCEmbed and Mozilla
build are both trunk builds.  But if either or both builds are 1.0.0 branch, the
problem happens every time.
-> Default Owner 
Assignee: Matti → adamlock
QA Contact: imajes-qa → mdunn

Comment 5

16 years ago
2002041903/Win2k crashes if Netscape 6.2 is running at the same time.

Talkback ID: TB5417078H
(Assignee)

Comment 6

16 years ago
Confirming. Stack trace:

nsWindow::ProcessMessage(unsigned int 522, unsigned int 4287102976, long
35586269, long * 0x0012fd88) line 4105 + 22 bytes
nsWindow::WindowProc(HWND__ * 0x00030578, unsigned int 522, unsigned int
4287102976, long 35586269) line 1130 + 27 bytes
USER32! 77d43a5f()
USER32! 77d43b2e()
USER32! 77d43d6a()
USER32! 77d441fd()
CWinThread::Run() line 487 + 11 bytes
CWinApp::Run() line 400
AfxWinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char *
0x001423de, int 1) line 49 + 11 bytes
WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x001423de,
int 1) line 30
WinMainCRTStartup() line 330 + 54 bytes
KERNEL32! 77e7eb69()

It appears to be this piece of code in nsWindow::ProcessMessage:

nsWindow* destWindow = GetNSWindowPtr(destWnd);
if (destWindow) {
  return destWindow->ProcessMessage(msg, wParam, lParam,
                                    aRetValue);
}

GetNSWindowPtr() calls Win32 function GetProp() to obtain a pointer to the
nsWindow * pointer associated with the HWND. Unfortunately, the window in
question is in another process so the property exists but the pointer is
invalid. The protection is to add some code to return NULL if the window belongs
to another process.
Keywords: crash, topembed
(Assignee)

Comment 7

16 years ago
Patch follows.
(Assignee)

Comment 8

16 years ago
Created attachment 81038 [details] [diff] [review]
Patch

Brian can you review this please?

This patch adds a check to the mousewheel code to ensure the window belongs to
current instance of Mozilla before calling the nsWindow * pointer on it. This
stops mousewheel crashing when wheeling over a window in another instance of
Mozilla (or Gecko app like MfcEmbed).
Comment on attachment 81038 [details] [diff] [review]
Patch

lose the unneeded whitespace changes and r=bryner.
Attachment #81038 - Flags: review+

Comment 10

16 years ago
Comment on attachment 81038 [details] [diff] [review]
Patch

sr=alecf
yikes!
Attachment #81038 - Flags: superreview+
(Assignee)

Comment 11

16 years ago
Fix checked into trunk. Nominate for branch.

ADT summary - Low risk, big win. Stops crashes while mousewheeling when Mozilla
& other embedding apps are running side by side.
Keywords: adt1.0.0, edt1.0.0, nsbeta1

Comment 12

16 years ago
adding adt1.0.0-.  Let's consider this for rtm.
Keywords: adt1.0.0 → adt1.0.0-
Whiteboard: [adt2 rtm]
(Reporter)

Comment 13

16 years ago
Verified.  I do not crash when running the 04-30 trunk mfcembed, and 04-30 trunk
Mozilla build at the same time.

I think we should definitely check this into the branch.

Comment 14

16 years ago
Comment on attachment 81038 [details] [diff] [review]
Patch

a=asa (on behalf of drivers) for checkin to the 1.0 branch
Attachment #81038 - Flags: approval+

Updated

16 years ago
Keywords: topembed → topembed+
(Assignee)

Comment 15

16 years ago
Nominate for adt1.0.0 again.
Keywords: adt1.0.0- → adt1.0.0
Target Milestone: --- → mozilla1.0

Comment 16

16 years ago
adding adt1.0.0+ for checkin to the 1.0 Branch.
Keywords: adt1.0.0 → adt1.0.0+
(Assignee)

Comment 17

16 years ago
Fixed in branch
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Keywords: fixed1.0.0
Resolution: --- → FIXED
(Reporter)

Comment 18

16 years ago
Verified on the 05-16 1.0.0 branch and 05-16 trunk builds.
Status: RESOLVED → VERIFIED
Keywords: verified1.0.0
You need to log in before you can comment on or make changes to this bug.