845403 - Remove support for browser.download.useToolkitUI

Status: RESOLVED DUPLICATE of bug 928349

(Firefox :: Downloads Panel, defect)

Description

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

The Downloads Panel is currently pref-offable, in that we can revert back to the old downloads window.

The old downloads window is not going to be maintained, and doesn't play well with per-window private browsing, so we're going to remove support for it.

Comment 1

[Joshua Smith [:joshua-s]]

I don't think this is a very good idea.  A lot of users still prefer the old downloads window to the panel.  

See:
https://support.mozilla.org/questions/955240
https://support.mozilla.org/questions/955403

We even added a section in our KB article:
https://support.mozilla.org/kb/find-and-manage-downloaded-files#w_how-do-i-revert-to-the-old-downloads-window

Comment 2

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

Hey Joshua,

(In reply to Joshua Smith [:joshua-s] from comment #1)
> I don't think this is a very good idea.  A lot of users still prefer the old
> downloads window to the panel.  

How many is "a lot"?

> 
> See:
> https://support.mozilla.org/questions/955240
> https://support.mozilla.org/questions/955403
> 
> We even added a section in our KB article:
> https://support.mozilla.org/kb/find-and-manage-downloaded-files#w_how-do-i-
> revert-to-the-old-downloads-window

The old toolkit downloads window is deprecated. It is no longer receiving support, and does not work well with per-window private-browsing (I don't believe downloads will appear in the downloads window when created from a private browsing window).

I think we'd need a really, really, _really_ compelling argument (beyond "I like the old one better", "the new one broke my workflow", etc) to keep the old toolkit window around. Such a discussion is best suited for the firefox-dev mailing list rather than this bug.

-Mike

Comment 3

[Marco Bonardo [:mak]]

(In reply to Joshua Smith [:joshua-s] from comment #1)
> I don't think this is a very good idea.  A lot of users still prefer the old
> downloads window to the panel.  

Those people should file bug and enh requests to bring their favorite features to the new downloads experience, there is no plan to improve the old manager code, and thus there is no possibility to keep it alive.
Moreover, I unfortunately noticed many are reverting to the old manager just cause of the change, without actually evaluating it, that makes it even harder for us to improve the new experience.

Yes, as Mike said, we need a very compelling and non subjective argument to keep maintaining the costs for supporting this option.

Comment 4

[Joshua Smith [:joshua-s]]

(In reply to Mike Conley (:mconley) from comment #2)
> Hey Joshua,
> 
> (In reply to Joshua Smith [:joshua-s] from comment #1)
> > I don't think this is a very good idea.  A lot of users still prefer the old
> > downloads window to the panel.  
> 
> How many is "a lot"?

I will post the links to the input on the dev list when bug 854022 lands (the Input upgrade broke the link function).

Comment 5

[Marco Bonardo [:mak]]

I already saw the feedback about this actually (I monitored feedback pretty closesly, not just on input.m.o, also on news sites and forums). I know some vocal (in the sense of advanced users who are reporting back to us) users are reverting back.  Unfortunately we also know this is a pretty common shape when UI changes happen, I can't remember a single UI change we made that didn't have this request.
We can't go back for very contingent resources availability.  We have small resources to improve the new experience, but not enough to maintain old crappy code until everyone is 100% happy.  So please, ask users to file bugs requesting changes to the new downloads experience that will make them happy, we will try to do our best to follow (and where possible satisfy) those requests.

Comment 6

[Joshua Smith [:joshua-s]]

Ok, thanks :)

I also want to say that you have done a great job on the panel, and I love it, just concerned about the feedback.

Comment 7

[Marco Bonardo [:mak]]

It's good to be concerned, please keep up informed of any major topics that rise.

Comment 8

[:Paolo Amadini]

Now that the new JavaScript API for downloads is available, we will remove support for the now incompatible useToolkitUI preference as part of the work in bug 928349.

Comment 9

[Patrick Storz]

*sad*

see bug 948964

Comment 10

[BSaito]

Marco, what would it take to convince you that a UI change is bad and the old functionality is better?  If you dismiss feedback regarding UI changes you'll miss it when you actually do worsen the user experience.  Negative feedback being common means you're doing something wrong.  End users do not like when you disrupt they way they are used to using their browser; which means such changes should be made carefully, sparingly, and with a careful and responsive eye on user feedback.  Monitoring feedback means nothing if you don't actually listen to it.

I'd imagine that most of the users who are complaining about the change, myself included, have not encountered the issue with per-window private browsing.  From our perspective you've taken a perfectly good feature away from us and replaced it with ****.  How would you feel if you were reading a good book and I snatched it away and replaced it with a copy of Twilight?  What if I refused to give you your book back and insisted you should instead read Twilight and tell me how it could be improved?

Comment 11

[Marco Bonardo [:mak]]

(In reply to BSaito from comment #10)
> If you dismiss feedback regarding UI changes
> you'll miss it when you actually do worsen the user experience.  Negative
> feedback being common means you're doing something wrong.

we got a lot of positive feedback and some negative. That's fine and expected, we try to gather suggestions from both. We already did some changes, others will come.

> Monitoring feedback means nothing if
> you don't actually listen to it.

I think that also listening (and as such implementing) all of the feedbacks would have negative effects in creating an undriven project. The right compromise is needed, that also means sometimes the feedback may go the opposite direction of the product, it's unavoidable an up to us to do our best to interpret that.