414214 - Download Manager window doesn't stay open when browser.download.manager.closeWhenDone is true

Status: VERIFIED FIXED

(Toolkit :: Downloads API, defect, P1)

Description

[Elmar Ludwig]

Tested with a new profile, today's nightly build:

1. Open Preferences and enable the option:
   "Main > Downloads > Close it when all downloads are finished"
2. Open Download Manager window

The download manager appears for a fraction of a second and immediately closes itself again. This makes it impossible to work with the download manager when browser.download.manager.closeWhenDone is enabled, so requesting blocking.

This is a very recent regression, I'm investigating which checkin caused it.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008012704 Minefield/3.0b3pre ID:2008012704

Comment 1

[Elmar Ludwig]

Regression range:

2008-01-26_11-27 works
2008-01-26_13-05 fails

Checkins between 2008-01-26 11:27 and 2008-01-26 13:04:

http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1201375620&maxdate=1201381499

The Bonsai query shows several changes to the download manager code here, but from looking at the patches, bug 411947 seems the most likely one to have caused this regression.

Note: This is very similar to the problem reported in bug 397935 and it may well be that bug 411947 just made this older bug more visible.

Comment 2

[Antti Tervasmäki]

And this happens with Windows also.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008012704 Minefield/3.0b3pre ID:2008012704

Comment 5

[Mike Connor [:mconnor]]

Awesome.

Comment 6

[Shawn Wilsher :sdwilsh]

Attachment: v1.0

ug...stupid mistake on my part.

Now with more tests!

Comment 7

[Asaf Romano (gone)]

Comment on attachment 300072 [details] [diff] [review]
v1.0

That's what you get for copy and paste.

Comment 8

[Shawn Wilsher :sdwilsh]

Attachment: v1.1

fixed the comment change...

Comment 9

[Shawn Wilsher :sdwilsh]

Attachment: v1.2

one additional comment fix

Comment 10

[Asaf Romano (gone)]

Comment on attachment 300091 [details] [diff] [review]
v1.2

please document this behavior in the downloadmanangerui interface.

r=mano.

Comment 11

[Shawn Wilsher :sdwilsh]

Attachment: v1.3

Address review comment.

Comment 12

[Shawn Wilsher :sdwilsh]

Checking in toolkit/components/downloads/src/nsDownloadManagerUI.js;
new revision: 1.5; previous revision: 1.4
Checking in toolkit/components/downloads/test/browser/Makefile.in;
new revision: 1.2; previous revision: 1.1
Checking in toolkit/components/downloads/test/browser/browser_bug414214.js;
initial revision: 1.1

Comment 13

[Shawn Wilsher :sdwilsh]

Test isn't liking tinderboxen - disabled for debugging some other time.

Checking in toolkit/components/downloads/test/browser/Makefile.in;
new revision: 1.3; previous revision: 1.2

Comment 15

[pal-moz]

(In reply to comment #13)
> Test isn't liking tinderboxen - disabled for debugging some other time.
> 
> Checking in toolkit/components/downloads/test/browser/Makefile.in;
> new revision: 1.3; previous revision: 1.2
> 

Status: RESOLVED FIXED ?

Comment 16

[Michael Monreal [:micmon]]

The DL window still does not open for me if no downloads are in progress with the latest nigtly. Not fixed yet?

Comment 17

[Shawn Wilsher :sdwilsh]

(In reply to comment #15)
> Status: RESOLVED FIXED ?
Yes - I *only* backed out the test.  It passes locally (tinderboxen are slow, I didn't want to delay the tree going green on a freeze day...)

(In reply to comment #16)
> The DL window still does not open for me if no downloads are in progress with
> the latest nigtly. Not fixed yet?
build id?

Comment 18

[Michael Monreal [:micmon]]

Shawn, I'm currently using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008013004 Minefield/3.0b3pre. Just tested again, still the same.

Comment 19

[Stephen Donner [:stephend] Not actively reading bugmail]

Me neither, sadly, with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b3pre) Gecko/2008013004 Minefield/3.0b3pre; reopening.

Comment 20

[Shawn Wilsher :sdwilsh]

ug - I missed the browser.js file...

attaching a pass with the test fixed shortly

Comment 21

[Shawn Wilsher :sdwilsh]

Attachment: v2.0

Tests fixed to not use window.timeout too!

Comment 22

[Shawn Wilsher :sdwilsh]

Got the file this time.  Test landed as well.

Checking in browser/base/content/browser.js;
new revision: 1.952; previous revision: 1.951
Checking in toolkit/components/downloads/test/browser/Makefile.in;
new revision: 1.4; previous revision: 1.3
Checking in toolkit/components/downloads/test/browser/browser_bug414214.js;
new revision: 1.2; previous revision: 1.1
Checking in toolkit/components/downloads/test/browser/browser_nsIDownloadManagerUI.js;
new revision: 1.2; previous revision: 1.1

Comment 23

[Shawn Wilsher :sdwilsh]

Test passes on mac only, so backed out again.

The actual fix is checked in this time though...

Checking in toolkit/components/downloads/test/browser/Makefile.in;
new revision: 1.5; previous revision: 1.4

Comment 24

[Shawn Wilsher :sdwilsh]

Attachment: v1.0 test fix

OK, follow-up to fix the test.

metaKey isn't used on windows or linux...

Comment 26

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED using:

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b3pre) Gecko/2008020104 Minefield/3.0b3pre

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b3pre) Gecko/2008020104 Minefield/3.0b3pre

-and-

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008020104 Minefield/3.0b3pre

Comment 27

[Stephen Donner [:stephend] Not actively reading bugmail]

Looks like we should update the tests for this, if indeed it caused bug 413093.