Closed Bug 60180 Opened 24 years ago Closed 23 years ago

Crash if setup helper app with extension left blank

Categories

(SeaMonkey :: Preferences, defect, P2)

Product:
SeaMonkey
Component:
Preferences
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME
Milestone:
mozilla1.0

People

(Reporter: scott, Assigned: mscott)

References

(
URL
)

Details

(Keywords: crash) 

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...
Assignee: matt → mscott
Keywords: crash
QA Contact: sairuh → shrir
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Severity: normal → critical
*** 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.
Blocks: 104166
Keywords: nsbeta1+
Priority: P3 → P2
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
QA Contact: shrir → sairuh
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
i don't crash using 2002.02.13.08 comm bits on linux rh7.2.

marking wfm.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
vrfy wfm, unless this can be repro'd with the latest trunk bits.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.