User-Agent: Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.8b2) Gecko/20050409 Firefox/1.0+ Build Identifier: Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.8b2) Gecko/20050409 Firefox/1.0+ Some forms after you've clicked 'Submit' causes Firefox to go down with a segmentation fault. I suspect this one to be BeOS specific as the crash can be avoided by, before submitting, focusing another app and then Firefox again. Have not found out what yet. The URL provided (LXR) crashes everytime for me. Reproducible: Always Steps to Reproduce: 1. Go to http://lxr.mozilla.org/seamonkey/ 2. Add a search term 3. Submit Actual Results: Crashes browser Expected Results: Form, submitted. Results shown.

In trying to get the debugger to give me some better stacktrace I made a link from dist/bin/lib to dist/lib and the error vanished. So maybe this is a tricky library issue.

No, that did not matter.

are you building debug/with symbols?

Yes. I suspect the theme I use might be involved, but have not had a chance to confirm it. http://sheltonfamily.org/firefoxtheme/Install.htm is the theme.

After CVS-update I havn't been able to reproduce this. Will leave it a few days and close it if it don't happen during that time

It's still there. It's not related to themes, and it seems to be happening mostly after popup-windows been shown.

Also to point out, as I have a very 'experimental' nsWindow it's the same if I use the CVS one for BeOS.

Well stacktrace shows a nsWindow::CallMethod is doing BView::Window() which seems to fail inside the BView-class. Probably due to the call done during the destruction of the alert-window.

Probably something in CallMethod ONACTIVATE, it gets called twice when I checked and it's the only one calling BView::Window().

Switched the mView->Window() calls to use BWindow * aWin = (BWindow *) info->args[1]; instead and so far no crashes or weird behaviour.

Marking it a Gfx:BeOS bug. As we do for widgets :)

i don't see sense in last change. At least i don't get what happens. Because there is line if((BWindow *)info->args[1] != mView->Window()) return false before all that code, which should guarantee that it is the same window. Only thing may be that both are 0 (if window is gone), but i don't see how it can prevent crash. Actually this code with args[1]==Window() is partially hack, to prevent some focus handling issues. Why hack? Because in theory, CallMethodAsync and SwitchToGuiThreed must guarantee us, that this is proper window, so hack was rather intended to catch case if window is gone. Did you experience it with standard build, or in some wersion where AppShell/Toolkit and/or Destroy methods differ from CVS version? Also, about last thing - why did you change component to GFX while we have Widget:BeOS for half of year at least?

We have widget:BeOS now? That's good. Anyway it crashes inside BView::Window() so it's the calls to Window() themselves that never return null or a valid pointer they crash. The more I think of it I think it's wrong to call Window() there anyway as the window that the invoker refers to is args[1] and Window() might not always be the same as args[1]. So I think it's better to listen to what the invoker of CallMethod says is the proper window than ignoring it.

according to purpose of ONACTIVATE: we should drop any action if those two don't match. If we don't, we'll get problems with focus handling.

Hmm, is that documented somewhere? I'd like to read about it.

No. It isn't. As most such things in Mozilla. When i struggled with focus issues, i asked for help and docs several times - best what i got is answer "look how we did it in ***". And this piece for WindowsActivated() hook handling was implemented by me. Before that it deal purely with View::MakeFocus() hook messages, using several hacks and tricks. Shortly, focus control consist of two messages in Mozilla - NS_ACTIVATE and NS_*FOCUS*. There are lot of problems and tricks there (even well-developed GTK verion suffers from time to time from focus issues, as MS Windows - but less), but most important thing is timing/order of those messages in which it will be received and handled in Mozilla. Actually, NS_ACTIVATE should be applied only and strictly in case where BWindow belongin' to nsWindget is really active. While NS_DEACTIVATE seems to ought working/sent even in case of destructed BWindow - so maybe last case is the issue with your crash.

I think we can close this, we have much better handling in nsWindow now.

actually i still experience similar behaviour when submitting patches to BugZilla. When pressing Browse button second time. But i think maybe it is related rather to our flacky and hacky FilePicker.

That should be another bug (isn't there one about filepicker?), see the steps to reproduce in this bug. The title is a bit vague on this bug though, but I don't have a better title.