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)

x86
Windows 2000
defect

Tracking

()

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.
Keywords: nsbeta1
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]
Depends on: 55690, 129923
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?
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.
nsbeta1- per Nav triage team. requires file type unknown to OS, + 2 very timing-dependent steps; result is only a minor inconvenience - low impact.
Keywords: nsbeta1nsbeta1-
Target Milestone: --- → mozilla1.2alpha
QA Contact: sairuh → petersen
Assignee: law → nobody
QA Contact: chrispetersen → file-handling
Product: Core → Firefox
Target Milestone: mozilla1.2alpha → ---
Version: Trunk → unspecified
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.