155426 - OS X trunk: download manager never displays downloads

Status: VERIFIED FIXED

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

Description

[sairuh (rarely reading bugmail)]

found using 2002.07.01.03 comm trunk. whenever i download a file or open it with
a helper app, its entry is never listed in the download manager window.

tested:
a. saving via "save target link as"
b. saving via helper app dlg ("save to disk")
c. opening helper app

js console output for (a):

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:///Perla/Test%20OS%20X%20Builds/2002070103/Netscape/Netscape.app/Contents/MacOS/Components/nsDownloadProgressListener.js
:: anonymous :: line 98"  data: no]
Source File:
file:///Perla/Test%20OS%20X%20Builds/2002070103/Netscape/Netscape.app/Contents/MacOS/Components/nsDownloadProgressListener.js
Line: 98

Error: this.doc.getElementById(aDownloadID) has no properties
Source File:
file:///Perla/Test%20OS%20X%20Builds/2002070103/Netscape/Netscape.app/Contents/MacOS/Components/nsDownloadProgressListener.js
Line: 99

Error: this.doc.getElementById(aDownloadID) has no properties
Source File:
file:///Perla/Test%20OS%20X%20Builds/2002070103/Netscape/Netscape.app/Contents/MacOS/Components/nsDownloadProgressListener.js
Line: 63

js console output for (b) just spews the line 98 error above until download
finishes, followed by the line 99 and 63 errors above.

js console output for (c) consists of the line 99 and 63 errors.

Comment 1

[sairuh (rarely reading bugmail)]

btw, is this another component registry issue, or something else?

Comment 2

[J.J. Enser]

sairuh, you might be able to answer your own question by removing the component
registry file and trying again.

Because of the stability problems it caused, we stopped including a
pre-generated component registry with OSX BRANCH builds, but we continue to do
so with TRUNK builds since we didn't encounter the same issues there.

If this works fine with today's branch build and removing the Compreg from the
trunk build also resolves the issue, then I'll turn off the "autoreg" step in
the TRUNK build automation as well.

Comment 3

[sairuh (rarely reading bugmail)]

this was not a problem using 2002.07.02.05 branch comm bits.

for the 2002.07.01.03 trunk build, i removed the Component Registry, but the
download manager still fails to display entries.

i'll dblcheck with today's trunk build, if it's available...

Comment 4

[sairuh (rarely reading bugmail)]

even after trashing the Component Registry for the 2002.07.02.11 trunk comm
build, i still this.

Comment 5

[sairuh (rarely reading bugmail)]

not a problem with trunk builds on linux rh7.2, win2k, or oddly enough mac 9.1.
tested with 2002.07.03.0x comm builds.

Comment 6

[sairuh (rarely reading bugmail)]

hey steve, have you encountered this problem before? and/or, any ideas as to why
it might be happening?

Comment 7

[Steve Dagley]

Nope, haven't seen this one before (not that I ever use the DL manager tho)

Comment 8

[Greg K.]

Reconfirmed using FizzillaCFM/2002071808.

Comment 9

[Simon Fraser [no longer active]]

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

Comment 10

[Simon Fraser [no longer active]]

See bug 155426 for the reasons why this is broken.

Comment 11

[Simon Fraser [no longer active]]

Er, the reasons are in bug 156955. See also bug 132027, which is related.

Comment 12

[Greg K.]

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

Comment 13

[Greg K.]

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

Comment 14

[Greg K.]

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

Comment 15

[Greg K.]

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

Comment 16

[Greg K.]

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

Comment 17

[Greg K.]

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

Comment 18

[Samir Gehani]

Nav triage team: nsbeta1+/adt2

Comment 19

[Greg K.]

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

Comment 20

[Greg K.]

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

Comment 21

[Greg K.]

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

Comment 22

[Michael Hannemann]

I've noticed this on Mac OS X, both 10.1.5 and 10.2.1, versions 1.2a through
today's build (2002101612).

Comment 23

[Simon Fraser [no longer active]]

Bug 156955 describes why this is broken.

Comment 24

[Simon Fraser [no longer active]]

Specifically:
http://bugzilla.mozilla.org/show_bug.cgi?id=156955#c8
http://bugzilla.mozilla.org/show_bug.cgi?id=156955#c9

