Using july10 commercial branch build, mac OS 9.0 Cannot reproduce with linux or win98 Only seen when in classic skin, does not happen on same accounts when in Modern. Steps: 1. Edit|Prefs|Themes. Change to Classic skin, OK/confirm out of alert and prefs dialog. 2. Exit and restart, go to mail window, login to account ( mine was IMAP), let inbox load. 3. Search|Search Mail/News Messages. Type a character or two in the default/first criteria row's text field. Do not press Enter or click Search to engage a search. 4. Click the Close button. Result: Application exits, no talkback, but I do have a macsbug stdlog which I'll attach. Note: Generally closing the search dialog after searching didn't have the same effect. It happens for me only when I close after typing into the text field when there's no results, no previous activity.

More info: doesn't happen on trunk (there was a fix applied to trunk to make it a window, remove close button). Does happen with the Beta1/PR1/june7 branch build.

So it's not reproducable on the trunk, at all?

I'll investigate, navin has a dataloss bug he's working on.

I've got an old trunk build (before 0.9.2) that has this problem. I can reproduce it. debugging now...

laurel, on recent trunk builds, can you reproduce this with the window manager [x]?

No I couldn't.

I'm able to reproduce this, but I've quickly run out of mac debugging expertise. I don't end up with a stack when I crash, which cramps my style. ducarroz, can you take a look?

when I do crash, I get this: "unmapped memory exception"

I'm hitting this on Filters, too. Mac only, today's branch and trunk. Happens when editing in Filter Rules, can't do it in a lot of situations in that dialog, but this case is reproducible: 1. Launch filters where there is an existing filter. 2. Select filter, edit --> opens filter rules dialog populated with previously enetered conditions. (Doesn't matter if it's a filter with lots of conditions or just one existing condition.) 3. Click More button. Place cursor in the text field of the newly added line, type a character then OK the dialog. Boom.

I've kicked off a trunk build, so that I can look into the filter trunk problem. maybe I can get a stack from that crash. ducarroz is going to get his 0.9.2 branch build up, and investigate search.

still building, I'll resume work on this tomorrow.

I can now reproduc this crash with a branch build from last nigh (around 9 pm). Looks like we are crashing while dispatching a DOM event. cc'ing pinkerton and saari in case they have an idea. Investigating...

I can reproduce laurel's filter crash on the trunk. I can't get a stack trace in the debugger (I get that same error), but when I don't use the debugger I get this in macsbugs: Calling chain using A6/R1 links Back chain ISA Caller 00000000 PPC 0C8144DC 0E43A200 PPC 0C7F5ED0 main+001AC 0E43A1A0 PPC 0C7F3120 main1(int, char**, nsISupports*)+00A68 0E439F20 PPC 0C496700 nsAppShellService::Run()+00054 0E439ED0 PPC 0C1CFD80 nsAppShell::Run()+0004C 0E439E90 PPC 0C1D0A1C nsMacMessagePump::DoMessagePump()+00044 0E439E40 PPC 0C1D12B0 nsMacMessagePump::DispatchEvent(int, EventRecord*)+ 000CC 0E439DF0 PPC 0C1D22F4 nsMacMessagePump::DoActivate(EventRecord&)+0006C 0E439DB0 PPC 0C1D2460 nsMacMessagePump::DispatchOSEventToRaptor(EventRecord&, GrafPort *)+00044 0E439D70 PPC 0C1CCA9C nsMacMessageSink::DispatchOSEvent(EventRecord&, GrafPort*)+00048 0E439D30 PPC 0C1C5790 nsMacWindow::HandleOSEvent(EventRecord&)+00038 0E439CF0 PPC 0C1C7144 nsMacEventHandler::HandleOSEvent(EventRecord&)+00070 0E439CA0 PPC 0C1C85D8 nsMacEventHandler::HandleActivateEvent(EventRecord& )+000C8 0E439C40 PPC 0C1C6B18 nsMacEventDispatchHandler::SetActivated(nsWindow*)+ 000C8 0E439BF0 PPC 0C1C67D0 nsMacEventDispatchHandler::DispatchGuiEvent(nsWindow*, unsigned int)+00090 0E439B80 PPC 0C1B4920 nsWindow::DispatchWindowEvent(nsGUIEvent&)+00028 0E439B40 PPC 0C1B4828 nsWindow::DispatchEvent(nsGUIEvent*, nsEventStatus& )+000B8 0E439AF0 PPC 0C49F11C nsWebShellWindow::HandleEvent(nsGUIEvent*)+00960 0E439990 PPC 0BA35604 GlobalWindowImpl::Focus()+00470 0E439880 PPC 0C1B12E4 nsWindow::SetFocus(int)+00018 0E439840 PPC 0C1C69F0 nsMacEventDispatchHandler::SetFocus(nsWindow*)+0009C 0E439800 PPC 0C1C67D0 nsMacEventDispatchHandler::DispatchGuiEvent(nsWindow*, unsigned int)+00090 0E439790 PPC 0C1B4920 nsWindow::DispatchWindowEvent(nsGUIEvent&)+00028 0E439750 PPC 0C1B4828 nsWindow::DispatchEvent(nsGUIEvent*, nsEventStatus& )+000B8 0E439700 PPC 0B635DD4 HandleEvent(nsGUIEvent*)+00064 0E4396B0 PPC 0B64DB28 nsViewManager::DispatchEvent(nsGUIEvent*, nsEventStatus*)+00974 0E4394B0 PPC 0B636FC8 nsView::HandleEvent(nsGUIEvent*, unsigned int, nsEventStatus*, i nt, int&)+0039C 0E439400 PPC 0B6AA3F8 PresShell::HandleEvent(nsIView*, nsGUIEvent*, nsEventStatus*, in t, int&)+00330 0E439360 PPC 0B6AA870 PresShell::HandleEventInternal(nsEvent*, nsIView*, unsigned int, nsEventStatus*)+000F0 0E4392F0 PPC 0BC68CE4 nsEventStateManager::PreHandleEvent(nsIPresContext*, nsEvent*, n sIFrame*, nsEventStatus*, nsIView*)+00718 0E438D00 PPC 0BD0C444 nsHTMLInputElement::HandleDOMEvent(nsIPresContext*, nsEvent*, ns IDOMEvent**, unsigned int, nsEventStatus*)+00AF0 0E438A40 PPC 0BDB0D34 nsGenericElement::HandleDOMEvent(nsIPresContext*, nsEvent*, nsID OMEvent**, unsigned int, nsEventStatus*)+002F4 I'll go look at nsHTMLInputElement::HandleDOMEvent()

