Open
Bug 844341
Opened 12 years ago
Updated 2 years ago
The position of the downloads indicator changes position when downloading background themes.
Categories
(Firefox :: Downloads Panel, defect)
Tracking
()
REOPENED
People
(Reporter: gaby2300, Assigned: mconley)
References
Details
(Keywords: regression, Whiteboard: [[testday-20130222])
Attachments
(2 files)
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.
Reporter | ||
Comment 1•12 years ago
|
||
Reporter | ||
Updated•12 years ago
|
Whiteboard: [[testday-20130222]
Comment 2•12 years ago
|
||
Setting as blocker for bug 564934 as per instructions (https://wiki.mozilla.org/User:P.A./Panel-based_Download_Manager/Status)
Blocks: DownloadsPanel
Updated•12 years ago
|
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 4•12 years ago
|
||
(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•12 years ago
|
||
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•12 years ago
|
||
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 → ---
Comment 7•12 years ago
|
||
then it must have been regressed by something else, since we already fixed this bug in the past.
Keywords: regression,
regressionwindow-wanted
Assignee | ||
Updated•12 years ago
|
Assignee: nobody → mconley
Assignee | ||
Comment 10•12 years ago
|
||
Confirmed in latest Beta on Windows 7. Investigating...
Assignee | ||
Updated•12 years ago
|
status-firefox20:
--- → affected
tracking-firefox20:
--- → ?
Comment 11•12 years ago
|
||
(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
status-firefox20:
affected → ---
tracking-firefox20:
? → ---
Updated•12 years ago
|
status-firefox20:
--- → affected
tracking-firefox20:
--- → ?
Assignee | ||
Comment 12•12 years ago
|
||
This appears to affect new profiles on Nightly as well.
status-firefox22:
--- → affected
Assignee | ||
Comment 13•12 years ago
|
||
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.
status-firefox22:
affected → ---
Comment 14•12 years ago
|
||
if the feedback button is added to the currentSet dinamically and doesn't set skipintoolbarset is quite likely to cause the issue
Comment 15•12 years ago
|
||
Since it's likely a user confusing/annoying regression in a new feature, tracking.
status-firefox21:
--- → affected
status-firefox22:
--- → affected
tracking-firefox21:
--- → +
tracking-firefox22:
--- → +
Assignee | ||
Comment 16•12 years ago
|
||
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.
Assignee | ||
Comment 17•12 years ago
|
||
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.
Updated•12 years ago
|
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.
Comment 18•12 years ago
|
||
(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
Keywords: regressionwindow-wanted
Comment 19•12 years ago
|
||
(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 !
Updated•12 years ago
|
Flags: needinfo?(simona.marcu)
Comment 20•12 years ago
|
||
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)
Comment 21•12 years ago
|
||
(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.
Assignee | ||
Comment 22•12 years ago
|
||
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)
Comment 23•12 years ago
|
||
(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)
Updated•12 years ago
|
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•