Build: 09-06-08-M18 commercial build: Crash when sending messages from AOL mail account 1) Login to a new AOL mail account 2) Tried to send messages from this AOL mail account 3) Actual Results: Crash Expected results: Should send messages successfully without crash.

Adding keywords: crash, regression, nsbeta3 Talkback ID: 16989034, 16990252 16990252: Stack Trace 0x00000000 nsMenuPopupFrame::GetNearestEnclosingView [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsMenuPopupFrame.cpp, line 226] nsMenuPopupFrame::GetWidget [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsMenuPopupFrame.cpp, line 1181] nsMenuDismissalListener::GetSubmenuWidgetChain [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsMenuDismissalListener.cpp, line 119] nsWindow::DealWithPopups [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 801] nsWindow::WindowProc [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 860] USER32.dll + 0x19d0 (0x77e719d0) USER32.dll + 0x1982 (0x77e71982) ntdll.dll + 0x163a3 (0x77f763a3) USER32.dll + 0x1bd8 (0x77e71bd8) nsAppShell::Run [d:\builds\seamonkey\mozilla\widget\src\windows\nsAppShell.cpp, line 95] nsAppShellService::Run [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 379] netscp6.exe + 0x17a7 (0x004017a7) netscp6.exe + 0x1230 (0x00401230) netscp6.exe + 0x2918 (0x00402918) KERNEL32.dll + 0x1ba06 (0x77f1ba06)

I vaguely remember sending pinkerton a bug that had the same crash a while ago in nsMenuPopupframe::GetNearestEnclosingView. cc'ing him. Maybe that bug is back.

I'm wondering why it matters if it's an AOL account? Crash is in popup menu area? Strange.

Peter, looks like this is in menus. Can you reassign?

->pinkerton, nsbeta3+, p1 for M18, assuming this is reproducible.

FYI: Sending with my AOL account is working without a problem using NT4 build 2000-09-07-04M18.

Karen, were you able to reproduce this, or was it one-time?

yesterday's build seems fine, but.... I just got Talkback 17103918 again on today's 09-08-08-M18 commercial build: Stack Trace 0x00000000 nsMenuPopupFrame::GetNearestEnclosingView [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsMenuPopupFrame.cpp, line 226] nsMenuPopupFrame::GetWidget [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsMenuPopupFrame.cpp, line 1181] nsMenuDismissalListener::GetSubmenuWidgetChain [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsMenuDismissalListener.cpp, line 119] nsWindow::DealWithPopups [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 801] nsWindow::WindowProc [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 860] USER32.dll + 0x19d0 (0x77e719d0) USER32.dll + 0x1982 (0x77e71982) ntdll.dll + 0x163a3 (0x77f763a3) USER32.dll + 0x1bd8 (0x77e71bd8) nsAppShell::Run [d:\builds\seamonkey\mozilla\widget\src\windows\nsAppShell.cpp, line 95] nsAppShellService::Run [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 379] netscp6.exe + 0x17a7 (0x004017a7) netscp6.exe + 0x1230 (0x00401230) netscp6.exe + 0x2918 (0x00402918) KERNEL32.dll + 0x1ba06 (0x77f1ba06)

This bug used to be reproducible on 09-06-08-M18 commercial build. But, it seemed that I got the crash from the first time of AOL clean profile for today build, and after that I couldn't reproduce this crash again......probably already fixed along with other bug.....

Wait! I got a crash again talkback 17111759, it seems this is intermittently problem.....it all crash at the same place (when trying to enter the subject for sending messages from the compose window, it crash)

Karen - do you crash sending or entering the subject? You last comments talk about entering the subject and crashing.

Yes. It crash when entering the subject of the compose window, updating the summary. Change QA contact to me and Ccing Esther.

I am seeing this problem on a non-aol account using these builds. Linux (2000-09-11-08 M18) Mac (2000-09-08-20 M18)

Karen, fenella is seeing something like this on linux and mac with non-aol accounts. If you are seeing this on non-aol accounts too, please remove the AOL reference in the Summary

Removing the AOL from the summary since I did see this problem is also occurring on non-AOL account. Changing component to Composition too.

ok, i need a specific list of steps to reproduce this. i can't seem to.

PDT agrees p1

I can't reproduce this. Could someone who has experienced this crash please outline explicit steps to reproduce. (Also, if it is intermittent, can you provide a ballpark number: is it one in three, one in ten, etc., ..., or is there some magic step that you hadn't noticed you were doing).

There is some talkback data at bug 44606, with further possible steps to reproduce this (although some of the talkback reports are e.g., Karen Huang, duplicating the reported crash).

By using 09-11-08-M18 commercial build: I got 3 times crashes of 8 times for typing the subject of the compose window. Scenario is: When mouse click & cursor on the subject, not even type the subject yet will get the Crash right away. Stpes for reproduce the problem: 1) Login to a new IMAP mail account 2) Select the New Msg button from the toolbar 3) Mouse Click "To: " entry field and display the cursor. 4) Type in the recipient email address 5) Mouse Click "Subject:" entry field and tried to type in the subject 6) Actual Results: Crash is occurring, don't even type in the subject yet. Expected results: Shouldn't get the crash before type in the subject. I got 4 times Talkback today, but only saw ID 17296395, 17296699. You can also see the talkback reports by search from my email address as well.

