Closed Bug 57582 Opened 24 years ago Closed 21 years ago

bad handling of helper app preferences and files

Categories

(SeaMonkey :: Preferences, defect, P3)

x86
Linux
defect

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.
reassign :mscott
Assignee: av → mscott
This looks like bug 56650 a bit.
Keywords: polish, ui
Moving to preferences component.
Component: Plug-ins → Preferences
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
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.