Closed Bug 155429 Opened 18 years ago Closed 17 years ago
[mac] some downloads result in invisible entries in the dl mgr
7.26 KB, text/plain
found using 2002.07.02.05-branch comm bits on mac 10.1.5. i've noticed that sometimes i get "invisible" entries in the download manager for some file downloads. haven't noticed this on win2k or linux, either (so far). 0. have the dl mgr window already opened. 1. go to the download section on http://mozilla.org, and bring up "save target link as" (context menu) for any of the following links: * mozilla 1.0 - win (9.8mb) * mozilla 1.1alpha - win (10.9mb) 2. chose a target location, hit save and watch the dl mgr window. results: and invisible entry is added to the dl mgr window (you can select it). the following is spewed in the js console during the download: Error: this.doc.getElementById(aDownloadID) has no properties Source File: file:///Perla/Test%20OS%20X%20Builds/2002070205-br/Netscape/Netscape.app/Contents/MacOS/Components/nsDownloadProgressListener.js Line: 63 oddly, this doesn't happen all the time. for example, when i hit cmd+s to save http://mozilla.org (html only), the entry does appear in the dl mgr. also --not sure if this is related-- but when there are these invisible entries, i cannot immediately remove them or visible entries: 1. select some entries, then click on "remove from list" 2. notice that nothin has happened, now close and reopen the dl mgr window. 3. if there's still no change, quit and restart the app. 4. upon restart, notice that the deleted entries are (finally) gone, and that the invisible entries are now visible. could this be yet another component reg issue? is the weird entry removal situation a separate issue from this bug?
prolly not a component reg issue, as removing the file didn't stop this bug from occurring.
jrgm was able to narrow this down to the filename length using today's branch build. files whose names were 31 char or less appeared in the dl mgr, whereas those with >31 char did not. here's a snippet from the download.rdf for a file with 32-char name (which failed to display in the dl mgr window): <RDF:Description about="" NC:Name="123456789_12345…89_123456789.gz" NC:ProgressMode="none" NC:StatusText="Finished" NC:Transferred="0KB of 0KB"> <NC:URL resource="http://jrgm.mcom.com/bugs/155429/123456789_123456789_123456789.gz"/> <NC:File resource=""/> <NC:DownloadState NC:parseType="Integer">1</NC:DownloadState> <NC:ProgressPercent NC:parseType="Integer">100</NC:ProgressPercent> </RDF:Description> cc'ing sdagley to see if he might have ideas as to why this might be happening. the odd thing is --i've seen this (so far) on only OS X, but jrgm said that from the downloads.rdf he got for bug 153480, such errata were appearing on non-Mac platforms. hrm. also (also?), i coulda sworn i've seen this occur with some files with shorter (less than 31 char) names, but maybe i'm mistaken there...
i'll need to check if there are differences in downloads.rdf before and after i restart the app, which makes the invisible entries visible in the next session...
NC:Name looks suspicious. It could be that the DL manager is somehow barfing on the ellipsis token we use to mid-trunc a downloaded file name >31 charcters. Adding ccarlen to the cc: list for his comments.
If you are looking for independent verification, well now you have it. With exactly one try, following the steps you outlined I saw the same results with 20020709 branch builds on MacOS 10.1.5. I've copied the error I saw. It was followed by numerous repeated errors that matched the earlier one sairuh mentioned in comment#0 Error: [Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsILocalFile.persistentDescriptor]" nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)" location: "JS frame :: file:///Main%20HD/Applications/Browser%20Builds/MachV/2002070905-100/Netscape.app/Contents/MacOS/Components/nsDownloadProgressListener.js :: anonymous :: line 98" data: no] Source File: file:///Main%20HD/Applications/Browser%20Builds/MachV/2002070905-100/Netscape.app/Contents/MacOS/Components/nsDownloadProgressListener.js Line: 98
fyi, I was also able to reproduce this behavior with both new and old profiles.
furthermore this failure was not evident on Win98, Linux, or MacOS 9. I should note however that on OS 9 after showing the initial state in the downloadmanger the item failed to updte until it was completely finished downloading.
per comment 4, i compared the downloads.rdf before and after i restarted the app: even though the invisible entries became visible after a restart, the .rdf remained unchanged. interesting...
jrgm recommends that this go to ccarlen or whoever owns mac file APIs.
Assignee: blaker → ccarlen
What's the difference between this bug and bug 155426?
this is specific to mozilla/netscape on the 1.0 branch, whereas bug 155426 is specific to the mozilla/netscape trunk. out of curiosity, is this particular issue also evident in embedded apps, which are based on the branch? (not sure which, if any, embedded apps would use the download manager as implemented in mozilla/netscape.)
*** Bug 161884 has been marked as a duplicate of this bug. ***
I have this problem with Mozilla 2002101612 with Win98 and with Mozilla 1.1 on win 2000. It was not like that from the very beggining. What happens is that when I click and save with "save target as" I can not see the file in the pop-up window of the Download Manager. Yes it is being highlighted when I click on that empty line, but it did not appear. It is very disapoing since I do not have an idea of the status of the download. The file I am downloading in a moment called update3_2.exe, thus the filenames is shorter than 30 symbols. I first thought it might be because I have a plugin of FlashGet which is suppose to take downloads over, which it dose not do. I did not find an obvious way how to get rid of it. BTW, the plugin is called FlashGet for Opera but they argued that it works for Mozilla and Netscape as well.
Let's keep this bug specific the Mac filename issue.
Summary: some downloads result in invisible entries in the dl mgr → [mac] some downloads result in invisible entries in the dl mgr
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.3beta
*** Bug 182615 has been marked as a duplicate of this bug. ***
*** Bug 184422 has been marked as a duplicate of this bug. ***
Error: [Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsILocalFile.persistentDescriptor]" nsresult: This will no longer happen on the trunk: I changed the code not to use persistent descriptors.
i cannot repro in ppembed --i added ("browser.downloadmanager.behavior", 0) to the prefs file to test (unless that's not the correct way to check in ppembed). and this is also moot for chimera, which has its own (non-xul) d/l mgr window. other than netscape 7.0x, are there other 1.0 mac embed apps which are still affected by this? should this be resolved?
hm, i guess adding the pref doesn't really matter for ppembed --the d/l behavior is the same. anyhow, just wondering if this bug should remain open, or marked resolved (wontfix?).
Does this bug still exist in Buffy builds (OS/X and OS/9)? What happens if you download http://jrgm.mcom.com/bugs/155429/123456789_123456789_123456789.gz with a current trunk build?
> hm, i guess adding the pref doesn't really matter for ppembed Right - PPEmbed has its own download UI, so this isn't relevant to it. Isn't this is a dup of bug 155426?.
it is not dup of bug 155426; bug 155426 is fixed now. However after a number of download and remove from list performed, occasionally there are invisible entries.
besides, strange issues occurs if: 1) create a new profile and visit http://www.mozilla.org 2) "save link target as" a few links, e.g. "Mozilla 1.0.2", "more ...", "Mozilla at a Glance" 3) open download manager window 4) click/highlight the item and click "Remove from list" one by one result: some entries can't be highlight but it can still be "removed from list".
Setting to milestone that's not passed. I'm not sure if this still happens though.
Target Milestone: mozilla1.3beta → mozilla1.4beta
WFM because (1) the test in comment 23 works fine (2) there is no 31 char filename limit on the Mach-O build (3) Simon's other fixes to the dl manager fixed the other problems
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.