1068656 - [userstory] Implement new Downloads Panel item state for items that can be unblocked

Status: NEW

(Firefox :: Downloads Panel, defect)

Comment 1

[:Paolo Amadini]

This bug is about the part of the work defined by bug 1062966 related to adding the new panel item state for downloads that can be unblocked. This is just the item itself, the confirmation dialog can be implemented separately in bug 1068660.

This should be based on the mockups in bug 1053890 and their evolution, as well as the strings in bug 1063105.

Comment 2

[Mark Hammond [:markh] [:mhammond]]

I'm not going to get to this in this iteration.

Comment 3

[[:mmc] Monica Chew (no longer reading bugmail)]

Is there anyone who can take this bug? This is blocking turning on remote lookups for application reputation, which accounts for approximately half of malware classifications.

Comment 4

[:Gavin Sharp [email: [e-mail]]]

We've been blocked on bug 1068664 for a while. We'll figure something out this week.

Comment 5

[Jared Wein [:jaws] (please needinfo? me)]

Gavin has asked me to take this. I'm not sure if I'll get to it in 37.1. It may slip until 37.2. Marco, can you please add this for the 37.1 iteration?

Comment 6

[Marco Mucci [:MarcoM]]

Added to IT 37.1

Comment 7

[:Paolo Amadini]

Jared, I took a closer look at the front-end code, and now this bug seems to me to be quite more difficult than I though initially, since the changes must be done for both the Downloads Panel and the Downloads View in the Library, or in content for private windows. Most things are currently implemented separately.

Also, we currently reduce the download state to an integer. This is a legacy from the old interface, and this patch would need to look at other state instead, requiring a deeper CSS refactor.

I'm looking into possible simplifications. Since I know you're working on other priorities at this time, I might have something ready before you even start working on this bug. However, I believe this simplification work shouldn't stop you from getting a preliminary version out with the current state.

You may see some related review requests from me in the next few days, but there is no hurry to handle them.

Comment 8

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

(In reply to :Paolo Amadini from comment #7)
> the Downloads View in the
> Library, or in content for private windows.

These 2 views are managed by the same code (allDownloadsViewOverlay), only the surrounding code changes (browser/components/places/content/downloadsViewOverlay.xul or browser/components/downloads/content/contentAreaDownloadsView.xul)

Comment 9

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to :Paolo Amadini from comment #7)
> I'm looking into possible simplifications. Since I know you're working on
> other priorities at this time, I might have something ready before you even
> start working on this bug. However, I believe this simplification work
> shouldn't stop you from getting a preliminary version out with the current
> state.

I've actually been working on this now for a couple days, and I agree that the task is much larger than I initially assumed. I'm thinking of ways that this bug may be broken down.

Comment 10

[:Paolo Amadini]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #9)
> I've actually been working on this now for a couple days, and I agree that
> the task is much larger than I initially assumed. I'm thinking of ways that
> this bug may be broken down.

First things first, I've made the code style consistent in bug 1115364 - will make code easier to read and move around across files.

I'm using dependencies of this bug to track my work, if it turns out your work spans more than one bug as well, we may actually turn this into a meta-bug.

Comment 12

[Lukas Blakk [:lsblakk] use ?needinfo]

We don't use the relnote keyword, changing to the relnote-firefox ? flag so this will be noted when it's fixed.

Comment 13

[Jared Wein [:jaws] (please needinfo? me)]

This bug is currently stalled until the refactoring work is complete. When this bug is picked back up, I'll break it down in to smaller chunks that will be easier to implement and review.

Comment 14

[Jared Wein [:jaws] (please needinfo? me)]

Paolo, can you drive this bug to completion? The patch that I have so far can be found at http://hg.mozilla.org/users/jwein_mozilla.com/jaws/file/cadb078649a7/1068656.patch, but it is not based off of your latest refactorings.

Comment 15

[:Paolo Amadini]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #14)
> Paolo, can you drive this bug to completion? The patch that I have so far
> can be found at
> http://hg.mozilla.org/users/jwein_mozilla.com/jaws/file/cadb078649a7/1068656.
> patch, but it is not based off of your latest refactorings.

Thanks for the reference, I'll work on updating the refactorings this week, then I can use your patch as a starting point.

Comment 16

[Tanvi Vyas[:tanvi]]

Hi Paolo and Jared,

Any update on this bug?  Looks like there is only once dependency that is still open - https://bugzilla.mozilla.org/show_bug.cgi?id=1117145

Comment 17

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Tanvi Vyas [:tanvi] from comment #16)
> Hi Paolo and Jared,
> 
> Any update on this bug?  Looks like there is only once dependency that is
> still open - https://bugzilla.mozilla.org/show_bug.cgi?id=1117145

Hi Tanvi, Paolo and I have met and discussed what would be necessary to move this bug forward. We will be filing a bug blocking this one to outline the steps.

Comment 18

[:Paolo Amadini]

I thought I had already filed the final item implementation as a separate bug, but this one was probably intended to be the implementation one originally, so I filed bug 1198181 instead.

Comment 19

[Liz Henry (:lizzard) (relman/hg->git project)]

Doing some release note flag cleanup. This was released in Firefox 48 and wasn't relnoted.