Bugzilla

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 you might start a very long download and get no notification when it's finished. 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 design. 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](https://i.imgur.com/Yi20h81.png) 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.

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 get no notification when it's finished. 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 design. 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](https://i.imgur.com/Yi20h81.png) 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.

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 design. 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](https://i.imgur.com/Yi20h81.png) 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.

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](https://i.imgur.com/Yi20h81.png) 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.