Karen - can you set up a time with pinkerton or jrgm and show them on their machines?

Linux (2000-09-12-08 M18) Mac (2000-09-12-04 M18) Win32 (2000-09-12-09 M18) I see this happen on Linux and Mac too. But do not see it on Win32.

Yes. I did try on today's build 09-12-09-M18 commercial build again: It seems that it's more easier to catch this crash on Linux platform for today's build. I got two times out of four times on Linux: talkback 17300605 & 173002255. But did not get the crash on windows yet for today's build. Updating the platforms to ALL. Let me know if you still cannot reproduce it on Linux platform, I can show you again.

After the crash, got the error occurred on the console as following: --------------------------------------------------------------------- ComposeLoad from XUL Compose: ComposeStartup [preselectid=id1] [format=0] [type=0] [nsIMsgIdentity: id1] Created editorShell [nsIMsgIdentity: id1] Created editorShell editor initialized in HTML mode failed to get command manager number 3 failed to get command manager number 2 Registering commands Have Find = true Have SpellChecker = true args newshost = undefined An error occurred updating the cmd_removeList command An error occurred updating the cmd_removeList command An error occurred updating the cmd_removeList command set focus on the recipient JavaScript error: line 1: uncaught exception: [Exception... "Component does not have requested interface" code: "-2147467262" nsresult: "0x80004002 (NS_NOINTERFACE)" location: "<unknown>"] Gdk-CRITICAL **: file gdkwindow.c: line 1479 (gdk_window_get_origin): assertion `window != NULL' failed. Gdk-CRITICAL **: file gdkwindow.c: line 1390 (gdk_window_get_size): assertion `window != NULL' failed. --------------------------------------------------------------------------------

ok, i've managed to dupe this on win32, here's the summary: - requires the email autocompletion to be turned on (isn't it off by default?) - it's timing related fer shure if the planets are in alignment, we get into a case where we've shut down the autocomplete widget (destroyed the native widget) but gRollupWidget is non-null. As a result, we try to see if the mouse cursor is in this non-existant widget and roll it up (maybe we will, maybe we won't, the values are garbage by this point). Since there is no widget, we die. it's pretty hard to get into this situation, and since it's timing related, it's very hard to track down, and even harder to duplicate when i'm trying. This will easily take me another 2 days to fix. HELP!

I believe that autocomplete is turned on by default. cc: selmer in case he has a resource available to help on this one :-)

I have a feeling that the widget is getting Destroy()ed and not fully released. While I'm having a hard time reproducing this bug, I bet this should fix the problem.

Linux (2000-09-15-08 M18) Win32 (2000-09-15-08 M18) Mac (2000-09-12-04 M18) I do not see this problem in the non-AOL account.

David Baron pointed out on related bug 44606 that this bug is "Netscape Confidential". Surely after shipping two Preview Releases with support for AOL mail accounts, that can't be any reason to consider this a confidential bug. Please remove the Confidential restriction (or explain to me why this must be Confidential).

this bugs has nothing confidential in it, opening to the public to see if anyone can help me dupe it....

