Open
Bug 130132
Opened 23 years ago
Updated 2 years ago
Launch File button sometimes disabled: quickly going thru helper app dlg [*no* OS-defined association]
Categories
(Firefox :: File Handling, defect)
Tracking
()
NEW
People
(Reporter: bugzilla, Unassigned)
References
(Depends on 1 open bug, )
Details
found while testing bug 128667 --using 2002.03.11.05 comm bits on win2k.
1. go to http://mozilla.org/
2. in the "Nightly Builds" section, click a link for which there's *no*
OS-defined file association on you machine. for me this was the "Mac OS X" link.
3. right when the helper app dlg appears, *quickly* hit the OK button.
4. right when the file picker dlg appears, *quickly* choose a location (i used
the Desktop) and immediately hit the Save button.
5. watch the resulting download progress dlg...
result: the Launch File button in the download progress dlg is disabled.
clicking it does nothing. *also* note that the dlg is clipped on the right side,
a la bug 79889.
this is an interesting timing issue. if i do either of the following, the Launch
File button is *not* disabled *and* the download progress dlg is *not* clipped:
* at steps 3 and 4, take a more leisurely pace: i waited about 30sec-1min before
clicking the buttons.
* instead of [left-]clicking the link, bring up the context menu and do a "Save
Link As". doesn't matter how slow or fast you do this either.
Reporter | ||
Comment 1•23 years ago
|
||
see also bug 130136, where i test this where there is an OS-defined file
association.
another (minor) observation about the download progress dlg when this bug crops
up: the Cancel button has changed to Close.
Summary: Launch File button sometimes disabled: quickly going thru helper app dlg → Launch File button sometimes disabled: quickly going thru helper app dlg [*no* OS-defined association]
Reporter | ||
Updated•23 years ago
|
Comment 2•23 years ago
|
||
I'm confirming this exact behavior with 0.9.9 in Win98SE except it also does this
with files that have an OS-defined association (IE: .mp3)
It's clearly a regression cause it used to work fine in 0.9.8.
Maybe it's due to the code that gone into the new "show file location" (select
the "My computer view instead of the Explorer 2-panes view AND select the
downloaded file in that window).
NB: The first time you download a file with a certain extension and click Show
file location, it doesn't select (hi-lite) the file . If I download the same
type of file with the same extension afterward and click Show file location, the
file is selected (hilighted). Should I file a new bug for that?
Comment 3•23 years ago
|
||
Sorry for the spam : but the bug I was describing in my NB (Show file location
doesn't select the file) is due to bug 55690 and the pre-saving files behavior
in general . You have to wait a couple of seconds before you click the show file
location button so the file is already there and can be selected.
bug 55690 is evil . The pre-saving file feature doesn't even work anymore since
a couple of months now (Files aren't being downloaded until I choose a location
but it download the files in a temp directory and move it after to the final
location.
so it's completely useless in this state).
/end of spam.
re: the "show file location" hilights the file only sometimes
Yes, please open a bug on that. It is because we have to jump through hoops to
accomplish that (on Windows, at least) and there are timing issues that require
more work to resolve.
Comment 5•23 years ago
|
||
nsbeta1- per Nav triage team. requires file type unknown to OS, + 2 very
timing-dependent steps; result is only a minor inconvenience - low impact.
Reporter | ||
Updated•22 years ago
|
QA Contact: sairuh → petersen
Updated•15 years ago
|
Assignee: law → nobody
QA Contact: chrispetersen → file-handling
Updated•8 years ago
|
Product: Core → Firefox
Target Milestone: mozilla1.2alpha → ---
Version: Trunk → unspecified
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•