Closed Bug 60814 Opened 24 years ago Closed 24 years ago

[RFE] "Run from current location" feature

Categories

(Core Graveyard :: File Handling, enhancement, P3)

x86
Windows 98
enhancement

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 42015

People

(Reporter: grey, Unassigned)

References

Details

(Keywords: helpwanted)

After an extensive discussion in netscape.public.mozilla.general, as well as an email discussion that quickly veered towards a discussion of Bugzilla, there seems to be a desire/need for Mozilla to have the ability to have a feature that allows a user to click a link to an executable program file, and run the program without additional user intervention, as Internet Explorer can do. I don't propose to replace the way handles links or anything drastic, nor to allow Mozilal to download and run EXEs without permission. I'm proposing to add a feature where, IF THE USER DECIDED to have Mozilla act like IE, when they click a link to a program, Mozilla can present them with the option to download it and save it to the disk, or to download the program and then run it immediately. I'm also volunteering to take this upon my self to implement. Let it no tbe said I'd make someone else do something I am unwilling to do myself. :)
I don't think I was explicit enough. After reading more posts on the topic, I'm going to be a little more detailed. This will be a feature that I propose to be OFF by default, but can be enabled. When they turn it on, a warning pops up. From then on, whenever they DL a program, a dialog will pop up asking them if they want to run it or just DL and save. If they choose to run it, another warning will pop up, explicitly detailing the possible ramifications, and giving them the ability to save it to disk instead, or to proceed. As far as what I plan, the warning page WILL NOT BE AN OPTION. You can choose to turn on this option, but then you have the warning. Now, maybe I'm being a bit totalitarian, but I won't write the warning to also be disabled. I don't like the way IE does it, and if I do it, I will do it right. My stance inthe newsgroup was this: it's open source. If you want to make the warning able to be bypassed, fine, that's your sin, I won't do that. Read this, review it, ask questions if you have them, and feel free then to assign this bug/RFE to me. Grey Hodge / jesus X
Grey, Will the behavior for local files (file:// urls) be the same as for remote files? There have been some requests for file manager functionality in Mozilla, and this seems like it could subsume said file manager functionality. The only difference is that the "mandatory dialog" may be unnecessary for local files....
Since Mozilla already has a very nice file:/// and ftp:// browsing ability, I can add some simple location checking ability to bypass the warning. That will be separate, since initially I was planning on ignoring file:/// URLs. one way or another, I won't force it on local files, I was only referring to remote files. The problem with now introduced would be for remote drives mapped as local drives. I'll have to think about that aspect... I loathe the idea of opening accidental security holes via features. file:/// handling will be a separate issue, set aside for now.
Boris: your 59932 is pretty similar, want to dupe that to this? seting helpwanted, assigning to nobody until you decide you really want to implement
Assignee: asa → nobody
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: helpwanted
Well, that's why I asked my question. This RFE is for automatically running files you download (with a little warning dialog). Bug 59932 is about running local executables. While the two can be implemented together, it looks like the plan is to do the remote thing and then worry about extending it to local files. So I would like to keep 59932 open unless Grey decides that he definitely wants to subsume it into this bug. Grey?
I'd leave the other bug either as OPEN or mark it LATER. My primary focus with this RFE is for remote files. I'm sure it won't be hard to extend it to local files, but bug 59932 deals not only with running local executables, but local file management as well. What I gather from the discussion in the other bug, relating it to IE's local browsing abilities, would be the ability to run EXEs, load data files, and do things similar to Windows Explorer. I'm hesitant to do all that for two reasons. I'm not familiar enough with the other two main platforms (Mac, Linux) to know how they should be handled, and I strongly believe in the Mozilla project's aim to be a nearly platform agnostic Internet development platform and fear too many Windows only features could dilute that. File management can be done as a separate Mozilla add on, but I think is beyond the scope of this bug. My plan is to allow the execution of remote programs like IE does (with a much more clear warning), and then look into the possibility of extending it to local files. As I said, I'd leave it open, or mark it LATER.
I'm ready to accept it, if no one has any objections.
Before you do this, please clarify a few conditions for me. Thanks in advance. 1. How do you detect an application? or What is an application? a. application/octet-stream, application/binary-stream, application/x-binary, b. By binary extension: .exe, .com, .scr c. By macbinary type: APPL, APPC, APPD, APPE, d. Scripts in no particular order: .pls, .bat, .sh, .shar, .cmd e. win32 binaries, win16 binaries, dos, elf binaries, a.out, As a general rule, I can't imagine linux/unix users wanting the ability to run binaries from the internet, most often they would download packages (.rpm, .deb, .tar.gz, .tgz) which would either be sent to a package manager (rpm, apt) or some command line apps beyond which the user would need to make decisions. wrt macos, most apps would be distributed in as .SIT (Stuffit Archive), .SMI (Self Mounting Image), .SEA (Self Extracting Archive), .CPT (CompactPro Archive). Some of these formats (.sea) don't survive pc's and would need to be flattened before transfer so they'd be encoded as .hqx (BinHex) or .bin (MacBinary). A quick survey of macintosh users resulted in a response from a developer akin to the linux/unix perspective. Another thing to consider: Even the win32 world is shifting away from using applications to install programs, towards data packages (.msi, .zip). Many applications are command line based and need parameters, running them would be useless. 2. To all concerned users: Why do you want this feature, is it because you have no way of running installation programs directly? Another concern is that under windows2000 you usually need to switch to installation mode before running installers. Mozilla should not do this for things like this feature (that would be a HIGH security risk), and therefore this feature is propobably relatively useless for windows2000. In these cases, simple evangelism to application distributors, requesting that they switch to .jar (java archive), .xpi (cross platform installer), .zip (zip archive), .cab (cabinet), .cat (catalog) or .msi (microsoft installer).
Severity: normal → enhancement
> c. By macbinary type: APPL, APPC, APPD, APPE, Just a comment here: APPCs are control panels, which you probably wouldn't be distributing standalone anyways. And appe (all lowercase) indicates a background-only application, which you absolutely don't want to automatically launch. And on the Mac, most installers are brain-dead in the sense that they want you to quit every application to install, and reboot when they're done, even when it's not really necessary. I hate these things enough when I have to run them. I don't want Mozilla running them for me too.
I think the first questions are good and need to be answered. However, the rest of you comments are completely unfounded. Linux: On Linux, RPM/DEB is the way to go for 90% of downloads. However, for complex applicaitons that will have multiple RPM's, an installer is much preffered. MacOS: I can not comment on MAC since it completely confuses me. Windows: Data files are good for non-interactive installs. Any install that is realativly complex needs an .exe installer. Have you even run Win2K? It behaves no different than any other windows. The installer mode is for non- admin users and is completely handled by the OS. Mozilla does not have to worry with it. Below are a list of vendors who would probably like an option to run the file directly from the browser because they still use .exe installers. I could have listed thousands, but I picked the first few I thought of. I have yet to find anyone using .zip. Linux does use a lot of RPM and .tar.gz, but this is fine. Netscape 6 - N6Setup.exe Winamp - winamp27_full.exe Real Audio - rp8-standard-u1-setup.exe Helix Gnome - lynx -source http://go-gnome.com/ | sh
Win32: A. I'm not planning of supporting scripts of any type, flat out. B. EXEs only will be supported. .COMs are rarely used, and I'venever even seen a Win32 .COM C. No one writes Win16 apps anymore, but if they do, and it's an .EXE and the user wants to run it, then they do. Mozilla doesn't currently run on a Win16 platform anyway, and frankly, I don't care about Windows 3.x anymore. Mac: I don't have knowledge of the Mac platform to do anything there. Linux: Ibid. And I don't think most Linux users like it when their machines do things they don't tell them to do. Once I get the Win32 implementation running, I'll be glad to accept help on adapting it to Linux and/or Mac. > 2. To all concerned users: Why do you want this feature, is it because you > have no way of running installation programs directly? No, it's because for setup programs that download their data over the net (NS6Setup, MS installers, etc.), it's a handy feature. > In these cases, simple evangelism to application distributors, requesting that > they switch... Another example: GRC.com has a neat feature of scanning your IP for you. Some people need to DL a program called IPagent.exe which helps the site determine your IP correctly under certain odd circumstances. It makes sense to just run this without long term storage concerns. And remember: You don't have to use it if you don't want to.
looks like a dup of bug 42015, "[RFE] Ability to run .exe files from webpages" *** This bug has been marked as a duplicate of 42015 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
The stated intent of the filer of bug 42015 is to allow running a file off a local CD. That would seem more like what's covered in bug 59932. So perhaps 42015 and 59932 are dups. I don't think that this is a dup of 42015.
While similar, if not a dupe (albeit a more well defined dupe) of bug 42015, it's not a dupe of bug 59932. 59932 is a theoretical extension of this one and bug 42015 into local browsing and execution. I'd consider it an RFE of this RFE. =-]
sorry, reopening. this is either a dup or a blocker of bug 59932.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
After looking at this some more, I think that bug 42015 is for running installers from webpages, and bug 59932 is for running local programs. What's this bug for?
This is for the ability to run Executable files, like 42015. 42015 not really about running installers, since installers are just EXEs like any other program, but the focus of both of these bugs. I'm just not limiting my terminology to a subset of a file type.
ok, so this should be marked as a dup of bug 42015 again?
42015 is acceptable, but not the 59xxx bug. There's a lot of valuable conversation here though that people visiting 42015 need to read.
You could also dup 42015 against this one. The rule about duping newer against older can be bent if the newer bug has more useful information.
Bug 42015 has more technical discussion and is "assigned", so marking this bug as a dup of 42015 again. *** This bug has been marked as a duplicate of 42015 ***
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → DUPLICATE
Blocks: 42015
VERIFYING: they are similar enough. The feature is complicated by the differences in OS (what is an application in <insert OS>?) -> file handling
Status: RESOLVED → VERIFIED
Component: Browser-General → File Handling
If I could suggest a couple things: 1- The difference between a "remote" file and "local" file is based on the browser's world view. File URLs, including mounted file servers (NFS, SMB, AFS, etc.) is effectively local b/c it comes from the OS. HTTP, FTP, gopher, etc. are remote, b/c the browser has to make a network connection to someplace else. 2- Create a separate bug for each OS on for defining an "application". There are too many differences, and everything is interlaced in a single bug here. 3- If the person who marked the block/depends relationship to 42015 is still here, since these are now dupes, perhaps it should be removed?
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.