844341 - The position of the downloads indicator changes position when downloading background themes.

Status: REOPENED

(Firefox :: Downloads Panel, defect)

Description

[Gabriela [:gaby2300]]

Attachment: Before the download

The position of the downloads indicator changes from the first placed icon to the last one when downloading background themes.

1. Open the latest Beta.
2. Note the position of the downloads indicator.
2. Browse to https://addons.mozilla.org/en-US/firefox/themes
3. Download a theme.
4. Note the position of the downloads indicator has changed. (In my case, it changed from the placed icon to the last one, see the screenshots).

Actual results:
The position of the downloads indicator changes from the first placed icon to the last one.

Expected results:
The position of the downloads indicator remains the same.

I'm using the latest Beta (build 2)and Windows 7 64 bit.

Comment 1

[Gabriela [:gaby2300]]

Attachment: After the download

Comment 2

[Jonah Ho (AAstar)]

Setting as blocker for bug 564934 as per instructions (https://wiki.mozilla.org/User:P.A./Panel-based_Download_Manager/Status)

Comment 4

[Gabriela [:gaby2300]]

(In reply to Simona B [QA] from comment #3)
> 
> *** This bug has been marked as a duplicate of bug 832969 ***


Simona, I'm sorry but I don't think this bug is a duplicate of bug 832969 at all.
Bug 832969 is about the downloads panel jumping around when previewing or applying background themes. Bug 844341 instead, is about the downloads indicator changing position, but not the download panel doing so!

Comment 5

[Marco Bonardo [:mak]]

I suspect this is due to an add-on adding some buttons/overlays to the toolbar, in such case it's invalid, would be good to know if it happens in safe mode (http://support.mozilla.org/en-US/kb/Safe%20Mode). Reporter, copuld you please verify that?

Comment 6

[Simona Badau, Desktop QA]

Sorry Gabriela, you're right, I'm reopening this.

Marco, the issue is easily reproducible on clean profiles following the steps:
1. Launch Firefox with a clean profile
2. Perform any download
3. Go to 
https://addons.mozilla.org/en-US/firefox/themes/
4. Apply or preview any theme.

Actual results:
The position of the downloads indicator is changed (jumps to the right in the navigation bar).

Comment 7

[Marco Bonardo [:mak]]

then it must have been regressed by something else, since we already fixed this bug in the past.

Comment 8

[Marco Bonardo [:mak]]

fwiw, I cannot reproduce on win 7 x64

Comment 9

[Marco Bonardo [:mak]]

dumb bugzilla overwriting changes :)

Comment 10

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

Confirmed in latest Beta on Windows 7. Investigating...

Comment 11

[Simona Badau, Desktop QA]

(In reply to Marco Bonardo [:mak] (Away Mar 1) from comment #8)
> fwiw, I cannot reproduce on win 7 x64

Neither can I - on the latest Nightly and on the latest Aurora. 
Mozilla/5.0 (Windows NT 6.1; rv:22.0) Gecko/20130225 Firefox/22.0
Mozilla/5.0 (Windows NT 6.1; rv:21.0) Gecko/20130225 Firefox/21.0

Reproducible on Firefox 20 beta 1:
Mozilla/5.0 (Windows NT 6.1; rv:20.0) Gecko/20100101 Firefox/20.0 Build ID: 20130220104816

Comment 12

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

This appears to affect new profiles on Nightly as well.

Comment 13

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

Hm - I might be wrong on that. To be more precise - it affects Nightly iff the profile was created and first run with beta.

I've been drilling into this, and I'm starting to suspect that this behaviour is caused by the Feedback button. Digging into it more.

Comment 14

[Marco Bonardo [:mak]]

if the feedback button is added to the currentSet dinamically and doesn't set skipintoolbarset is quite likely to cause the issue

Comment 15

[Lukas Blakk [:lsblakk] use ?needinfo]

Since it's likely a user confusing/annoying regression in a new feature, tracking.

Comment 16

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

Ok, did a bit of investigation, and here's what I found out.

The feedback button is not at fault. It is added both to the toolbar's defaultset attribute, and into the toolbar itself via an overlay. When the toolbar _inits, this defaultset is copied over to currentset.

The problem appears to be another node that comes along with it, "pilot-notification-popup". This is added to the toolbar, but is *not* added to defaultset. When _init is called on the toolbar (which happens when applying or unapplying a lw-theme), the currentset string attribute is compared against the list of comma-separated IDs for the elements in the nav-bar.

If they don't match, the toolbar re-orders all of the buttons according to the ID list in currentset. Since downloads-indicator isn't present in defaultset, things get inserted before it, and it eventually ends up at the end of the toolbar.

The easy fix is to add a skipintoolbarset to pilot-notification-popup, but I'm a little concerned that this problem could crop up again and again with other add-ons or features that do something similar with the nav-bar.

I'm investigating our other options.

Comment 17

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

Marco and I discussed this, and we think this bug is caused primarily by the Feedback add-on that ships with Beta.

Unfortunately, it's possible that other add-ons add buttons to the toolbar in a way similar to Feedback. It's far, far too late to attempt to find a solution to that, so we think we're willing to live with this relatively minor bug for FF 20.

When bug 845408 lands, this bug should no longer be a problem.

Comment 18

[Simona Badau, Desktop QA]

(In reply to Marco Bonardo [:mak] from comment #7)
> then it must have been regressed by something else, since we already fixed
> this bug in the past.

I've been trying to find a regression range for this after Bug 811263 was fixed. So this is what I got:
- the issue is not reproducible on the latest Nightly 22.0a1 (Build ID: 20130321090706) and neither is on Nightly 20.0a1 (after the fix for Bug 811263 landed).
- the issue is not reproducible on the latest Aurora 21.0a2 (Build ID): 20130321042014

However, the issue is still reproducible on Firefox 20 beta 6 and used to be reproducible on Aurora 20.0a2 until January 19th but stopped being reproducible from January 20th.
http://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=a8d6394508a3&tochange=331b0a480586

Comment 19

[bhavana bajaj [:bajaj]]

(In reply to Simona B [QA] from comment #18)
> (In reply to Marco Bonardo [:mak] from comment #7)
> > then it must have been regressed by something else, since we already fixed
> > this bug in the past.
> 
> I've been trying to find a regression range for this after Bug 811263 was
> fixed. So this is what I got:
> - the issue is not reproducible on the latest Nightly 22.0a1 (Build ID:
> 20130321090706) and neither is on Nightly 20.0a1 (after the fix for Bug
> 811263 landed).
> - the issue is not reproducible on the latest Aurora 21.0a2 (Build ID):
> 20130321042014
> 
> However, the issue is still reproducible on Firefox 20 beta 6 and used to be
> reproducible on Aurora 20.0a2 until January 19th but stopped being
> reproducible from January 20th.
> http://hg.mozilla.org/releases/mozilla-aurora/
> pushloghtml?fromchange=a8d6394508a3&tochange=331b0a480586

Simona, can you please help test with the latest beta(21.0b1) and 22 Aurora builds and marked this resolved works for me if this is no longer reproducible ? Thanks !

Comment 20

[Simona Badau, Desktop QA]

I can still reproduce this issue on Firefox 21 beta.
Mozilla/5.0 (Windows NT 6.1; rv:21.0) Gecko/20100101 Firefox/21.0 (20130401192816)

I can't reproduce the issue using the same steps to reproduce on the latest Aurora and Nightly.
Mozilla/5.0 (Windows NT 6.1; rv:22.0) Gecko/20130404 Firefox/22.0 (20130404004013)
Mozilla/5.0 (Windows NT 6.1; rv:23.0) Gecko/20130404 Firefox/23.0 (20130404030859)

Comment 21

[bhavana bajaj [:bajaj]]

(In reply to Mike Conley (:mconley) from comment #17)
> Marco and I discussed this, and we think this bug is caused primarily by the
> Feedback add-on that ships with Beta.
> 
> Unfortunately, it's possible that other add-ons add buttons to the toolbar
> in a way similar to Feedback. It's far, far too late to attempt to find a
> solution to that, so we think we're willing to live with this relatively
> minor bug for FF 20.
> 
> When bug 845408 lands, this bug should no longer be a problem.

Mike, what are the next steps here to get this resolved in Fx21 timeframe? Don't see any action in bug 845408 which could have helped resolve the issue as stated above.

Comment 22

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

Hey Bhavana,

I haven't yet had a chance to measure the performance impact that https://bugzilla.mozilla.org/show_bug.cgi?id=845408#c6 refers to.

My personal evaluation is that this bug is edge-case-y enough to let it slip FF 21. With the Australis widget work underway, this will likely be resolved during the FF 23 or FF 24 cycle.

Is that acceptable? Or do you feel we should attempt to get a fix for 21 in?

-Mike

Comment 23

[bhavana bajaj [:bajaj]]

(In reply to Mike Conley (:mconley) from comment #22)
> Hey Bhavana,
> 
> I haven't yet had a chance to measure the performance impact that
> https://bugzilla.mozilla.org/show_bug.cgi?id=845408#c6 refers to.
> 
> My personal evaluation is that this bug is edge-case-y enough to let it slip
> FF 21. With the Australis widget work underway, this will likely be resolved
> during the FF 23 or FF 24 cycle.
> 
> Is that acceptable? Or do you feel we should attempt to get a fix for 21 in?

Hey Mike, 

Per https://bugzilla.mozilla.org/show_bug.cgi?id=844341#c17 looks like its a primary issue Feedback add-on that ships with Beta, so release population will not be seeing this.

Keeping in mind its a corner case and this will be resolved in future cycles for Beta as well based on the above comments, I'll wontfix for 21. 

Thanks!


> 
> -Mike