291168 - [BeOS]Submitting some forms crashes the browser

Status: RESOLVED WORKSFORME

(Core Graveyard :: Widget: BeOS, defect)

Description

[tqh]

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.

Comment 1

[tqh]

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.

Comment 2

[tqh]

No, that did not matter.

Comment 3

[timeless]

are you building debug/with symbols?

Comment 4

[tqh]

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.

Comment 5

[tqh]

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

Comment 6

[tqh]

It's still there.

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

Comment 7

[tqh]

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

Comment 8

[tqh]

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.

Comment 9

[tqh]

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

Comment 10

[tqh]

Switched the mView->Window() calls to use 
BWindow * aWin = (BWindow *) info->args[1]; 

instead and so far no crashes or weird behaviour.

Comment 11

[tqh]

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

Comment 12

[Sergei Dolgov]

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? 

Comment 13

[tqh]

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.

Comment 14

[Sergei Dolgov]

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.

Comment 15

[tqh]

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

Comment 16

[Sergei Dolgov]

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.

Comment 17

[tqh]

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

Comment 18

[Sergei Dolgov]

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.

Comment 19

[tqh]

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.