[trunk] The dialog that opens when clicking a link to an .exe file has no radio button selected by default. This leads to a useless download!

VERIFIED FIXED

Status

()

--
minor
VERIFIED FIXED
15 years ago
11 years ago

People

(Reporter: norbert.notz, Assigned: aaronlev)

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.8a3) Gecko/20040816 Firefox/0.9.1+
Build Identifier: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.8a3) Gecko/20040816 Firefox/0.9.1+

- (left) click a link that downloads an exe-file:
A window as you can see in the first attachement appears. There no radio-button
is selected!

- confirm with OK (while now radiobox is selected):

When the download has finished the error message you can see in the second
attachement appears!
The user has downloaded the file but cannot use it. I think this makes this bug
"major".




(Please note that I have found this bug with a latest-trunk nightly under
Windows 95. I have not
tested other builds.
I found this problem under Windows 95 but I guess that also other operating
systems are affected.)

Reproducible: Always
Steps to Reproduce:

Actual Results:  
No radio-button is selected. This leads to the error message.

Expected Results:  
I think that the "Save to Disk" radio-button should be selected by default to
avoid this problem.
(Reporter)

Comment 1

15 years ago
Created attachment 156325 [details]
window that opens after clicking an exe-link
(Reporter)

Comment 2

15 years ago
Created attachment 156326 [details]
error message that appears after downloading if no radio-button has been selected

Updated

15 years ago
Flags: blocking-aviary1.0?
(Reporter)

Updated

15 years ago
OS: Windows 95 → Windows XP

Comment 3

14 years ago
WFM: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10

Please reopen if you can confirm with Firefox 1.0 PR or newer. If it doesn't
work, then try a clean profile too. If you are seeing this bug only on Windows
95, then please don't reopen. Windows 95 not supported by Firefox.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME

Updated

14 years ago
Flags: blocking-aviary1.0?
OS: Windows XP → Windows 95

Comment 4

14 years ago
This doesn't exist on the branch, but it has been on the trunk (as was
originally reported).

I see this all the time and reconfirmed it today with the 20040918 build (fresh
install/new profile).
Severity: major → minor
Status: RESOLVED → UNCONFIRMED
OS: Windows 95 → Windows XP
Resolution: WORKSFORME → ---
Summary: The window that opens when clicking a link to an exe-file has no radio-button selected by default. This leads to a useless download! → [trunk] The window that opens when clicking a link to an exe-file has no radio-button selected by default. This leads to a useless download!
Version: unspecified → Trunk

Updated

14 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 5

14 years ago
Ah, my bad. For whatever reason I didn't realise this was a trunk-only problem.
I guess I didn't pay enough attention to the UA. Merging 1.0 branch to the trunk
is going to be a nightmare.
This bug is still present in the 12/05/2004 trunk builds.

Updated

14 years ago
Summary: [trunk] The window that opens when clicking a link to an exe-file has no radio-button selected by default. This leads to a useless download! → [trunk] The dialog that opens when clicking a link to an .exe file has no radio button selected by default. This leads to a useless download!

Comment 7

14 years ago
Error: setting a property that has only a getter
Source File: file:///C:/PROGRAM%20FILES/FIREFOX/components/nsHelperAppDlg.js
Line: 484

This was broken by the patch in Bug 244624 which made <menulist>.label read-only.

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/mozapps/downloads/src/nsHelperAppDlg.js.in&mark=560#557

Comment 8

14 years ago
Aaron, the previous comment says your patch from bug 244624 caused this regression.
(Assignee)

Comment 9

14 years ago
Neil, you had asked me to make the label property readonly:
https://bugzilla.mozilla.org/show_bug.cgi?id=244624#c11

Do you still want it to be readonly or should I switch it back to having a setter?
(Assignee)

Comment 10

14 years ago
Actually hmm. That was my call to make the menulist label readonly, because the
label represents the selected item's label. Making it writable means that you're
choosing changing the selected option, but what happens when that option doesn't
currently exist? I guess the menulist should just show that label, but no option
is really selected.

It seems like Ben what wants to do here is to show nothing selected when the
menulist is disabled/grayed out. Seems reasonable.
(Assignee)

Comment 11

14 years ago
Created attachment 169298 [details] [diff] [review]
Restore setter for menulist label, make it similar to setting value (it will choose relevant item with same label if there is one)
Assignee: bugs → aaronleventhal
Status: NEW → ASSIGNED
Attachment #169298 - Flags: review?(mconnor)
So why is the code trying to set the label of the menulist anyway?
(Assignee)

Comment 13

14 years ago
(In reply to comment #12)
> So why is the code trying to set the label of the menulist anyway?

It's less confusing to novice users if the disabled menu list is blank.
Actually, in that case I don't see why there needs to be a menulist or radio
button at all. Why can't we just have a simpler dialog when there is really only
1 choice anyway?
(In reply to comment #13)
>It's less confusing to novice users if the disabled menu list is blank.
Then set it blank using openHandler.selectedItem = null;

Comment 15

14 years ago
*** Bug 247478 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 16

14 years ago
Created attachment 169357 [details] [diff] [review]
Follow Neil's simple suggestion
Attachment #169298 - Attachment is obsolete: true
Attachment #169357 - Flags: review?(mconnor)
(Assignee)

Updated

14 years ago
Attachment #169298 - Flags: review?(mconnor)

Comment 17

14 years ago
menulist.setAttribute("label", newlabel); still works btw.
Comment on attachment 169357 [details] [diff] [review]
Follow Neil's simple suggestion

yeah, this works.
Attachment #169357 - Flags: review?(mconnor) → review+
(Assignee)

Comment 19

14 years ago
Checking in nsHelperAppDlg.js.in;
/cvsroot/mozilla/toolkit/mozapps/downloads/src/nsHelperAppDlg.js.in,v  <-- 
nsHelperAppDlg.js.in
new revision: 1.18; previous revision: 1.17
done
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago14 years ago
Resolution: --- → FIXED

Comment 20

14 years ago
V 20041224 PC/Win2000
Status: RESOLVED → VERIFIED
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.