From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; m18) Gecko/20001108 BuildID: 2000110808 Setting up realplay as a helper app but leaving the extension field blank crashes Mozilla on encountering content of the MIME type specified. Reproducible: Always Steps to Reproduce: Set up realplay to handle the MIME type audio/x-pn-realaudio in the prefs Fill in every field except the extension Loading a page that contains the Real content. Actual Results: Mozilla crashes (disappears) Expected Results: Opened realplay (or complain when extension field left blank)

hmmmm, helper app issue, methinks...

I've tried this with acroread (not setting the file extension) and the helper works just fine. This is probably a dup of one of the other Real-related crashes. Reporter, do you get the crash if you _do_ fill in the file extension?

It doesn't crash if I do fill in the extension(s).

confirming bug.

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

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

any update?

hm, as with bug 69864, i wonder if bug 82798 is related...methinks the more recent one would be a dup --ie, 69864 and 82798 are prolly dups of this one...

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

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

hm, i cannot seem to repro this crash [i've realplayer installed, even tho' audio doesn't work on my linux box :-P]. i have a realplayer helper app that has no extension --mind you, i had to use audio/x-pn-realaudio-plugin for the mime, if that makes a diff. tested on linux, 2001.06.04.08 trunk bits and 2001.06.04.09 branch bits. how is this for other people on win32 or mac, with other applications?

email from mozilla contributor re: this bug: -------- I suppose they may have fixed it, if your using a cvs version of mozilla it would seem to suggest this, however This bug is reproducable 100% of the time on my machine. Usually what I try to set up is xmms with audio/x-mpegurl mimetype. It's not really a big thing since I can supply an m3u file extension and all works well. However the fact that mozilla goes down completely is a huge flaw in the code, and very frustrating to a new user who has no idea how to proceed when mozilla crashes on such a mundane and normal task. This one bug is pretty much the reason I don't use mozilla as my main browser. Plus there are some mimetypes that don't have a default extension, this was the problem I ran into. I've come to realize that the file extension truly isn't that important and you can just supply one that the view program will recognize, but this is still in my mind a pretty huge flaw. I'm using debian linux (about woody equivelent, probably a little above in some areas, and below in others), with kernel 2.4.3. I've seen this bug manifest itself on several different setups of debian, including all the revisions of the 2.2.x kernels I've run, and under redhat 7.x. I can't remember off hand if I ever ran a recent version of mozilla under redhat 6.x. I'm glad mozilla doesn't crash in this manner for you, but it does for me, and it does for other people as well, (the multiple bug reports to that effect are evidence enough). I don't know how a mozilla developer could miss this one, I beta tested the software for 30 minutes and ran into it as soon as I tried to set up an external viewer program which is one of the most basic things I do. I then spent the next couple of days on and off trying to figure out the pattern. The application handling code could stand to be a heck of alot more robust in the sense that it should either accept a greater range of user input without getting confused, or it should limit the user input with builtin checks or both.

There was a recent fix to Linux crashing for a similar problem. I got here via bug 82798, which was marked Windows+Linux. Can we get a check of the affected OS' reported here + see if Linux users are fixed with a branch daily build?

There was recently a fix to the MIME system in bug 97970 which prevents a crash in very similar circumstances. The GetFileExtentions() method would return an uninitialized pointer and an "OK" error code, so someone could attempt to dereference the pointer.... Once 0.9.5 is out (or with a current nightly), could someone who was seeing this crash before please retest? There is a good chance it is fixed by that checkin.

Is this really a nsbeta1+, P2? If yes, then we need to try and schedule before M1.0.

Has anyone been able to reproduce this lately? I'm fairly certain that fixing bug 97970 fixed this.

helper app-> sairuh

i don't crash using 2002.02.13.08 comm bits on linux rh7.2. marking wfm.

vrfy wfm, unless this can be repro'd with the latest trunk bits.