Given that the #downloads-indicator-progress-area is made invisible when counter, progress or paused is not set: 84 #downloads-indicator:not(:-moz-any([progress], 85 [counter], 86 [paused])) 87 #downloads-indicator-progress-area 88 89 { 90 visibility: hidden; 91 } The following lines are therefor useless: 187 #downloads-indicator:not([counter]) > #downloads-indicator-anchor > #downloads-indicator-progress-area > #downloads-indicator-counter { 188 background: -moz-image-rect(url("chrome://browser/skin/Toolbar.png"), 189 0, 108, 18, 90) center no-repeat; 190 background-size: 12px; 191 } 192 193 #downloads-indicator:not([counter])[attention] > #downloads-indicator-anchor > #downloads-indicator-progress-area > #downloads-indicator-counter { 194 background-image: url("chrome://browser/skin/downloads/download-glow.png"); 195 } As when counter is not set, the ...-progress-area is invisible, and therefor also the -counter is invisible. So these rules are useless.

I didn't mean to remove blocking, though blocking that bug was done when we didn't have a component in bugzilla, now that we have a component it's no more needed.

So this bug is actually invalid, the visibility hidden rule acts if not-progress, not-counter and not-paused, the other rules act if not-counter, thus they are valid for the progress and paused cases where the area is visible. I admit this is confusing, the not-counter rule there is just a shortcut to -moz-any([progress],[paused])... I will ask to add a comment in bug 831639 (where I actually hit the same confusing rule)