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

VERIFIED FIXED in mozilla1.0



Embedding: APIs
16 years ago
16 years ago


(Reporter: michael wendell, Assigned: Adam Lock)


({crash, topembed+})

crash, topembed+

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [adt2 rtm])


(1 attachment)

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


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.  

This may sound rather obscure, but I think it is definitely an issue that people
will run into.
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 1131]
USER32.DLL + 0x3eb0 (0x77e13eb0)
USER32.DLL + 0x401a (0x77e1401a)
USER32.DLL + 0x92da (0x77e192da)
[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]
KERNEL32.DLL + 0x7903 (0x77e87903) 
What is crashing : MFCEmbed or Mozilla
is MFCEmbed using the same profile ?
Component: Browser-General → Embedding: APIs

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

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,

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

Comment 7

16 years ago
Patch follows.

Comment 8

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

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]

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

Comment 10

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

Attachment #81038 - Flags: superreview+

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]

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]

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


16 years ago
Keywords: topembed → topembed+

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+

Comment 17

16 years ago
Fixed in branch
Last Resolved: 16 years ago
Keywords: fixed1.0.0
Resolution: --- → FIXED

Comment 18

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