1276973 - "Clear Downloads" does not start disabled with empty list

Status: VERIFIED FIXED

(Firefox :: Downloads Panel, defect, P3)

Description

[johngraciliano]

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160526140250

Steps to reproduce:

1. Start Firefox (47 or later).
2. Open the Library (e.g., Crtl-Shift-B).
3. Select Downloads.
4. Press "Clear Downloads" if there are any downloads listed.
5. Repeat steps 1-3 if necessary to confirm the problem.


Actual results:

The "Clear Downloads" button should be disabled (gray) if there are no downloads.  It turns that way after clearing any downloads if they were present.  However if Firefox starts with no downloads present the button does not start disabled.


Expected results:

When Firefox starts with no downloads present, the "Clear Downloads" button should default to disabled, as it is in Firefox 46 and earlier.

Comment 1

[Loic]

I can't reproduce it with the latest Beta. can you test with a fresh profile, please.
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

Comment 2

[johngraciliano]

I still find the problem when I tried this:

1. Start Firefox 47 rc profile manager from the command line:
"C:\Program Files (x86)\Firefox 47.0b\firefox.exe" -profilemanager

2. Created a new profile and started using it.

3. Pressed Ctrl-J

The button for "Clear Downloads" was black.   Only after downloading something and then clearing downloads it turned gray.  After restarting Firefox it returned to be black.

Comment 3

[Anders Öhrt]

I'm also seeing this problem, just as described by John above.

In addition, the "Clear Downloads" is not enabled (turned black) when a download finishes if the downloads window is displayed. I need to close the window and re-open if to be able to click "Clear Downloads".

Comment 4

[that-ben]

This bug still exists in Firefox 47.0 on Windows 7 64-bits.

Comment 5

[Loic]

(In reply to johngraciliano from comment #2)
> I still find the problem when I tried this:
> 
> 1. Start Firefox 47 rc profile manager from the command line:
> "C:\Program Files (x86)\Firefox 47.0b\firefox.exe" -profilemanager
> 
> 2. Created a new profile and started using it.
> 
> 3. Pressed Ctrl-J
> 
> The button for "Clear Downloads" was black.   Only after downloading
> something and then clearing downloads it turned gray.  After restarting
> Firefox it returned to be black.

I'm able to reproduce the regression with these STR, ty.

(In reply to Anders Öhrt from comment #3)
> I'm also seeing this problem, just as described by John above.
> 
> In addition, the "Clear Downloads" is not enabled (turned black) when a
> download finishes if the downloads window is displayed. I need to close the
> window and re-open if to be able to click "Clear Downloads".


Sorry, I can't reproduce it. If I download a file and keep the download window open (with Ctrl+J) with the "clear downloads" button greyed out, the button becomes active after the download finished.

Comment 6

[Loic]

Reg range:
https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=0a58b5b8a407f1420ce27b09554305c6b4bebfa2&tochange=3b3428c04743ca6da4472583dc809ae78cd3a5db


Regressed by Bug 1117145.

Comment 7

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

While this maybe a valid issue it isn't critical enough to be included in a 47 dot release.

Comment 8

[:Paolo Amadini]

May indeed be related to bug 1280799.

Comment 9

[Jorg K (CEST = GMT+2)]

Fixed by bug 1280799.

Comment 10

[Loic]

I tested with the latest Nightly (6/26), it's not fixed. Maybe in the build of Monday.

Comment 11

[Jorg K (CEST = GMT+2)]

Oops, I made this a duplicate too early. With Nightly of 26 June 2016 bug 1280799 is fixed, but this bug here isn't.

Comment 12

[Gerry Chang [:gchang]]

Track this as this is a regression issue.

Comment 13

[Gerry Chang [:gchang]]

Hi :jaws,
Since you fixed bug 1280799, not sure if these 2 bugs are related, can you help to investigate this issue?

Comment 14

[:Paolo Amadini]

This should have been fixed by bug 1282050.

Comment 15

[Gerry Chang [:gchang]]

Hi Andrei,
Can you help to find someone to verify if this issue is fixed in 49/50?

Comment 16

[Loic]

Working range:
https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=bc547f508f58108db8b9ad9c2b94f130c07de194&tochange=1249782e3771430f4328851c1e8d198c204a4cd0

I can't reproduce it anymore with the latest Aurora/Nightly on Win 7 64b.

Comment 17

[Ciprian Georgiu, Desktop QA]

I've managed to reproduce this bug on Firefox 47.0 (2016-06-04) using Windows 10, 64-bit.

The issue is verified fixed on beta 49.0b3 (2016-08-11) and latest aurora 50.0a2 (2016-08-11) running, Windows 10, 64-bit, Mac OS X 10.11 and Ubuntu 12.04 LTS 32-bit

Comment 18

[Gerry Chang [:gchang]]

Per comment #14 and #17, mark 49/50 as fixed.

Comment 19

[Ciprian Georgiu, Desktop QA]

Per comment 16 and based on my results from comment 17, I will mark this as verified fixed.