Closed
Bug 60948
Opened 24 years ago
Closed 24 years ago
Can't type in the "open using" field in "downloading" dialog
Categories
(SeaMonkey :: UI Design, defect, P3)
Tracking
(Not tracked)
People
(Reporter: bzbarsky, Assigned: mscott)
References
()
Details
Attachments
(1 file)
Linux build 2000-11-21-08
Steps to reproduce:
1) Go to the url provided (or anyplace where you have to get content you don't
have a helper for)
2) Try to click on a link to play streaming music
3) Get the "downloading" dialog
4) Try to type an application name
Actual results: can't type in textfield
Comment 1•24 years ago
|
||
Confirming build 2000112304 win32. I'm not sure we are supposed to be able to
write in it though, because you have to chose the file using "Choose...".
However I agree that it would be a great addition to have a second textfield
specifying the location of the program, so you could simply type in the local
url of the program to use, as it happens in most other softwares. What do you
think Boris?
Fabian.
Changing OS to all, marking new.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Summary: Can't type in the "open using" field in "downloading" dialog → Can't type in the "open using" field in "downloading" dialog
Reporter | ||
Comment 2•24 years ago
|
||
In every single other instance of such fields (eg the file upload field or even
the field in which you enter the application under Preferences -> Helpers), you
can type in the text field. So we should be consistent with that behavior.
Comment 3•24 years ago
|
||
A simple matter of removing readonly="true" in
source/xpfe/components/ucth/resources/helperAppLauncher.xul
However there is a reason (that I ignore) for this readonly to be there...
Fabian.
Reporter | ||
Comment 4•24 years ago
|
||
Reporter | ||
Comment 5•24 years ago
|
||
I can't think of a good reason that should be there....
CVS blame shows that the readonly="true" was there in the original revision of
the file.
CVS comments do not list a reason for that to be there.
Reporter | ||
Comment 6•24 years ago
|
||
Actually, the patch I have provided based on Fabian's observation fixes nothing
useful (again, per Fabian's observation).
The application to be used comes from an internal variable in
helperAppLauncher.js instead of coming from the textfield, so just modifying the
textfield by typing in it is not very helpful...
I'll talk to mpt about this and if he says that the current behavior needs to be
changed I'll look for a way to make this work more like the file upload form field.
Comment 7•24 years ago
|
||
handing over to mscott, at least to review the patch --pls change if this
shouldn't be yours. thx!
Assignee: don → mscott
Keywords: patch
Reporter | ||
Comment 8•24 years ago
|
||
This is actually a duplicate of bug 49787, but I'm not sure which direction I
should dup in.
Assignee | ||
Comment 9•24 years ago
|
||
*** This bug has been marked as a duplicate of 49787 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
verified dup.
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•