Open Bug 844341 Opened 7 years ago Updated 7 years ago

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

Categories

(Firefox :: Downloads Panel, defect)

20 Branch
x86_64
Windows 7
defect
Not set

Tracking

()

REOPENED
Tracking Status
firefox20 + wontfix
firefox21 + wontfix
firefox22 + unaffected

People

(Reporter: gaby2300, Assigned: mconley)

References

Details

(Keywords: regression, Whiteboard: [[testday-20130222])

Attachments

(2 files)

Attached image 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.
Attached image After the download
Whiteboard: [[testday-20130222]
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 832969
(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!
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?
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).
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
then it must have been regressed by something else, since we already fixed this bug in the past.
Assignee: nobody → mconley
fwiw, I cannot reproduce on win 7 x64
Assignee: mconley → nobody
dumb bugzilla overwriting changes :)
Assignee: nobody → mconley
Confirmed in latest Beta on Windows 7. Investigating...
(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
This appears to affect new profiles on Nightly as well.
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.
if the feedback button is added to the currentSet dinamically and doesn't set skipintoolbarset is quite likely to cause the issue
Since it's likely a user confusing/annoying regression in a new feature, tracking.
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.
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.
Summary: The position of the downloads indicator changes position when donloading background themes. → The position of the downloads indicator changes position when downloading background themes.
(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
(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 !
Flags: needinfo?(simona.marcu)
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)
Flags: needinfo?(simona.marcu)
(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.
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
Flags: needinfo?(bbajaj)
(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
Flags: needinfo?(bbajaj)
You need to log in before you can comment on or make changes to this bug.