187600 - Using a new profile, DL manager doesn't display file transfer upon opening the first time.

Status: VERIFIED FIXED

(SeaMonkey :: Download & File Handling, defect)

Description

[Chris Petersen]

Build: CFM 2003-01-03-04 trunk  and Mach -0 2003-01-02-07 trunk builds.
Platform: OS X 10.2.3
Expected Results: File transfer should appear in DL manager's window.
What I got: DL window opens but current file transfer isn't displayed.

Steps to reproduce:

1) Create a new profile 
2) Launch browser with this profile
3) Specify in Mozilla Preferences to open DL Manager by default
Preferences - Downloads - Open the download manager
4) Start a dl transfer
5) Notice DL manager opens but file transfer is not displayed
6) If you quit and relaunch Mozilla, the DL manager's window will should the
previous file transaction. At this point, all file transfers will appear in the
 DL window.

Comment 1

[Simon Fraser [no longer active]]

Taking.

Comment 2

[sairuh (rarely reading bugmail)]

unable to repro (so far) with today's linux trunk.

could this be bug 155429?

Comment 3

[sairuh (rarely reading bugmail)]

chatted w/chris who sez it doesn't seem to matter what the filename length is,
so this might not be related to bug 155429.

Comment 4

[Chris Petersen]

This problem is very reproducable with new profiles. I thought maybe the problem
might be related to changing to dl manager and starting a file transfer in the
same session. But it doesn't matter. If I change dl manager to be the default
and quit then relaunch, the dl manager still doesn't show a entry when a file
transfer is occuring.

However, I found a workaround. If I open/close the download manager after I
specifying it as default, it will display the file transfer correctly during the
same session.

Comment 5

[Conrad Carlen (not reading bugmail)]

Sounds like the .rdf file in the profile which is used to store download history
is not there the first time around and causing problems?

Comment 6

[Chris Petersen]

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

Comment 7

[Chris Petersen]

I can't reproduced this problem using the Mach-o 2003-01-23-07 trunk build under
10.2.3.

Comment 8

[Simon Fraser [no longer active]]

Yeah, my other fix fixed this.

Comment 9

[Chris Petersen]

Verified.