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

Status: RESOLVED WORKSFORME

(SeaMonkey :: Download & File Handling, defect)

Description

[sairuh (rarely reading bugmail)]

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?

Comment 1

[sairuh (rarely reading bugmail)]

prolly not a component reg issue, as removing the file didn't stop this bug from
occurring.

Comment 2

[sairuh (rarely reading bugmail)]

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...

Comment 3

[sairuh (rarely reading bugmail)]

Attachment: downloads.rdf showing both visible and invisible entries

Comment 4

[sairuh (rarely reading bugmail)]

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...

Comment 5

[Steve Dagley]

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.

Comment 6

[Claudius Gayle]

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

Comment 7

[Claudius Gayle]

fyi, I was also able to reproduce this behavior with both new and old profiles.

Comment 8

[Claudius Gayle]

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.

Comment 9

[sairuh (rarely reading bugmail)]

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...

Comment 10

[Samir Gehani]

Nav triage team: nsbeta1+/adt3

Comment 11

[Blake Ross]

jrgm recommends that this go to ccarlen or whoever owns mac file APIs.  

Comment 12

[Torben]

What's the difference between this bug and bug 155426?

Comment 13

[sairuh (rarely reading bugmail)]

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.)

Comment 14

[Max Alekseyev]

*** Bug 161884 has been marked as a duplicate of this bug. ***

Comment 15

[Olexi Pasyuk]

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.

Comment 16

[John Morrison]

Let's keep this bug specific the Mac filename issue.

Comment 17

[Conrad Carlen (not reading bugmail)]

Setting milestone.

Comment 18

[Torben]

*** Bug 182615 has been marked as a duplicate of this bug. ***

Comment 19

[Torben]

*** Bug 184422 has been marked as a duplicate of this bug. ***

Comment 20

[Simon Fraser [no longer active]]

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.

Comment 21

[sairuh (rarely reading bugmail)]

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?

Comment 22

[sairuh (rarely reading bugmail)]

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?).

Comment 23

[John Morrison]

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?

Comment 24

[Conrad Carlen (not reading bugmail)]

> 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?.

Comment 25

[King-On Yeung]

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.

Comment 26

[King-On Yeung]

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".

Comment 27

[Conrad Carlen (not reading bugmail)]

Setting to milestone that's not passed. I'm not sure if this still happens though.

Comment 28

[Conrad Carlen (not reading bugmail)]

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