1759676 - Warning badge on download toolbutton does not display when the download fails if the downloads panel is open at that time

Status: RESOLVED WONTFIX

(Firefox :: Downloads Panel, defect, P3)

Description

[Alice0775 White]

Steps To Reproduce:

1. Save/download something that should fail to download

Actual results:
Warning badge on download toolbutton does not display when the download fails.

Expected results:
Warning badge on download toolbutton should display.

Comment 1

[Alice0775 White]

Attachment: screenshot

Comment 2

[Alice0775 White]

This is because when the download finishes, the download panel is now forcefully opened.

Setting browser.download.alwaysOpenPanel = false will fix this issue.

Comment 3

[:Gijs (he/him)]

(In reply to Alice0775 White from comment #2)

This is because when the download finishes, the download panel is now forcefully opened.

It's not, though - it is opened when the download starts. I guess for failed downloads this doesn't matter, maybe? It's not really clear from comment 0 - what is a "failing" download in this context - can you give an example link or workflow? Does the download fail to start, or break mid-way, or...?

Comment 4

[Alice0775 White]

(In reply to :Gijs (he/him) from comment #3)

(In reply to Alice0775 White from comment #2)

This is because when the download finishes, the download panel is now forcefully opened.

It's not, though - it is opened when the download starts.

yep.

I guess for failed downloads this doesn't matter, maybe? It's not really clear from comment 0 - what is a "failing" download in this context - can you give an example link or workflow?

Steps to Reproduce

1. Start Firefox98 or Nightly100.0a1 with clean new profile
2. Install an addon from amo https://addons.mozilla.org/en-US/firefox/addon/ublock-origin/
   (this step is force to fail the download)
3. Open https://ncode.syosetu.com/n5530cf/29/
4. "Save Page As..." from menu or context menu
   I

Does the download fail to start, or break mid-way, or...?

It is during the download process that it fails.

Comment 5

[:Gijs (he/him)]

TBH I'm not sure how severe this is, given the downloads panel is open and that has "Failed" text for the download in question if/when it fails. Certainly there'd have to be some kind of UX question here about when the badge would show up at all in these circumstances, or if it'd show up on the individual download or something (but is that noticeable enough?).

Feels to me like I'd rather spend the time to fix the issue causing the download to fail with uBlock installed (bug 1445211 and friends). Molly/Sam, thoughts?

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1733587

Comment 7

[Sam Foster [:sfoster] (he/him)]

(In reply to :Gijs (he/him) from comment #5)

TBH I'm not sure how severe this is, given the downloads panel is open and that has "Failed" text for the download in question if/when it fails. Certainly there'd have to be some kind of UX question here about when the badge would show up at all in these circumstances, or if it'd show up on the individual download or something (but is that noticeable enough?).

Feels to me like I'd rather spend the time to fix the issue causing the download to fail with uBlock installed (bug 1445211 and friends). Molly/Sam, thoughts?

Failed downloads is normal and expected though, so we should support that - even if this particular case is avoidable? I guess we previously expected the be able to update the panel state when it got opened. Now it gets opened automatically we need to update it on the fly?

The binding between downloads state and the UI - in particular the download panel - is pretty complicated/indirect and prone to this kind of thing. I'm not sure if this is the straw that warrants improving how that all works but I do think we'll see issues like this for as long as that work remains todo. That said, I know there was some work in this area which I've not looked at so I could be off base.

Comment 8

[Molly Howell (she/her) (no longer active)]

I do agree that we need to support failures in general, and also that this is a problem that ought to be fixed. But also, we do already have an indication on the screen that the download failed, which is the entry in the panel itself. And if opening the panel is disabled, then you do get the badge as usual, so there's no regression in that case. So, bottom line, I think we do have an issue here, but not at all a serious one.

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:mak, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 10

[Shane Hughes [:aminomancer]]

Alice is correct, it is not showing the indicator because of the patch for bug 1749784. Rather than just clearing indicators from the downloads view, opening any downloads view will clear existing indicator state and suppress future indicator notifications until the view is closed. So while the downloads view is open, no badges will be added to the downloads button.

It's a tradeoff I was considering and I tested different options. Although you kinda fizzle the indicators this way, I have to consider what the indicators were for. They existed before this alwaysOpenPanel feature. And back then, without the indicators, you might start a very long download, and there's no popup when it's finished for the default action. Back like 10-20 versions ago the downloads button had a really big finish animation too (in terms of pixel dimensions). So it would get your attention since nothing else was necessarily going to.

But if a download is added and the panel opens, and the download finishes (or is blocked, or fails) while the panel is still open, there's no need for anything to get your attention since the panel is dramatically larger and more noticeable than a 12px indicator. That makes the indicators redundant in that specific context (and that's currently the only context in which indicators are suppressed), so the interest is low I think.

I would have omitted the whole suppression feature altogether (or at least made suppression only apply to the success indicator), except I think it looks really janky to have an indicator appear while the panel is open. That's because I perceive those badges as something to get your attention to incite you to click the affordance that has a badge on it. But the effect of clicking, the action, is to open the panel that's already open. So the badge is inviting you to open something that's already open, which makes it look like a bug.

It's further compounded by some extra jank as we figure out what to do with the indicator next. Do we clear it when the panel is closed? When the download element that spawned the indicator notification is clicked/activated? Or do we just leave the indicator alone until the next time the panel is opened? That would probably prompt some users (me) to needlessly click the button again just to get rid of the badge, since it irritates them.

For me, those options all elicit an unpolished feeling, since even if a lot of thought goes into that decision, from the user's point of view those seem like the results of some design oversight or general sloppiness. Whereas the user can at least intuitively see why a badge (whose purpose is to get you to click the button) is not appearing when its button is already "open". So I felt like it's the lesser of two evils.

I do think it's important for the failure or blocked states to be highly noticeable, but since the user is interacting with the downloads panel (either because they just started the download by their own interaction, or because the downloads panel automatically opened when a download finished), they're already paying attention to elements in the downloads panel.

Those states could also be made more noticeable by adjusting the design of the panel's download elements. Making the icons and font bolder and more colorful would have that effect. So would giving blocked/failed download elements a different background color. I did something similar recently when making an app menu panel for extensions. The unverified extensions are marked with text but they also get a yellow "warning" background. I wouldn't recommend using a colored background obviously, it needs to be something easily themeable. But even if the background is just slightly dimmed (or you just use the actual --arrowpanel-dimmed property), that would make it clear that something is special/wrong about the download in question.

Comment 11

[Romain Testard [:RT]]

Given that the panel opens and clearly states that the download failed, it seems clear enough for the users that a failure happened so we decided there is no need for fixing the disappearance of the badge upon opening the panel.