Closed
Bug 60814
Opened 24 years ago
Closed 24 years ago
[RFE] "Run from current location" feature
Categories
(Core Graveyard :: File Handling, enhancement, P3)
Tracking
(Not tracked)
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. :)
Reporter | ||
Comment 1•24 years ago
|
||
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
Comment 2•24 years ago
|
||
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....
Reporter | ||
Comment 3•24 years ago
|
||
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.
Comment 4•24 years ago
|
||
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
Comment 5•24 years ago
|
||
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?
Reporter | ||
Comment 6•24 years ago
|
||
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.
Reporter | ||
Comment 7•24 years ago
|
||
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
Comment 9•24 years ago
|
||
> 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.
Comment 10•24 years ago
|
||
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
Reporter | ||
Comment 11•24 years ago
|
||
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.
Comment 12•24 years ago
|
||
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
Comment 13•24 years ago
|
||
Reporter | ||
Comment 14•24 years ago
|
||
Comment 15•24 years ago
|
||
sorry, reopening. this is either a dup or a blocker of bug 59932.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Comment 16•24 years ago
|
||
Reporter | ||
Comment 17•24 years ago
|
||
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.
Comment 18•24 years ago
|
||
ok, so this should be marked as a dup of bug 42015 again?
Reporter | ||
Comment 19•24 years ago
|
||
42015 is acceptable, but not the 59xxx bug. There's a lot of valuable
conversation here though that people visiting 42015 need to read.
Comment 20•24 years ago
|
||
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.
Comment 21•24 years ago
|
||
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 ago → 24 years ago
Resolution: --- → DUPLICATE
Comment 22•23 years ago
|
||
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
Comment 23•23 years ago
|
||
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?
Assignee | ||
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•