There is no notice/feedback/warning when a program/application is started upon clicking a downloaded file

NEW
Unassigned

Status

()

Firefox
Downloads Panel
--
enhancement
6 years ago
5 years ago

People

(Reporter: Aleksej, Unassigned)

Tracking

Trunk
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [testday-20120601] Actual & Expected results are mixed up in #c0)

(Reporter)

Description

6 years ago
2012-06-01-03-05-20-mozilla-central-firefox-15.0a1.en-US.linux-x86_64

Steps to Reproduce:
1. Have an application chosen for a file type for clicking in the Downloads Panel.
2. Download a file.
3. Click an entry in the Downloads Panel.

Actual results:
There is some notice that a program is being started because of the click, then the program starts.

Expected results:
A program starts, quietly.
(Reporter)

Updated

6 years ago
Whiteboard: [testday-20120601]

Comment 1

6 years ago
(In reply to Aleksej [:Aleksej] from comment #0)
> Actual results:
> There is some notice that a program is being started because of the click,
> then the program starts.
> 
> Expected results:
> A program starts, quietly.

If I read this correctly, you're saying that a confirmation message appears before
the program starts. This is expected for some file types, like executable files.

Or is this a different issue?
(Reporter)

Comment 2

6 years ago
Oops, sorry, I mixed actual and expected results up.  It should be:

Expected results:
There is some notice that a program is being started because of the click, then the program starts.

Actual results:
A program starts, quietly.

Comment 3

6 years ago
There's already a preference for this, see "browser.download.manager.alertOnEXEOpen" in about:config. The default value is 'true', you will receive a warning when you start an executable. In that warning, you have a "don't ask" box to shut it off for the future. That would set the configuration value to 'false'.
(Reporter)

Updated

6 years ago
Whiteboard: [testday-20120601] → [testday-20120601] Actual & Expected results are mixed up in #c0
Sorry, I still find unclear what's the bug about, comment 3 seems to explain the correct behavior, is not this what happens?
You need to log in before you can comment on or make changes to this bug.