If I install the Java plugin in Mozilla, Mozilla will hang at startup. The last thing I see on the console is: Registering plugin 19 for: "application/x-java-bean;version=1.3","Java(tm) Plug-in","" Registering plugin 20 for: "application/x-java-bean;jpi-version=1.3.0_01","Java(tm) Plug-in","" java_vm is running and so is mozilla-bin, but Mozilla never displays a window. It will sit there forever or until I kill it, whichever comes first. I installed Java by installing NS6 and copying the libjavaplugin_oji.so link from its plugins directory to the Mozilla plugins directory. For what it is worth, NS6 will not start either when libjavaplugin_oji.so is present. With it gone, both Mozilla and NS6 run fine. Tested with Mozilla 121414 on Linux (RedHat 7).
*** Bug 63075 has been marked as a duplicate of this bug. ***
I have discovered why Mozilla was hanging with Java installed. Mozilla and Java seem to communicate through a socket. Not a UNIX domain socket. Rather they use a real Internet socket on port 13000 and, as such, were running afoul of my ipchains firewall. I have it set to deny all SYN packets since my machine is just a workstation and not a server of any kind. This prevented java_vm from connecting to the socket on which mozilla_bin was listening. Why is a UNIX domain socket not being used? It seems very bad to me that to use Java, Mozilla must listen to all foreign addresses on a socket at a well known port number. This would seem to invite all sorts of malicious hacking especially since most users will not realize that Mozilla is acting as a server and may not have a firewall setup to protect themselves.
Marking WORKSFORME as per Stephen's comments. As for the question I have no idea. I suggest filing another bug so we can get an official response.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
Created bug 63810 for the socket question.
On second thought, I am going to reopen this bug. Hanging is never an acceptable response to an unexpected condition. Mozilla should detect that it could not open the socket and should put up a message box saying "No Java for you" and explain why. It should then continue load without Java. It definitely should not hang. What kind of user feedback is that?
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Hmmmm ok i fiddled around with the summary and went ahead and NEW'ed. Hopefully we can get an answer on this one. I appreciate the feedback. I am going to ask around and see what I can dig up.
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Mozilla hangs at startup with Java installed. → Mozilla & Java Crashes when port 13000 is blocked by firewall
Target Milestone: --- → mozilla0.8
Adding crash keyword
Just to be clear: neither mozilla nor java crashes. There is a "hang" keyword that would probably be more appropriate than "crash".
Whoops changing to hang :)
Keywords: crash → hang
Steve Katz, the owner of the Sun Java Plugin on Unix, tells me that this bug is due to the fact that NSPR uses TCP sockets by default. If there was a way to get NSPR to use Unix domain sockets, this bug may not persist. Therefore, I'm reassigning this to NSPR.
Component: OJI → NSPR
Product: Browser → NSPR
Target Milestone: mozilla0.8 → ---
Version: other → 4.1
Reassign to NSPR owner.
Assignee: edburns → wtc
QA Contact: shrir → wtc
Assignee: wtc → edburns
Component: NSPR → OJI
Product: NSPR → Browser
QA Contact: wtc → shrir
Version: 4.1 → other
You can create a Unix domain socket as follows: #include "prio.h" #include "private/pprio.h" PRFileDesc *sock; sock = PR_Socket(PR_AF_LOCAL, PR_SOCK_STREAM, 0); /* a private NSPR function */ If you don't like the idea of calling a private NSPR function, you can bypass NSPR and write standard BSD socket code.
Hi Steve, I know you said not to assign bugzilla bugs to you, but this is just to track in bugzilla the bugtraq bug 4409791. When that bug is fixed, you can close this one.
Assignee: edburns → skatz
How do I go about using private nspr functions? Where can I find the header files that define the constants used in the code provided? Is it likly this interface will change in the future? The implementation of PR_SOcket seems to create a NON-BLOCKING socket (as read from the LXR sources in mozilla), is this the case? My understanding is that PS_NewTCP create a BLOCKING socket, is this true? Bypassing nspr seems like a non-starter at this point since it would mean rewritting all the socket code we currently have. Is there a public way to take a socket that already exists and turn it into a PRFileDesc? I could not find such a thing inthe documsntation.
On 12 February 21:56:59, Wan-Teh Chang wrote: > You can only use our semi-private functions. These > functions are declared in headers files under the > "private" directory. The function you need, PR_Socket, > is declared in "private/pprio.h". > > We reserve the right to change our semi-private interface but > in practice it's unlikely to happen. > > > The implementation of PR_Socket seems to create a NON-BLOCKING > > socket (as read from the LXR sources in mozilla), is this the case? > > The PRFileDesc it creates is BLOCKING. The Unix file descriptor > (an int) embedded in the PRFileDesc is NON-BLOCKING. > > The non-blocking mode of the Unix file descriptor used by NSPR > is an implementation detail. If you need to rely on this fact, > that's a problem. > > > My understanding is that PR_NewTCP create a BLOCKING socket, is this true? > > See above. > > Bypassing nspr seems like a non-starter at this point since it would > > mean rewritting all the socket code we currently have. Is there a > > public way to take a socket that already exists and turn it into a > > PRFileDesc? I could not find such a thing in the documentation. > This is also a semi-private function, also declared in > "private/pprio.h". There are actually four of them: PR_ImportFile, > PR_ImportPipe, PR_ImportTCPSocket, and PR_ImportUDPSocket. You can > use PR_ImportTCPSocket to import a Unix domain SOCK_STREAM socket. > Please do not publicize our semi-private interface.
A fix has been made in the ladybird (1.3.1) version of the plugin/jre. This fix has been confirmed by the original submitter (thanks Stephen). The coresponding Sun Bugtraq bug has been updated and I am marking this report as fixed. No changes where required to the Netscape code to implement this fix. I think in the long run it would be a benifit to NSPR if it exposed a public interface to UNIX domain sockets.
Status: NEW → RESOLVED
Last Resolved: 18 years ago → 18 years ago
Resolution: --- → FIXED
*** Bug 63810 has been marked as a duplicate of this bug. ***
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.