884370 - Downloads button switches to overflow button when download starts

Status: RESOLVED FIXED

(Firefox :: Toolbars and Customization, defect)

Description

[:Margaret Leibovic]

Attachment: screenshot

I can't reliably reproduce this, but I noticed that when starting a download today, my downloads button turned into the overflow button.

The only thing in the overflow menu is the downloads button, and it seems odd to only have one item in the overflow menu, since it looks like there's room for it on the toolbar. The things I have in my toolbar, from left to right, are: URL bar, Facebook social API button, bookmark button, downloads button.

I attached a screenshot of what it looks like after this happened.

Comment 1

[u428464]

Dupe of bug 875816 ?

Comment 3

[:Gijs (he/him)]

I can't reproduce this anymore. Has anyone else seen this recently?

Comment 4

[Sören Hentzschel]

Attachment: screenshot

(In reply to :Gijs Kruitbosch from comment #3)
> I can't reproduce this anymore. Has anyone else seen this recently?

yes, just now with the ux build from 2013-07-18.

Comment 5

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

Paolo, do you think you can take this? This is likely to do with how the downloads button is replaced when a download starts.

Comment 6

[:Paolo Amadini]

(In reply to Jared Wein [:jaws] from comment #5)
> Paolo, do you think you can take this? This is likely to do with how the
> downloads button is replaced when a download starts.

Unfortunately I don't know the Australis overflow code that much, and given my
current focus on the Downloads API I don't think I can make any Australis
blocking paths advance faster right now.

Mike Conley may be the person that has the best knowledge of both worlds here.

Comment 7

[:Gijs (he/him)]

(In reply to :Paolo Amadini from comment #6)
> (In reply to Jared Wein [:jaws] from comment #5)
> > Paolo, do you think you can take this? This is likely to do with how the
> > downloads button is replaced when a download starts.
> 
> Unfortunately I don't know the Australis overflow code that much, and given
> my
> current focus on the Downloads API I don't think I can make any Australis
> blocking paths advance faster right now.
> 
> Mike Conley may be the person that has the best knowledge of both worlds
> here.

I'm happy to have a look at this considering my recent adventures with the overflow code... but I could never reproduce this. Does anyone have reliable STR? Sören, perhaps?

Comment 8

[Mike Conley (:mconley) (:⚙️)]

Oh, I think I know why this is.

As some of you are already aware, we do some pretty fancy sleight of hand with the downloads button - there's a placeholder node that we show on start-up (and during customization) that is swapped out when a download starts, or when the panel is opened.

Looking at the code that does that swapping:

http://mxr.mozilla.org/mozilla-central/source/browser/components/downloads/content/indicator.js#165

We insert the indicator, then we hide the placeholder. If inserting the indicator causes overflow, I can see that triggering the OverflowToolbar before the collapse happens.

This might be as simple as collapsing the placeholder before doing the insertion instead of after.

(Or, even better, getting rid of the placeholder entirely... *cough* bug 845408 *cough*)

Comment 9

[:Gijs (he/him)]

(In reply to Mike Conley (:mconley) from comment #8)
> Oh, I think I know why this is.
> 
> As some of you are already aware, we do some pretty fancy sleight of hand
> with the downloads button - there's a placeholder node that we show on
> start-up (and during customization) that is swapped out when a download
> starts, or when the panel is opened.
> 
> Looking at the code that does that swapping:
> 
> http://mxr.mozilla.org/mozilla-central/source/browser/components/downloads/
> content/indicator.js#165
> 
> We insert the indicator, then we hide the placeholder. If inserting the
> indicator causes overflow, I can see that triggering the OverflowToolbar
> before the collapse happens.
> 
> This might be as simple as collapsing the placeholder before doing the
> insertion instead of after.
> 
> (Or, even better, getting rid of the placeholder entirely... *cough* bug
> 845408 *cough*)

But that sounds like I should be able to reproduce this consistently, and although I've been trying my darndest, I haven't managed. I resized my window to within a teeeny bit of overflowing, and then start a download (long or short doesn't seem to make a difference). I just get the progress bar of the download indicator, and nothing overflows. (all this on OS X 10.8, with a retina screen, so maybe that has something to do with it? I dunno...)

There's a separate issue on the very latest builds where if the download button is every overflowed, and then stops being overflowed, it gets put at the beginning of the navbar. That's probably because of bug 913972. I can file a separate bug for that, but tbh, I really think we should just fix all this download-button magic to be less magical.

Comment 10

[Mike Conley (:mconley) (:⚙️)]

(In reply to :Gijs Kruitbosch from comment #9)

> But that sounds like I should be able to reproduce this consistently, and
> although I've been trying my darndest, I haven't managed.

Just so we're clear - the behaviour I suggested would only be triggered if the overlay hasn't been loaded yet, and the placeholder hasn't been swapped out.

> I really think we should just fix all
> this download-button magic to be less magical.

I agree. The original impetus to make the button so magical was because there was some suspicion that it caused a ts_paint regression (remember that old chestnut?). Marco wasn't convinced that it was actually the cause though...

Comment 11

[Mike de Boer [:mikedeboer]]

This bug has been stale for a while, without any new input that this is in fact reproducable. +1 to resolve this to WORKSFORME until someone, perhaps Sören Hentzschel?, can come up with a solid STR.

Comment 12

[Sören Hentzschel]

Unfortunately I have no STR, sometimes the issue occurs, sometimes not, but it happens almost every day. :( The download button does not switch to overflow when the download starts (as the bug title suggest) but when the download is completed (see duplicate bug 875816).

Comment 13

[u428464]

Same for me. The bug appears frequently but randomly.

Comment 14

[Mike Conley (:mconley) (:⚙️)]

(In reply to Mike de Boer [:mikedeboer] from comment #11)
> This bug has been stale for a while, without any new input that this is in
> fact reproducable. +1 to resolve this to WORKSFORME until someone, perhaps
> Sören Hentzschel?, can come up with a solid STR.

I too don't have reliable STR. It's intermittent. I don't think we can resolve WORKFORME while the behaviour keeps popping up...

Comment 15

[:Gijs (he/him)]

Possibly related: bug 917760.

Comment 16

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

Gijs, you've been been looking in to a potentially related issue in bug 845408. Do you think fixing that bug would fix this bug?

Comment 17

[:Gijs (he/him)]

(In reply to Jared Wein [:jaws] from comment #16)
> Gijs, you've been been looking in to a potentially related issue in bug
> 845408. Do you think fixing that bug would fix this bug?

To be perfectly honest, I don't know. I've tried frequently but can't actually reproduce this bug anymore, so I also don't know what causes it and if bug 845408 will be enough to fix this or not.

Comment 18

[:Gijs (he/him)]

I think I've figured out why this is. The download start/finish animation is triggering an overflow event, because it animates the icon to be bigger, which will "sometimes" cause an overflow event (depends if the window is focused, and on luck, apparently).

To make this easier to reproduce, set the animation interval to 10s instead of 1s, and then manually set the notification attribute to "finish" on the downloads-indicator button.

So this is related to bug 886939. However, I suspect we can fix most of bug 886939 by just setting overflow-x: hidden instead of overflow: hidden, but that will not fix this bug. In order to fix this one, we'd need to figure out a different way to do the animation which doesn't trigger the overflow event (which isn't triggered on the <stack> used by the button, but on the nav-bar's customization container). I don't really have much of an idea in that department at the minute.

Comment 19

[:Gijs (he/him)]

(In reply to :Gijs Kruitbosch from comment #18)
> So this is related to bug 886939. However, I suspect we can fix most of bug
> 886939 by just setting overflow-x: hidden instead of overflow: hidden, but
> that will not fix this bug. In order to fix this one, we'd need to figure
> out a different way to do the animation which doesn't trigger the overflow
> event (which isn't triggered on the <stack> used by the button, but on the
> nav-bar's customization container). I don't really have much of an idea in
> that department at the minute.


So it turns out fixing bug 886939 isn't as trivial as I thought, because overflowing in only one direction implies scrolling in the other direction. So that didn't work out.

On the plus side, I have a patch locally which moves the animation into a separate element and animates onto an arbitrary anchor. I'll file a separate bug for that to block this, bug 886939, and bug 916256.

Comment 20

[:Gijs (he/him)]

This should be fixed by bug 922847.