adding nsbranch in case we can get a fix.

I get this on mac 8.6, so marking all. no luck with this one yet, still debugging...

pink tells me this is a dup. I'll go search for the bug.

this is almost certainly 87112.

I'll update my mac build and see if it has gone away. (now that 87112 has been marked fixed.) if it does, I'll mark it a dup.

I am running today'e debug build which has the fix for bug 87112 and I am still crashing!

I'll update my mac build and see if it has gone away. (now that 87112 has been marked fixed.) if it does, I'll mark it a dup.

I still crash, even with peter's fix for #87112 peter, does this look like the same bug to you? if so, would you be the right owner?

I just got peter's last check in to nsObjectFrame.cpp. still crashes. mac, classic skin only, following laurel's steps on "2001-07-10 16:13"

With Laurel's steps on 7-10, it doesn't seem likley that this is a dup of bug 87112. You can try setting a breakpoint in nsObjectFrame::DispatchFocus, but since the crah happens in Mail Rules, I can't even see how an nsObjectFrame would be loaded in memory. Laurel's stack is different from the one pasted in comments: Stack Addr Frame Addr ISA Caller 0F6EF6F4 PPC 6806E224 0F6EF6E4 68K 0001ACEA 0F6EF6DC 68K 100CAF60 HGETVOL+FD376 0F6EF6C4 68K 000CC624 0F6EF6B4 68K FFC168E2 _UnimplTrap+01084 0F6EF68C 68K 0070915C 0F6EF688 68K FFC101A4 _CursorDeviceDispatch+01684 0F6EF664 68K 0060D890 0F6EF5BC PPC 1E7E8A54 nsFileSpec::Execute(const nsString&) const+00BC8 0F6EF5A4 68K 0000000A 0F6EF4B0 PPC 1EE02724 NS_NewImageDocument(nsIDocument**)+84D10 0F6EF498 PPC 1E78B77C nsSupportsHashtable::ReleaseElement(nsHashKey*, voi d*, void*)+00020 0F6EF468 PPC FFCF6CA4 LowLevelExceptionHandler+002FC 0F6EF450 PPC 1EE02724 NS_NewImageDocument(nsIDocument**)+84D10 0F6EF3FC PPC 1E7915AC nsCOMPtr_base::~nsCOMPtr_base()+00030 0F6EF3F0 PPC 1EE02724 NS_NewImageDocument(nsIDocument**)+84D10 0F6EF3E4 PPC 1E78B77C nsSupportsHashtable::ReleaseElement(nsHashKey*, voi d*, void*)+00020

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

moving to 0.9.4

peter, thanks for the hint, sorry for the delay. I tried again on my fresh mac trunk build, still crash. I don't see nsObjectFrame::DispatchFocus(), did you mean something else? http://lxr.mozilla.org/seamonkey/search?string=dispatchfocus

using the debugger, I seem to be consistently dying in nsGenericElement::GetBindingParent(), at NS_IF_ADDREF(*aContent); still investigating.

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

pink / saari, I'm going to throw this one back over the wall to xptoolkit, since it isn't XP. if you need help reproducing this crasher, I can stop by. over to saari, since he's running xptoolkit and is a mac / event guru.

Saari is out of the office, so I think this one is gonna have to wait unless Judson reassignes. Propose nsbranch-.

gone

removed keyword nsbranch since bug now has nsbranch-, per pdt mtg.

Seth, it sounds like this isn't a focus issue, correct? I'm doing a build now to get back up to date and I'll give this a whril.

This did not crash for me on a fresh mac build.

Using today's branch builds for both OS X and OS 9.1, I can no longer reproduce the crash in either search or filters. Tried in classic theme (as how originally reported) and also in modern, just in case. Worksforme in current build. If development thinks there still may be a trailing issue here, please reopen.

Marking verified worksforme