Closed Bug 155429 Opened 18 years ago Closed 17 years ago

[mac] some downloads result in invisible entries in the dl mgr


(SeaMonkey :: Download & File Handling, defect, major)

Not set


(Not tracked)



(Reporter: bugzilla, Assigned: ccarlen)



(Keywords: relnote, Whiteboard: [adt3])


(1 file)

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, 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:
Line: 63

oddly, this doesn't happen all the time. for example, when i hit cmd+s to save (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
Keywords: nsbeta1
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:Transferred="0KB of  0KB">
    <NC:File resource=""/>
    <NC:DownloadState NC:parseType="Integer">1</NC:DownloadState>
    <NC:ProgressPercent NC:parseType="Integer">100</NC:ProgressPercent>

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 ::
:: anonymous :: line 98"  data: no]
Source File:
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...
Keywords: relnote
Nav triage team: nsbeta1+/adt3
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt3]
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.)
QA Contact: sairuh → petersen
*** Bug 161884 has been marked as a duplicate of this bug. ***
Blocks: 157062
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
Setting milestone.
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 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
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
Closed: 17 years ago
Resolution: --- → WORKSFORME
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.