We need to nail this sucker. I spoke w/ mscott briefly about this a few days ago. I'm inclined to change the summary to "crash when composing mail." I'm guessing this crash is focus related (not aol account related at all) and that it has nothing to do w/ the subject field. I've filed maybe 30 talkback reports (yes, I'm that bullheaded, maybe someone can get stack info from the talkback server w/ reports having my email addr in them?) against this. Here's what I'm seeing (to make it even more fun, it's itermittant). I'm using IMAP. 1. Compose a new message (or reply to one, either way bring up a compose window). 2. Enter a recipient, a subject, or body text, or use the ctrl+arrow keys to navigate the text. 3. Crash sometimes in any of #2's steps. I believe this is focus related. I'm using linux (today's build from release is crashing too).

cc saari

valeski: every time i've seen someone repro this bug, it was because of the address autocomplete popup. had nothing to do with the subject line or any other part of mail. is that what you're seeing? or are you seeing something different?

Adding JF to CC.

pink, it's probably the popup. maybe after the autocomplete popup comes up I'm able to give focus to other fields before a "bad event" get's processed that was generated by the popup. :-/

PDT marking nsbeta3-, nominating for rtm

adding [@ nsMenuPopupFrame::GetNearestEnclosingView] for topcrash tracking.

rtm+ need info

jud doesn't see this any more...does anyone else? Is it that big of a deal?

I did a query on climate for stacks containing GetNearestEnclosingView since 09/15 (chosen arbitrarily). I got one: http://cyclone/reports/singleincidentinfo.cfm?dynamicBBID=18281778 Can you confirm that, Jay? Otherwise ...

I tried on 10-05-09-MN6 build for 10 times and haven't get a crash for this problem yet....

The stack signature for this crash shows up as 0x00000000 in the talkback data...but I haven't been able to find more then just a few entries in the latest reports. Here is all I found: 0x00000000 95d0d978 line Build: 2000092909 CrashDate: 2000-09-29 UptimeMinutes: 271 Total: 271 OS: Windows NT 4.0 build 1381 URL: Comment: Detailed : http://climate/reports/incidenttemplate.cfm?bbid=18281778 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=18281778 0x00000000 b4418bf8 line Build: 2000092909 CrashDate: 2000-10-04 UptimeMinutes: 291 Total: 291 OS: Windows NT 4.0 build 1381 URL: Comment: Detailed : http://climate/reports/incidenttemplate.cfm?bbid=18496250 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=18496250 And just so you know, we don't keep crash reports in the database for more than 10 days, so if the crash was reported more than 10 days ago, chances are you won't find them in the query. But as far as I can tell, this no longer seems to be a topcrasher.

well then, i'm taking the initiative here...

What Mike really meant is "rtm-/future" We won't hold release for problems we can't reproduce.

*** Bug 44606 has been marked as a duplicate of this bug. ***

I'm not able to reproduce this in 6 tries on my debug branch build

Asa says that i have a bunch of incidents that match this. I was playing w/ DnD in the personal toolbar. No mail launches.

This crash is still occurring in some form in the latest trunk builds. Here are a few recent entries from Talkback: 0x00000000 9bd19666 line Build: 2001043015 CrashDate: 2001-05-02 UptimeMinutes: 9 Total: 397 OS: Windows NT 5.0 build 2195 Detailed : http://climate/reports/incidenttemplate.cfm?bbid=29928315 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=29928315 (29928315) URL: http://www.mynetscape.com (29928315) Comments: clicking in editor instance of compose window 0x00000000 9bd19666 line Build: 2001043015 CrashDate: 2001-05-02 UptimeMinutes: 253 Total: 388 OS: Windows NT 5.0 build 2195 Detailed : http://climate/reports/incidenttemplate.cfm?bbid=29927506 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=29927506 (29927506) URL: http://www.mynetscape.com (29927506) Comments: replying to a simple plaintext msg w/o a subject Adding topcrash keyword since this has potential to be a topcrash if it continues to crash trunk builds. Adding qawanted keyword. Can QA try to reproduce this with the latest builds?

this has become a top crasher for me in recent builds. =( I think an easy way to reproduce this is something like the following: 1) bring up the compose window 2) type in an intial email address on the first line and hit enter 2) click on the editor body and try to type some text 3) Usually we get confused and that text is showing up on the next line in the address widget. 4) click on the addressing line with the mistyped text and delete it then click back on the body. 5) At this point I think a timer is going off to show a popup for what was orignally typed in the addressing widget. But the enclosing view was deleted when the addressing widget lost focus and you clicked back in the editor body. 6) crash.

trudelle/pinkerton - with mscott's steps, are you able to reproduce this bug now?

Er, I'll take his word for it ;-) ->0.9.1/P1/Critical, clearing whiteboard, old keywords.

I saw this several times on yesterdays win32 build on win2k.

no matter how much i try, i still can't repro this on win2k

Karen or Esther - when you get a chance, do you want to try to reproduce this on pinkerton's win2k system? Thanks.

trying both debug and opt builds form 5/21, i can't repro this. in fact, going through the debugger, i can't see any place way where we've started popup creation but don't call captureRollupEvents(PR_FALSE...) to clear out the widget. i guess the patch that pav provides might save us eventually since obviously something else is wrong. it shouldn't hurt, i'll make sure it doesn't make anything worse and check it in.

Pink: You should see if Pav's patch also fixes bug 30841. If it does, feel free to reassign to yourself and mark fixed... r=dr on the patch, though I've never seen the problem.

just attached a slight tweak of pav's original patch. can someone who has been seeing this problem try out said patch? needing r/sr since i think this is a good idea anyway, regardless of the outcome of this bug. better safe than sorry.

got sr from hyatt

r=saari.

a=blizzard for 0.9.1

ookies. fix checked in. please reopen if you see this in builds starting with 5/26/01.

In fixing the bustage when this patch landed, there was an NS_REINTERPRET_CAST checked in. While in this case that cast will do the right thing, it won't necessarily do so in the future -- it depends on nsIWidget being the first base class of the first base class of nsWidget. Any chance of changing it to an NS_STATIC_CAST, or getting rid of it altogether (and perhaps removing the .get() too?). I'm always interested in error messages related to operator== with nsCOMPtrs, if anyone still has the errors.

dbaron, i too would have prefered a static_cast, but since I was playing blind with the compilers, I went straight to the reinterpret_cast to make sure it compiled. If someone can help me try static_cast on hpux/irix, I'd love to change it as you're absolutely correct about this not being future-proof.

I actually cannot reproduce this original problem after 2000-10-06 (see my 09:38 comments), even on the latest (05-25-09-trunk)build before Mike's checkin...... But, I still verify on all the platforms to confirm that there were no crashes with this fix: WinNT 05-30-06-trunk - No crash Linux 05-30-08-trunk - No crash Mac 05-30-11-trunk - No crash Marking as verified. If someone sees this crashes again, please reopen this bug.....