- "Show the Downloads window when downloading a file" (browser.download.manager.showWhenStarting;true) is enabled in Options in General tab - "Downloads" button is hidden - "browser.download.useToolkitUI" is set by default as "false" Regression window (mozilla-inbound-win32-pgo) Good: https://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win32-pgo/1356023013/ Bad: https://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win32-pgo/1356033838/ Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=f042470c7ae8&tochange=487d0f89749b Probably triggered by: 6bcdc46945a6 Mike Conley — Bug 822244 - Use the Downloads View in Places if it's preffed on. r=mak.

Do you have the new downloads view enabled? if so that's by design.

hmm, I don't know. How can I check it? But even if it's by design, I still see nothing, having "Show the Downloads window when downloading a file" (browser.download.manager.showWhenStarting;true) is enabled in Options in General tab.

yes, we should hide those 2 options when the new downloads panel is in use, confirming the file to do that. Btw, if you have set browser.library.useNewDownloadsView to true, then you are using the new view. Is this the case?

http://mxr.mozilla.org/mozilla-central/source/browser/components/preferences/main.xul#120 and the corresponding in-content file. Luckily main.js has an init() function we can likely use to hide these options: http://mxr.mozilla.org/mozilla-central/source/browser/components/preferences/main.js#16

(In reply to Marco Bonardo [:mak] (intermittently avail. until 3 Jan) from comment #3) > Btw, if you have set browser.library.useNewDownloadsView to true, then you > are using the new view. Is this the case? I don't have this preference in about:config, so it's set on default (probably "false" I think)

(In reply to Virtual_ManPL [:Virtual] from comment #5) > (In reply to Marco Bonardo [:mak] (intermittently avail. until 3 Jan) from > comment #3) > > Btw, if you have set browser.library.useNewDownloadsView to true, then you > > are using the new view. Is this the case? > I don't have this preference in about:config, so it's set on default > (probably "false" I think) Hey Virtual_ManPL: The preference does not exist in about:config by default. If it doesn't exist, Nightly will assume you don't want to enable the new view. In order to try it, go to about:config, and add a new boolean. Name it browser.library.useNewDownloadsView and set it to true. -Mike

Thanks! Some test info: - "Show the Downloads window when downloading a file" (browser.download.manager.showWhenStarting;true) is enabled in Options in General tab - "Downloads" button is hidden - "browser.download.useToolkitUI" is set by default as "false" Test: Without "browser.library.useNewDownloadsView" = no Downloads info is shown With "browser.library.useNewDownloadsView" set to "false" = no Downloads info is shown With "browser.library.useNewDownloadsView" set to "true" = no Downloads info is shown So in every case you need to open manually Downloads (CTRL+J or by menu) to see the progress of downloading files, at least it's in my case and settings. Also, background of New Downloads View is completely white, isn't it a bug?

ok, so the above is (so far) expected when the panel feature is enabled, cause with it we have a notification in the main window. And if you remove the downloads button we consider that you don't want to be notified. In future we may evaluate changes but so far this is the direction. If you can't live without the old DM window popping up you should disable the feature through the browser.downloads.useToolkitUI (true) pref, and keep using the old DM. What we should do here is just hide the preferences when the new panel is in use.

Took Javi's original patch from bug 697679, partially reverted in bug 748160, and updated it to use the preference for the Library view instead of the panel.

Updated after IRC discussion, since in the end we'll want a single preference to control whether the old or the new user interface is used, and the preference for the Library view will eventually be removed.

Comment on attachment 696029 [details] [diff] [review] Updated patch Review of attachment 696029 [details] [diff] [review]: ----------------------------------------------------------------- Thanks! ::: browser/components/preferences/in-content/main.js @@ +31,5 @@ > > + setupDownloadsWindowOptions: function () > + { > + var showWhenDownloading = document.getElementById("showWhenDownloading"); > + var closeWhenDone = document.getElementById("closeWhenDone"); please use let in new code ::: browser/components/preferences/main.js @@ +33,5 @@ > > + setupDownloadsWindowOptions: function () > + { > + var showWhenDownloading = document.getElementById("showWhenDownloading"); > + var closeWhenDone = document.getElementById("closeWhenDone"); ditto

I addressed my comments and pushed https://hg.mozilla.org/integration/mozilla-inbound/rev/0b3cc2b5fc5f

Backed out for failing browser_library_downloads.js: https://hg.mozilla.org/integration/mozilla-inbound/rev/a17555ed859b

(In reply to Marco Bonardo [:mak] (intermittently avail. until 3 Jan) from comment #8) > ok, so the above is (so far) expected when the panel feature is enabled, > cause with it we have a notification in the main window. And if you remove > the downloads button we consider that you don't want to be notified. > > In future we may evaluate changes but so far this is the direction. > If you can't live without the old DM window popping up you should disable > the feature through the browser.downloads.useToolkitUI (true) pref, and keep > using the old DM. > > What we should do here is just hide the preferences when the new panel is in > use. Awww! Yep! Recently I reinstalled Nightly and I have completely forgotten about changing "browser.download.useToolkitUI" to "true", so Firefox will use old download manager. Happily I find this bug because of that. Thanks for pointing this out!

relanded, not culprit for the test failure. https://hg.mozilla.org/integration/mozilla-inbound/rev/499791560b0e

Thanks for landing this, Marco.

Verified using latest hourly Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20121229 Firefox/20.0 Thanks!