Closed
Bug 57582
Opened 24 years ago
Closed 21 years ago
bad handling of helper app preferences and files
Categories
(SeaMonkey :: Preferences, defect, P3)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: spam, Assigned: mscott)
Details
(Keywords: polish)
2000102021 SEA Linux
If i have preferences for a helper app set to "Ask me before opening downloaded
files of this type", behaviour in mozilla gets utterly weird.
Also, the wording in preferences is misleading. Ask me before opening DOWNLOADED
files..." etc???? What is that supposed to mean? At the time i come across one
of those files it will still NOT be downloaded. So it should instead ask
something like "Ask me to DOWNLOAD files of these types, before opening..."
Well. That is not the worst. When i have this oddball preference checked, moz
gets even more confused when it actually hits one of the helper type files:
A dialog then will pop up stating:
"This file has a mime type audio/x-pn-realaudio and cannot be viewed using
Mozilla. you can open it with another application, or save it to disk."
I have already added realplayer as a helper app, so a radio-button checked for
"Open with" and in the form underneath it states "realplay".
There are two buttons: OK and Cancel.
If i now choose Cancel, the dialog goes away and nothing more happens.
If i choose OK, realplayer wiull start AND a download dialog starts.
The latter is of course redundant.
In addition, it has prefilled in all known file-extentions as suggested filename
and even if i click "Cancel" and dismiss the window, it will save a file to the
/tmp directory
(This is of course wrong. When i have confirmed i want to OPEN the file, no
save-dialog should appear at all.)
After having closed the helper app the Save dialog remains.
Closing the Save dialog before the app is trough with doing whatever it does
does not cause harm, however.
But: After having tested this i found heaps of fairly predictable filenames
scattered around in my /tmp directory:
-rw-r--r-- 1 dark dark 36 Oct 22 06:05 cnnhn.ra,rm,ram
-rw-r--r-- 1 dark dark 36 Oct 22 06:07 cnnhn-1.ra,rm,ram
-rw-r--r-- 1 dark dark 36 Oct 22 06:07 cnnhn-2.ra,rm,ram
-rw-r--r-- 1 dark dark 36 Oct 22 06:07 cnn-1.ra,rm,ram
-rw-r--r-- 1 dark dark 36 Oct 22 06:08 cnn-2.ra,rm,ram
The content of a file was for instance:
dark@localhost dark]$ more /tmp/cnn-2.ra,rm,ram
rtsp://real4.cnn.com/encoder/38922
The last number didn't correspond to any files in tmp.
So it doesn't clean up after itself.
In NC4.* the "old" syntax, according to all helper apps i've tested, was to
add an additional %s after the name of the helper app.
This to ensure the temporary files were cleaned up.
It seemed to be some standard.
However: If i add a %s after a helper app in mozilla preferences, the helper
application will not start at all - it is as if nothing ever happened when i
then click on some link to a file i know a helper app can handle.
So i'm forced to omit the %s for helper apps - and get a cluttered up /tmp
firectory with filenames evil children can easily guess.
This is not a new bug at all - seen it for ages, but for a while now i haven't
been able to add helper files at all due to missing files in packages, so filing
it now, praying it's a dup soon to be fixed :)
There are two bugs in this one; one about wrong functionality, and one about
wrong wording. Regarding the wording in prefs:
It should simply have a checkbox for "Ask before opening files of this type".
That would cover both downloaded and not yet downloaded files. Since a download
also takes place when the content is piped into the helper app, the wording in
prefs shouldn't mention anything a about "downloading" at all.
Comment 5•21 years ago
|
||
Resolving as bittrotted per doron on IRC...
Helper app UI has been reworked at least once since this was reported.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•