User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0 Build ID: 20160905030222 Steps to reproduce: 1. Start Nightly 2. Go to "https://www.mozilla.org/en-US/firefox/channel/" 3. Download "Firefox Beta" 4. Check downloads panel after downloading 5. Go to Home (about:home) 6. Click Downloads of launcher 7. Click "Clear Downloads" 8. Check downloads panel again Actual results: Spacer height is not reset even if clearing download history. Regression range: https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=4b767c8f023685e9e598f026453fbd906e0e8d1f&tochange=b655b3fb6153570e6e91635322e1e3c8ed2e4a1a Expected results: Spacer height is reset when clearing download history.

[Tracking Requested - why for this release]: Similar to bug 1292345. Following the discussion in that bug, I think we want this in Firefox 51 but a fix for Firefox 50 might be optional if it isn't simple to implement.

Tracking 51+ for this downloads panel regression.

Looks like this is getting ready to land.

Comment on attachment 8788900 [details] Bug 1300556 - Adjust the height of the Downloads Panel if downloads are removed while the panel is hidden. https://reviewboard.mozilla.org/r/77220/#review75556 One question below but the other changes are fine. Would be nice if a test was included (add a download item to the panel, open the panel, note the height, close the panel, open the library, clear downloads, open the panel, confirm that the height is now less than the previous height). ::: browser/components/downloads/content/downloads.js (Diff revision 1) > - DownloadsBlockedSubview.view.setHeightToFit(); > - > // If we've got some hidden downloads, we should activate the Shouldn't we keep this in case the panel is opened and another download is started?

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #5) > Would be nice if a test was included I've filed a separate bug for the automated test case since I'm wary of potential intermittent failures after uplift, and I'll not be around next week. I plan to work on the test as soon as I'm back, since it will be useful even for the work I'm doing to refactor this code. > Shouldn't we keep this in case the panel is opened and another download is > started? I've tested with a delayed download and expanding the panel while it's visible works correctly, it's just shrinking that is an issue. I removed this call to avoid flickering on open in the most common case, where downloads are just added to the panel while it's closed.

Pushed by paolo.mozmail@amadzone.org: https://hg.mozilla.org/integration/fx-team/rev/8f68c33f5793 Adjust the height of the Downloads Panel if downloads are removed while the panel is hidden. r=jaws

Comment on attachment 8788900 [details] Bug 1300556 - Adjust the height of the Downloads Panel if downloads are removed while the panel is hidden. Approval Request Comment [Feature/regressing bug #]: Bug 1252509 [User impact if declined]: Similarly to bug 1292345, the height of the downloads panel will remain unnecessarily large, but in this case this happens if downloads are removed while the panel is hidden. [Describe test coverage new/current, TreeHerder]: Just landed on mozilla-central, needs manual testing [Risks and why]: Changes are limited to the height calculation for the Downloads Panel, the risk is only that we missed some cases and the panel will be too high, but still usable. [String/UUID change made/needed]: None

verified in latest Nightly (20160909030428)

Note that there is a visible auto-sizing of the downloads panel in this scenario - http://screencast.com/t/ZH5k7D5kc Can we do something here? NI Jared since Paolo is away.

I would consider this a known issue that will hopefully get fixed by bug 1009116.

>Status: RESOLVED → VERIFIED Comment 9, How about uplift?

(In reply to magicp from comment #13) > Comment 9, How about uplift? Hi Ritu, perhaps can you answer this?

Comment on attachment 8788900 [details] Bug 1300556 - Adjust the height of the Downloads Panel if downloads are removed while the panel is hidden. It's a minor UI issue, but since the fix was verified on Nightly and 50 is still in aurora cycle, let's take it.

verified in 50.0a2 (Build ID 20160914004005)