Closed Bug 149510 Opened 22 years ago Closed 19 years ago

progress bar in Download Mgr only updated when download completes

Categories

(SeaMonkey :: Download & File Handling, defect)

PowerPC
macOS
defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: rxsherm, Assigned: sfraser_bugs)

References

Details

(Whiteboard: [adt3])

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.0) Gecko/20020529 BuildID: 2002052918 The download manager in Mozilla seems to be exhibiting two distinct problems that I could not find similar bugs on: Problem #1> When I bring up the download manager window, and then perform an FTP type download (like of a Mozilla build), I get a dialog asking whether I want to save the file or open it. After responding with "save" and picking a location, I get an entry in the download manager and a seperate download dialog box. This is a completely different behavior than what I've been seeing on Windows builds. Problem #2> While the download progress dialog increases in percent complete, etc, the download manager window does nothing. It does not update at all until either the download has completed or is cancelled It provides no sort of progress updates whatsoever. This is also contrary to the behaviors I've seen on the windows builds. I have tried removing my $HOME/Library/Mozilla folder and starting from scratch, but the same problem occurs. I should also point out this problem occurs on all my systems with 10.1.4 and 10.1.5 and both systems have HFS+ (not UFS) for the root drives (where I'm saving my files) Reproducible: Always Steps to Reproduce: 1.Pull up the download manager window 2.Download a Mozilla build (using the build toolbar link) 3.Specify "Save this file to disk" 4.Save the file to the desktop (your user and desktop folder should be on an HFS+ volume) 5. Note seperate progress dialog 6. Note download manager windows does not update during the actual download Actual Results: 5. Seperate progress dialog appears (unlike Mozilla on Windows) 6. Download manager does not update until upload is completed or cancelled (unlike windows builds) Expected Results: 5. Seperate progress dialog should not be appearing if the dialog manager window is up. 6. The dialog manager window should be updating with the download progress as the file downloads.
Confirmed using FizzillaCFM/2002052918 (rv1.0.0). Download Manager listing does not update during download.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Verified again on build 2002061308, so it's not going away by itself. :)
Still not assigned? Hello??? Anyone working on OS X functionality bugs? I know that the platform is probably the lowest of the low priorities for you guys (considering how long its been since the Java hooks were written but still not landed in the trunk) but I would assume that you would want similar functionality on all platforms. If not, I can certainly file a "cripple Mozilla on OS X" bug to have those pesky features like Download manager and Java support removed from the Mac OS X version.
*** Bug 145282 has been marked as a duplicate of this bug. ***
Verified again on build 2002062608. Behavior of download manager bug is slightly different in this build. It now doesn't seem to update the download manager window with any sort of information whatsoever.
Thanks to Mike Pinkerton for filing a "blocker" bug #154886.
Severity: major → critical
Depends on: 154486
My mistake, bug 154486 deals with downloading not working at all (although it is a blocker (if you can't download, how can you test? <g>) So here we are in the same boat. We've got this lovely bug that we can't even get the assignee to take some ownership of! ARGH! :)
No longer depends on: 154486
re-assign (hopefully) to someone less overloaded / gives a **** about major OS X functionality bugs opened over 23 days ago to at least touch it.
i saw a similar problem today, using 2002.07.01.07-branch commercial bits on mac 10.1.5. after i had done several downloads, those items didn't appear in the dl mgr window. i also tried deleting some older entries, but that didn't work either. then, i quit and restarted...and the deleted items were gone, and the most recently downloaded items were present. so far, i cannot quite reproduce this state, unfortunately. if i get more info, i'll add it here. steve / blake, any ideas what could be causing this? my profile is a bit "old", it was created on 13 may 2002. but not sure if profile corruption would be the issue. does anyone see this occurring with a new/fresher profile? just curious...
Also appears in the Mac OS 9.x builds. Verified on build 2002062109.
just spoke with simon on this, and he was able to demonstrate this bug using mozilla 1.1a (based on the trunk) bits on 10.1.5. i'll doublecheck this tomorrow. however, this behavior is strange, since i had verified bug 137676 on the trunk (albeit w/comm bits) several weeks ago (on 6/10, although this was filed on 6/5). again, i'll check out both the dl mgr and progress windows later on. so, i'm wondering if this might be a file handling issue, so punting to that component for now. bill, pls reassign as needed.
Assignee: blaker → law
Component: Download Manager → File Handling
to clarify my comment 12: what simon was seeing was the progress bar in the dl mgr window not updating during the download. he was also seeing the progress dlg appear as well; the progress bar therein, however, did update during the download. when simon canceled a download, the dl mgr displayed "canceled" as well as the amount that had been transferred thus far. as for the additional progress dlg appearing --i believe that is expected behavior on Mac by default, because the Downloads pref is "show progress dialog" by default on Mac. ie, you need to go to Tools > Download Manager initially to display the dl mgr window. but, again, i'll check with the "open with dl mgr" pref turned on.
okay, nevermind comment 10 for now --using 2002.07.02.05 *branch* comm bits on 10.1.5, i can repeat the problem of the progress bar in the download manager not painting till the download is complete. readjusting summary to reflect that. also, i just tested with the "open the download manager" pref turned on, and i don't get an extra progress dlg. the "extra" progress dlg is expected behavior if the "open a progress dialog" pref is on (default setting) && the download manager window was manually opened beforehand. (btw, the bar in the progress dlg still paints fine for me). i've seen some other weird behavior on the branch, as well as the trunk --but i want to keep those a separate bugs for now (best to have one issue per report). * bug 155426: trunk os x build not displaying anything in dl mgr window * bug 155429: branch os x build sometimes displaying a blank entry in dl mgr window
Severity: critical → major
Summary: Download manager on Mac ignored by Mozilla, only updated when download completes → progress bar in Download Mgr only updated when download completes
my observations in comment 14 for the branch build might also be due to the fact that bug 137676 has only been fixed on the trunk...but testing this further on the trunk is currently blocked by bug 155426.
QA Contact: sairuh → petersen
Nav triage team: nsbeta1+/adt3
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt3]
simon or conrad, could either of you look at this, since it's blocked by bug 155426?
Depends on: 155426
Simon has graciously offered to own this. Thanks Simon!
Assignee: law → sfraser
Component: File Handling → Download Manager
Progress bar in download manager is working fine in build 2003041103. Nevertheless, progress bar in download properties window does not work at all. Moreover I would suggest changing the severity of this bug to normal or minor, because this is probably only a little mistake in the code. Bearing in mind that from 1.5 will work on Phoenix builds I'm not sure if it makes sense to work on this bug at all, because Phoenix uses a different download manager, so this bug will not influence the future based-on-Phoenix builds. So if at all, I would set the Target Milestone to 1.4 final. Owner please agree or disagree (and make appropriate changes) :)
I just checked the experimental Mac OS X Phoenix build from http://www.kmgerich.com/misc.html and it has the same bug, so I assume this Mozilla bug and Phoenix bug have the same source. So I would suggest setting the target milestone to 1.4 final, before the 1.5 Phoenix mini-revolution.
This bug is probably correlated with bug 197289.
Looks like it is all working now thanks to the fixes for Bug 197289. Working in build 2003043008.
Is this now fixed?
Yes, now it seems to work fine on buil 2003120105.
Product: Browser → Seamonkey
fixed per comment 22 and comment 24 by bug 197289. Please reopen if still a fails with trunk build.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.