Comment 25

[Greg K.]

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

Comment 26

[Stefan [:stefanh]]

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

Comment 27

[Stefan [:stefanh]]

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

Comment 28

[sairuh (rarely reading bugmail)]

also busted on mach-o [moz trunk, 2002.12.16.07].

Comment 29

[Chris Petersen]

This problem pretty much makes the dl manager useless to the user. Any chance we
can get this resolved soon ? This has been broken for months on the trunk and
really should be a useable feature for OS X Mozilla users.

Comment 30

[Conrad Carlen (not reading bugmail)]

Sure, I'll take a look.

Comment 31

[Simon Fraser [no longer active]]

Conrad: there are 2 issues (when I looked at this a while back).
i) xul overlays included for Mac (to get a menu bar in the d/l window) cause
   errors that mean that initting the window fails.

ii) blake mixed full paths and persistent descriptors (in C++ and JS).

See
http://bugzilla.mozilla.org/show_bug.cgi?id=156955#c8
http://bugzilla.mozilla.org/show_bug.cgi?id=156955#c9

Comment 32

[Simon Fraser [no longer active]]

Taking

Comment 33

[Simon Fraser [no longer active]]

Attachment: Patch to fix persistent descriptor/path mismatches

This patch fixes a bunch of issues (some XP) with mismatches between paths and
persistent descriptors (PDs).

The DL manager uses paths/PDs to index into the list of downloads (both active,
and done). PDs have issues here, because the code needs to reference the PD for
a file before it has been created, which is not possible with a PD. So I
converted the code to use full paths, which (now that we don't care about OS 9)
is mostly OK. However, the code used file.path in JS, but native paths in C++
(which it used with RDF). That was also broken, because native paths use the
system encoding, so won't match unicode paths. This was fixed by using unicode
paths in the C++, converted to UTF-8 for RDF.

Issues remain. It's possible to start the same download twice, but because the
destination path isn't unique, it will only appear once in the list, with
progress that flickers up and down. Also, past downloads won't be tracked if
you  move the file, or reboot and end up with different volume names.

Also, none of this works unless you remove the contents.rdf that causes
hiddenwindow.xul to be overlayed in the download manager window, something that
is done just for Mac (to get menus), but causes a slew of JS errors.

Comment 34

[Conrad Carlen (not reading bugmail)]

> That was also broken, because native paths use the
system encoding, so won't match unicode paths.

This should be true for anything but builds using nsLocalFileOSX.cpp, because
its native *is* UTF-8. So, that fix is right, but I'm curious where you observed
that breakage. If it was on Mach-O, something very contrary to the OS doc is
happening.

Comment 35

[Simon Fraser [no longer active]]

I saw it in a CFM build, with a truncated filename (that contained an ellipsis
character).

Comment 36

[Simon Fraser [no longer active]]

Attachment: Patch adds fix for XUL menus on Mac

Comment 37

[Conrad Carlen (not reading bugmail)]

Comment on attachment 110021 [details] [diff] [review]
Patch adds fix for XUL menus on Mac

Nice, cleans up a few things.

Comment 38

[Simon Fraser [no longer active]]

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

Comment 39

[Simon Fraser [no longer active]]

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

Comment 40

[jag (Peter Annema)]

Comment on attachment 110021 [details] [diff] [review]
Patch adds fix for XUL menus on Mac

>Index: resources/downloadmanager.js
>===================================================================

>+function haveSelectedItem()
>+{
>+  return (gDownloadView.currentIndex != -1);
>+}

Are you using this function anywhere?

>Index: resources/mac/dlmanagermenuoverlay.xul
>===================================================================

>+  <script type="application/x-javascript" src="chrome://global/content/strres.js"/>

Is this overlay needed? I thought we got rid of most uses of the function in
there.


sr=jag

Comment 41

[Simon Fraser [no longer active]]

Fix checked in, with jag's comments addressed. Thanks guys!

Comment 42

[Chris Petersen]

Using the 2003-01-03-08 OS X CFM trunk, this problem has been fixed. Download
transfers now appear in the DL window. During the transfer process, information
like file name, progress indicator, and transferred data are displayed.

Comment 43

[Greg K.]

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

Comment 44

[Greg K.]

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