Closed Bug 1393213 Opened 7 years ago Closed 7 years ago

Reconsider providing back option to show permanently "Downloads" button and make it movable again in this mode

Categories

(Firefox :: Toolbars and Customization, defect)

Product:
Firefox
Component:
Toolbars and Customization
Version:
57 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 57
Tracking Flags:
Tracking Status
firefox-esr52 --- unaffected
firefox55 --- unaffected
firefox56 --- unaffected
firefox57 --- verified

People

(Reporter: Virtual, Assigned: Gijs)

References

Details

(6 keywords, Whiteboard: [fixed by patch backout from bug #1371765]) 

[Tracking Requested - why for this release]: Regression

Caused by:
bug #1371765

STR:
1. Look in Firefox GUI for "Downloads" button
and see that it's missing there, as it only shows itself, when user downloading files, otherwise it's hidden.

Now, user can't:
- get easy and fast access to latest Downloads in "Downloads" button menu with 1 mouse click from previous browsing session
- get easy and fast access to "Downloads" in Library with 2 mouse clicks
- move "Download" button in Location Bar
- move "Download" button to Bookmark Bar
- move "Download" button to Overflow Menu
- be happy, because extension will be needed for such basic feature

My proposition:
- "Download" button added in "Customize..." mode to Location Bar/Bookmark Bar/Overflow Menu = old always visible "Download" button behavior
- "Download" button removed in "Customize..." mode = new Photon "Download" button behavior with showing "Downloads" button as unmovable, same as Hamburger/Overflow buttons
or other to consider, but don't take away user customization
Has Regression Range: --- → yes
Has STR: --- → yes
No point tracking it before a decision is made.
Has Regression Range: yes → ---
Has STR: yes → ---
tracking-firefox57: ? → ---
Flags: needinfo?(bbell)
Saying the change doesn't allow customization of the Downloads button is a misnomer as the effect is larger.

I have (had) my Bookmarks icon to the right of the URL bar in a consistent space, and now the button moves after I download a file. I use it regularly and now I can't depend on its location.

I don't mind learning new placements after a UI change, but buttons that move from one minute to the next are distracting. I could even tolerate a download button that appeared, as long as I could place it where it wouldn't affect my workflow.
Re-posting from duped bug:

I download a lot of pdf files. I am used to going to the same place to click on the downloads button (not the immediately on the RHS of the location bar, that's where I keep my bookmarks button), so I can open the pdfs. Disrupting this really annoys me. Additionally, Shifting the location of the bookmarks button (I have it adjacent to the location bar) is also very frustrating - I am used to moving the mouse to fixed locations, having to check where the button is located is a very slow and frustrating experience. 

I like my Downloads button where it is. Please let me customise the browser UI in this very simple way.
(In reply to B.J. Herbison from comment #2)
> Saying the change doesn't allow customization of the Downloads button is a
> misnomer as the effect is larger.
> 
> I have (had) my Bookmarks icon to the right of the URL bar in a consistent
> space, and now the button moves after I download a file. I use it regularly
> and now I can't depend on its location.
> 
> I don't mind learning new placements after a UI change, but buttons that
> move from one minute to the next are distracting. I could even tolerate a
> download button that appeared, as long as I could place it where it wouldn't
> affect my workflow.

(re-post from a duplicate bug) 

I understand that this change is potentially jarring, and I'm sorry for any consternation that this might cause. The complete design might satiate any concerns you might have, so please stay tuned. 

I should explain the intent. 

We recognized that The Recent Downloads Menu has very little utility for the user in its empty state, and so we decided to hide it when not needed.  However, its total uselessness in the empty state is not entirely true, because it was the only convenient place to see a listing of downloads from previous sessions. The Library is about to gain a Recent Downloads list so that users can have full-time access that that information. 

It's unfortunate this downloads change landed before the augmentation of the library was able to make it because users would not be losing access to any information. 

I am intrigued as to why Alice and yourself have a desire to control where this menu appears when a Recent Download is present. Having it just to the right of the URL bar seemed like a logical and visible place for it to appear when necessary, but you guys would rather have it show at a predesignated (by yourself) point on the toolbar. What advantage do you feel this change would give you? How would you overcome the problem this change might cause for users who do not have any recent downloads, then add this position designator to their toolbar via customization, but find that that icon disappears when they exit Customization Mode.

---

Ultimately the solution we're moving toward is to create an even better Recent downloads space.  Something that's not a door-hanger in the toolbar. Something that keeps Recent Downloads handy and in sight.
I agree with this bug. Even though you can see your download in library it's not as easily and as quickly accessible.
Download button was perfect for that.

Besides I am also annoyed with the idea that my button will move (or that location or search bar will reduce) when I download something. And even though library might have an entry what about user who do not display library button ? (Yes it is in menu but how many click does it take...)

Finally why keeping download button if access from library is preferred ? I think either :
- library button has to show download progress and indicate completion. Get rid of download button and force library button to be present in any bar. 
- or either download button is kept but user should be able to customize toolbar and make it always visible. Is it hard to add a checkbox in customize to always show download button and enable moving it when it's checked ?
(In reply to Eriatile from comment #6)
> I agree with this bug. Even though you can see your download in library it's
> not as easily and as quickly accessible.
> Download button was perfect for that.

This change doesn't effect this use case. Downloads from this session will always show, and stay available (untill you restart FF) from a downloads icon in the toolbar. 


> though library might have an entry what about user who do not display
> library button ? (Yes it is in menu but how many click does it take...)

The Recent Downloads Report in the library is only meant to replace the "Show All Downloads" button at the bottom of the current Downloads menu. It was 2 clicks to see that report before and it remains 2 clicks in the New Library. 

> Finally why keeping download button if access from library is preferred ? 

This is not so, The Downloads button in the toolbar only show downloads from the current session (just now) to keep things you just now downloaded in sight and available. The downloads report in the library maintains a persistent list of downloads that goes back several sessions so you can recover older downloads. 

> - library button has to show download progress and indicate completion. Get
> rid of download button and force library button to be present in any bar. 

I assure you that the library only replaces the Show All Downloads feature, the download progress bars and the short list of the most recent downloads will still be shown on the (now transient) Downloads Menu. 

> - or either download button is kept but user should be able to customize
> toolbar and make it always visible. Is it hard to add a checkbox in
> customize to always show download button and enable moving it when it's
> checked ?
Flags: needinfo?(bbell)
(In reply to bbell from comment #5)
> I am intrigued as to why Alice and yourself have a desire to control where
> this menu appears when a Recent Download is present. Having it just to the
> right of the URL bar seemed like a logical and visible place for it to
> appear when necessary, but you guys would rather have it show at a
> predesignated (by yourself) point on the toolbar. What advantage do you feel
> this change would give you? How would you overcome the problem this change
> might cause for users who do not have any recent downloads, then add this
> position designator to their toolbar via customization, but find that that
> icon disappears when they exit Customization Mode.

I would also reply to that.
I'm kinda pedantic perfectionist with paying great attention to details,
so I like to move, group and organize browser buttons,
where I like them to be and where I find them most useful for me,
not where someone force them to be.

In my case, I had "Downloads" button grouped in the far right in Bookmarks Toolbar
with other Download Management extensions buttons like:
DownThemAll!/Download Star/Flash Video Downloader - YouTube HD Download [4K]/Downloads(Firefox button).
Looking left, I have privacy and security extensions buttons like:
uBlock Orgin/HTTPS Everywhere/Self-Destructing Cookies/Cookie AutoDelete/Popup Blocker (strict).
Looking more left, I have session extensions buttons like:
Undo Close/Session Manager/History(Firefox button)
In end going to Bookmarks Toolbar Items, so bookmarks without name with only favicons to see more items,
which take over 75% of Bookmarks Toolbar.

I like to keep clean Location Bar from bloat to see more of URLs,
so that's why I don't like this "Downloads" button positioning in Location Bar
without ability to move it elsewhere like to Bookmarks Toolbar and to Overflow button menu,
what's more, I find this hiding and reappearing of "Downloads" button as annoying and irritating for me.
(In reply to Eriatile from comment #6)
> Finally why keeping download button if access from library is preferred ? I
> think either :
> - library button has to show download progress and indicate completion. Get
> rid of download button and force library button to be present in any bar. 

Then people will complain that they cannot move/hide the library button. We'd just be shifting the exact issue this bug got filed about. I don't understand why you think that would help.

> - or either download button is kept but user should be able to customize
> toolbar and make it always visible. Is it hard to add a checkbox in
> customize to always show download button and enable moving it when it's
> checked ?

Yes, that is (very) hard. There would be 1 button that is sometimes movable, and sometimes not, which would likely be difficult to keep track of in the code that handles UI customization. Plus we would need to write a bunch of code to move the button if it *is* movable and not otherwise (especially on startup), and/or to ensure that when this checkbox is changed, we put the button back to the default place somehow, etc. Plus, some other features (like the animation) are currently engineered expecting the downloads button to always be in the navigation toolbar. If it was possible to move it elsewhere or for it to be in the overflow menu, we would have to come up with designs for what happens in those cases (overflow menu, what about if it's in a toolbar that's hidden, etc. etc.) and then implement them.
(In reply to bbell from comment #7)
> This change doesn't effect this use case. Downloads from this session will
> always show, and stay available (untill you restart FF) from a downloads
> icon in the toolbar. 

Are you saying the Downloads button will stay visible forever for users who have Session Restore enabled, unless they manually clear the Downloads list?
(In reply to :Gijs from comment #14)
> (In reply to Eriatile from comment #6)
> > Finally why keeping download button if access from library is preferred ? I
> > think either :
> > - library button has to show download progress and indicate completion. Get
> > rid of download button and force library button to be present in any bar. 
> 
> Then people will complain that they cannot move/hide the library button.
> We'd just be shifting the exact issue this bug got filed about. I don't
> understand why you think that would help.

It would help because library button would always be visible and you won't have a button which is sometimes visible and sometimes not. And user would still be able to move the button. They just won't be able to remove it.
Imho what's the most annoying is having your buttons (or search bar) move because suddenly there is a new button next to the location bar.
(In reply to bintoro from comment #15)
> (In reply to bbell from comment #7)
> > This change doesn't effect this use case. Downloads from this session will
> > always show, and stay available (untill you restart FF) from a downloads
> > icon in the toolbar. 
> 
> Are you saying the Downloads button will stay visible forever for users who
> have Session Restore enabled, unless they manually clear the Downloads list?

Nope. I already tested to restart my session, button was gone until I download something new :)
(In reply to :Gijs from comment #14)
> If it was possible to move it
> elsewhere or for it to be in the overflow menu, we would have to come up
> with designs for what happens in those cases (overflow menu, what about if
> it's in a toolbar that's hidden, etc. etc.) and then implement them.

This got me another simply idea, as bug #1387313 will landing to Nightly soon:
- move "Downloads" button between Overflow button and Hamburger button in Location Bar by default,
so it will stays there as dimmed non-removable item with this new Photon "Download" button behavior,
- if user will move "Bookmarks" button out of this area, to other place in Location Bar or move it elsewhere, to Bookmark Toolbar or Overflow menu, it will be undimmed and will use old always visible "Download" button behavior.
(In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #18)
> (In reply to :Gijs from comment #14)
> > If it was possible to move it
> > elsewhere or for it to be in the overflow menu, we would have to come up
> > with designs for what happens in those cases (overflow menu, what about if
> > it's in a toolbar that's hidden, etc. etc.) and then implement them.
> 
> This got me another simply idea, as bug #1387313 will landing to Nightly
> soon:
> - move "Downloads" button between Overflow button and Hamburger button in
> Location Bar by default,

This part is not part of the customizable area. You can't drag/drop removable/customizable items here right now. Why this part specifically? Why not just leave it in the place it has now in the toolbar?

> so it will stays there as dimmed non-removable item with this new Photon
> "Download" button behavior,
> - if user will move "Bookmarks" button out of this area, to other place in
> Location Bar or move it elsewhere, to Bookmark Toolbar or Overflow menu, it
> will be undimmed and will use old always visible "Download" button behavior.

Do you mean the library? Why would moving bookmarks (which isn't there by default anymore) have any influence over the downloads button? To me this seems like it would not be discoverable for users (who would just try to move the disabled downloads button and fail).
So, something that would be relatively straightforward to implement and would solve the surprising-ordering-in-the-navbar and the not-available-for-dnd-droptarget issues would be:

1) hide the button by default, but add a pref to make it permanently visible (location for checkbox, if any, being tbd - the customize mode footer already has a lot of buttons and is not contextual for the downloads button, so I would prefer not to put it there).
2) allow moving the button in customize mode **within the navbar only** (like the non-removable buttons from bug 1387313). We'd force it to be visible in customize mode, but it would disappear outside customize mode unless the pref from (1) was flipped or the user had downloads.

Bryan, how does that sound?
Flags: needinfo?(bbell)
(In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #18)
> - move "Downloads" button between Overflow button and Hamburger button in
> Location Bar by default,

adding to this:
maybe creating something like this [Bookmark Toolbar Items] item area in Bookmark Toolbar with ability to move in/out buttons, so it will be:
[Location Bar Items] item with [Downloads][Overflow][Hamburger] buttons.
[Downloads] button should be first I think in the end, as it will be more logical per "showing more...".



(In reply to :Gijs from comment #19)
> (In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see
> your comment/reply/question/etc.) from comment #18)
> > (In reply to :Gijs from comment #14)
> > > If it was possible to move it
> > > elsewhere or for it to be in the overflow menu, we would have to come up
> > > with designs for what happens in those cases (overflow menu, what about if
> > > it's in a toolbar that's hidden, etc. etc.) and then implement them.
> > 
> > This got me another simply idea, as bug #1387313 will landing to Nightly
> > soon:
> > - move "Downloads" button between Overflow button and Hamburger button in
> > Location Bar by default,
> 
> This part is not part of the customizable area. You can't drag/drop
> removable/customizable items here right now. Why this part specifically? Why
> not just leave it in the place it has now in the toolbar?

But it could be customizable area, as was in the past.
There is no single logical reason why to forbid it.
See some more info in above added comment
and see Comment #8 why I would like to move "Downloads" button to Bookmars Toolbar.

(In reply to :Gijs from comment #19)
> > so it will stays there as dimmed non-removable item with this new Photon
> > "Download" button behavior,
> > - if user will move "Bookmarks" button out of this area, to other place in
> > Location Bar or move it elsewhere, to Bookmark Toolbar or Overflow menu, it
> > will be undimmed and will use old always visible "Download" button behavior.
> 
> Do you mean the library? Why would moving bookmarks (which isn't there by
> default anymore) have any influence over the downloads button? To me this
> seems like it would not be discoverable for users (who would just try to
> move the disabled downloads button and fail).

No,
I meant by moving "Downloads" button somewhere else in other non default place
will restore old always visible "Download" button behavior.
(In reply to bbell from comment #5)
> We recognized that The Recent Downloads Menu has very little utility for the

> I am intrigued as to why Alice and yourself have a desire to control where
> this menu appears when a Recent Download is present.

You covered the reason above--the menu has little utility. The position to the right of the URL bar is significant, and I know what is there (and I use that button regularly). This new button appears, and now I can't depend on the consistency of the button I want to use being the button on the right of the URL bar.

Appearing buttons lead to miss-clicks and frustration, especially for frequently used buttons.

If the button is going to appear I want it on a place which won't cause me frustration, so I want to move the Downloads button.
Another solution to this issue is to re-provide ability to move Download button wherever user want without option to hide it completely per dropping out from bar/toolbar/overflow,
with simple preference like "Auto-hide Download button", which will be enabled by default, and users could always disable it, if they want Download button to be always visible.
Hello, 

I have to add my comment/wish to this BUG/CR. I'm very upset about the change in bug 1371765 Is UX Team serious with it? Probably yes :-( I was used to have "Downloads" on my toolbar to have quick (probably fastest) access to my latest downloads. Now "Downloads" are gone and I have to stupidly go to menu Tools -> Downloads, which is slower and not so user friendly. 
And as a "dessert" one funny thing - "Downloads" are not in the toolbar if you open new window on macos, but if you go to menu Tools -> Downloads and new window with downloads is opened, button "Downloads" is automatically added to the toolbar and remains there until browser's window is closed. Then if you open new window again, "Downloads" button is not in toolbar again until you access to "downloads" via menu Tools -> Downloads. First impression of this new "feature" for me was like it is bug and I wanted to report it. It is crazy behaviour in contrast of other buttons in the toolbar. I think nobody would be happy about it.

Please leave users option to have button "Downloads" in the toolbar if they wish. I think customization of "Downloads" button should be the same as for the other buttons like "Library", "Home", "Back", "Reload" and so on.

Generally "Photon" project is great but this change drives me totally crazy. I'm sorry, that I'm so negative, but it is really crazy!!
(In reply to Michal K from comment #25)
> Hello, 
> 
> I have to add my comment/wish to this BUG/CR. I'm very upset about the
> change in bug 1371765 Is UX Team serious with it? Probably yes :-( I was
> used to have "Downloads" on my toolbar to have quick (probably fastest)
> access to my latest downloads. Now "Downloads" are gone and I have to
> stupidly go to menu Tools -> Downloads, which is slower and not so user
> friendly. 
> And as a "dessert" one funny thing - "Downloads" are not in the toolbar if
> you open new window on macos, but if you go to menu Tools -> Downloads and
> new window with downloads is opened, button "Downloads" is automatically
> added to the toolbar and remains there until browser's window is closed.
> Then if you open new window again, "Downloads" button is not in toolbar
> again until you access to "downloads" via menu Tools -> Downloads. First
> impression of this new "feature" for me was like it is bug and I wanted to
> report it. It is crazy behaviour in contrast of other buttons in the
> toolbar. I think nobody would be happy about it.
> 
> Please leave users option to have button "Downloads" in the toolbar if they
> wish. I think customization of "Downloads" button should be the same as for
> the other buttons like "Library", "Home", "Back", "Reload" and so on.
> 
> Generally "Photon" project is great but this change drives me totally crazy.
> I'm sorry, that I'm so negative, but it is really crazy!!

We're really thinking on this one, and are looking for a solution.
To be consistent with the other elements in the Library Menu, which for the most part have a stand alone counterpart that users can add to the toolbar via customization, and because some users find utility in the Downloads Menu as a drag-target, let's expose a Downloads icon in Customization. When the user manually adds a Downloads icon to the toolbar, the application should cancel the default show/hide behavior for that user.
Flags: needinfo?(bbell)
Summary: Reconsider providing back option to show permanently "Downloads" button and make it movable again in this mode → Provide Downloads in Customization that lets the user permanently place a Downloads Menu in their toolbar.
Comment 22
> Appearing buttons lead to miss-clicks and frustration, especially for frequently used buttons.

Shifting buttons (and shifting menu items) are known to increase misclicks. If buttons should appear and disappear, they should not cause any other buttons to shift. On occasion when screens shifted click zones on the third-party software I maintained while working for the local community college it was common to see lots of complaints on the vendor's mailing lists.
Summary: Provide Downloads in Customization that lets the user permanently place a Downloads Menu in their toolbar. → Provide Downloads object in Customization that lets the user permanently place a Downloads Menu in their toolbar.
(In reply to bbell from comment #29)
> To be consistent with the other elements in the Library Menu, which for the
> most part have a stand alone counterpart that users can add to the toolbar
> via customization, and because some users find utility in the Downloads Menu
> as a drag-target, let's expose a Downloads icon in Customization. When the
> user manually adds a Downloads icon to the toolbar, the application should
> cancel the default show/hide behavior for that user.

Thank you very much for reconsidering this and providing the choice for Firefox users! \o/
I only hope, that I could still be able to move this button to Bookmarks Toolbar like before.
Flags: qe-verify+
(In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #31)
> (In reply to bbell from comment #29)
> > To be consistent with the other elements in the Library Menu, which for the
> > most part have a stand alone counterpart that users can add to the toolbar
> > via customization, and because some users find utility in the Downloads Menu
> > as a drag-target, let's expose a Downloads icon in Customization. When the
> > user manually adds a Downloads icon to the toolbar, the application should
> > cancel the default show/hide behavior for that user.
> 
> Thank you very much for reconsidering this and providing the choice for
> Firefox users! \o/
> I only hope, that I could still be able to move this button to Bookmarks
> Toolbar like before.

Will moving the button to Bookmark toolbar be possible soon?
(In reply to hulmelo from comment #33)
> (In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see
> your comment/reply/question/etc.) from comment #31)
> > (In reply to bbell from comment #29)
> > > To be consistent with the other elements in the Library Menu, which for the
> > > most part have a stand alone counterpart that users can add to the toolbar
> > > via customization, and because some users find utility in the Downloads Menu
> > > as a drag-target, let's expose a Downloads icon in Customization. When the
> > > user manually adds a Downloads icon to the toolbar, the application should
> > > cancel the default show/hide behavior for that user.
> > 
> > Thank you very much for reconsidering this and providing the choice for
> > Firefox users! \o/
> > I only hope, that I could still be able to move this button to Bookmarks
> > Toolbar like before.
> 
> Will moving the button to Bookmark toolbar be possible soon?

It's already possible again since yesterday's update.
(In reply to Gurenko Alex from comment #34)
> (In reply to hulmelo from comment #33)
> > (In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see
> > your comment/reply/question/etc.) from comment #31)
> > > (In reply to bbell from comment #29)
> > > > To be consistent with the other elements in the Library Menu, which for the
> > > > most part have a stand alone counterpart that users can add to the toolbar
> > > > via customization, and because some users find utility in the Downloads Menu
> > > > as a drag-target, let's expose a Downloads icon in Customization. When the
> > > > user manually adds a Downloads icon to the toolbar, the application should
> > > > cancel the default show/hide behavior for that user.
> > > 
> > > Thank you very much for reconsidering this and providing the choice for
> > > Firefox users! \o/
> > > I only hope, that I could still be able to move this button to Bookmarks
> > > Toolbar like before.
> > 
> > Will moving the button to Bookmark toolbar be possible soon?
> 
> It's already possible again since yesterday's update.

YEEEEESSSSSS. I'm so so happy, that "Downloads" button is back in today's Nightly. THANK YOU VERY MUCH MOZILLA!! Thank you.
Priority: -- → P3
Whiteboard: [photon-structure] [triage] → [reserve-photon-structure]
I'm going to close this out as WFM given the regressing bug was backed out, and file a new bug to replace bug 1371765 with an updated plan (which will still allow full customization in line with the earlier resolution here). Doesn't seem to make sense to overload this bug given that it was backed out, the number of dupes, people in the CC list, many comments, etc.
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox55: unaffected → ---
status-firefox56: unaffected → ---
status-firefox57: fix-optional → ---
status-firefox-esr52: unaffected → ---
Resolution: --- → WORKSFORME
Priority: P3 → --
Whiteboard: [reserve-photon-structure]
Let's change status to FIXED, per backout in bug #1371765 comment 75 and bug #1371765 comment #76,
as this was major intention of this bug to get back movable and permanently shown "Downloads" button.

So, thank you very much again for reconsidering this! \o/
Status: RESOLVED → VERIFIED
status-firefox55: --- → unaffected
status-firefox56: --- → unaffected
status-firefox57: --- → verified
status-firefox-esr52: --- → unaffected
Resolution: WORKSFORME → FIXED
Summary: Provide Downloads object in Customization that lets the user permanently place a Downloads Menu in their toolbar. → Reconsider providing back option to show permanently "Downloads" button and make it movable again in this mode
Whiteboard: [fixed by patch backout from bug #1371765]
Target Milestone: --- → Firefox 57
Please don't make everything block photon-structure directly. Dependency graphs work. No need to have everything block a single bug.
No longer blocks: photon-structure
You need to log in before you can comment on or make changes to this bug.