Closed
Bug 746772
Opened 13 years ago
Closed 12 years ago
Downloads button disappears from toolbar when customizing
Categories
(Firefox :: Downloads Panel, defect)
Firefox
Downloads Panel
Tracking
()
VERIFIED
FIXED
People
(Reporter: djcater+bugzilla, Unassigned)
References
Details
(Keywords: ux-consistency)
Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120418 Firefox/14.0a1
New profile.
1. Start a download.
2. Observe that download button has appeared on the toolbar, to the right of the home button.
3. Customize toolbar.
4. Download button disappears from toolbar.
This is confusing. The download button is in the palette, but it disappears from the toolbar.
My reason for wanting to move it is that I like having the home button as the rightmost button because: (I use it a lot && I use maximised windows && Fitt's Law).
That in itself might be worthy of another bug (people are more likely to use the home button than the downloads button I expect), but I'll leave that for now.
Blocks: DownloadsPanel
No longer depends on: DownloadsPanel
Updated•13 years ago
|
Blocks: ReleaseDownloadsPane
Updated•13 years ago
|
Component: General → Downloads Panel
Updated•13 years ago
|
QA Contact: general → downloads.panel
Comment 1•13 years ago
|
||
The downloads button should be fixed on the nav-bar and be always visible to handle bugs of this kind. Users should not be allowed to remove it but still have the ability to add buttons before or after it. This kind of behavior is already followed for the close button in the addon bar.
When a user disables the nav-bar the button may be added to the Tabs toolbar which is always visible. Thanks for already doing this!
Comment 2•13 years ago
|
||
> Users should not be allowed to remove it but still have the ability to add buttons before or after it.
This would remove the ability to move the downloads button to the addon bar, which may be undesirable.
Comment 3•13 years ago
|
||
(In reply to Marcel Dejean from comment #2)
> This would remove the ability to move the downloads button to the addon bar,
> which may be undesirable.
An arrow panel popping upwards from the addon bar would look broken. You can see it yourself. I wonder how many users know that they can customize the layout of buttons.
Given the fact that this is a new feature no one would complain that they can no longer open the downloads popup from the addon bar.
Comment 4•13 years ago
|
||
> An arrow panel popping upwards from the addon bar would look broken. You can see it yourself.
Looks just fine to me. A reversed order would be preferable, though, with the most recent download at the bottom and 'Show All Downloads' at the top.
> I wonder how many users know that they can customize the layout of buttons.
Enough for us to keep that feature.
> Given the fact that this is a new feature no one would complain that they can no longer open the downloads popup from the addon bar.
They will instead complain that they cannot move the downloads button to where they had it before.
Comment 5•13 years ago
|
||
I don't understand why the Downloads button shouldn't be allowed to be removed. Every other button and control on the navigation bar can be removed. We anyway need to handle the case of the navigation bar being hidden, and what happens if you summon the downloads panel. I think the behaviour in this case should be the same as what it seems to do currently if you have the navigation bar hidden -- a temporary Downloads button appears on the tab bar and the panel pops out from that.
Comment 6•13 years ago
|
||
please, stop the discussion until we finalize the interaction, all of these topics have been discussed and over-discussed already, and are being taken into consideration already.
Updated•12 years ago
|
OS: Linux → All
Comment 11•12 years ago
|
||
I'm pretty sure this has been obsoleted by bug 748381.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment 12•12 years ago
|
||
Verified on the latest Nightly that the Downloads button doesn't disappear when customizing it's position.
Verified on Windows 7, Ubuntu 12.04 and Mac OS X 10.7:
Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/19.0 Firefox/19.0
Build ID: 20121111030749
Mozilla/5.0 (X11; Linux i686; rv:19.0) Gecko/19.0 Firefox/19.0
Build ID: 20121112030753
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:19.0) Gecko/19.0 Firefox/19.0
Build ID: 20121112030753
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•