Mozilla and Haiku-OS kernel kit - who's guilty?
That's again about misterious bug described in ticket 2049 - where launching some Gecko-based app instantly closes another running at the moment.

I got fix for that, at Mozilla code level, but actually this is Haiku problem - or feature?

We use for internal Mozilla communication BeOS ports,
and to have access for those ports from different components and threads we assign to ports name, which must be unique.
For that purpose we're using "current thread" identifier printed in octal form as port name - at stage of port creation. Then when we need somewhere to communicate, we are getting port by find_port - again, using portname created from current thread "number.
- see
http://lxr.mozilla.org/mozilla1.8/source/xpcom/threads/plevent.c#382
http://lxr.mozilla.org/mozilla1.8/source/widget/src/beos/nsAppShell.cpp#122
http://lxr.mozilla.org/mozilla1.8/source/widget/src/beos/nsToolkit.cpp#93

To get current port ID we use methods PR_GetCurrentThread() from NSPR (NS runtime kit):
http://lxr.mozilla.org/mozilla1.8/source/nsprpub/pr/src/bthreads/btthread.c#417

and there is something wrong. I'm not so competent yet to analyze btthreads code, but once I replaced all calls for PR_GetCurrentThread() in 3 places mentioned above,
plus this one (NB!!!, may be quite important, as it uses another PR method - mGuiThread = PR_CreateThread(PR_SYSTEM_THREAD,*)):
http://lxr.mozilla.org/mozilla1.8/source/widget/src/beos/nsToolkit.cpp#231

with simple native find_thread(0) - all started to work as "expected" in Haiku - mozilla apps can now run simultaneously.