1206334 - Allow "Saved Files" in a standalone window (like before, and *not* like FF)

Status: RESOLVED WONTFIX

(Thunderbird :: General, enhancement)

Description

[jwq]

Bug 1087233 appears to have done two things: (1) migrate download management and (2) replace the "Saved Files" dialog with a tab. I'm fine with (1) but not (2).

 Bug 724262, marked as a duplicate of Bug 1087233, requested the enhancement of being able to display either a dialog or a tab at the user's option. I'm fine with that.

 I'd like "Saved Files" as a dialog to be restored because a tab just doesn't work for me.

 Depending on which way you want to look at this, it's either a regression caused by Bug 1087233 or a RFE. But I would like to see the dialog restored. I note that not even FF shows downloads in a tab (at least not by default) so TB is anomalous in its behaviour.

Comment 1

[Thomas D. (:thomas8)]

(In reply to jwq from comment #0)
>  I'd like "Saved Files" as a dialog to be restored because a tab just
> doesn't work for me.

Would you please spell out WHY it does not work for you, like providing detailed workflow examples which are now broken?

Do you know Ctrl+J shortcut to show saved files tab?

> I note that not even FF shows downloads in a tab (at least not by default)
> so TB is anomalous in its behaviour.

I'd agree that the FF behaviour is much superior, with visual animation showing where downloads have gone, and thus making them easily accessible from primary UI, via intuitive popup when downloads button is clicked. I'd wish the same or something similar for TB. Pls note that the full downloads list DOES live in a tab even for FF.

Comment 2

[:aceman]

For me, the full downloads list (as clicking on the downloads icon and clicking "show all downloads" does open in a separate window. Also from the menu Tools->Downloads.

Yes, if you type about:downloads in location bar, downloads show in a tab. But that seems to be some unofficial not yet exposed way.

Paenglab, do you know why this is? Has TB enabled functionality before Firefox got there? :)

Comment 3

[jwq]

Thomas D.: I'm unsure what purpose would be served by fulfilling your request. Suffice it to say: the saved files dialog allowed simultaneous viewing of an email and the saved files list, nobody asked for the dialog to be removed and I am asking for the dialog to be restored, please.

Comment 4

[Richard Marti (:Paenglab)]

When you are in FX's private browsing mode, then CTRL+J or clicking the button opens the list in a tab. The TB styles are a copy from this tab.

Comment 5

[:aceman]

But why does Firefox not also use a tab also in normal mode? Is the plan to move to a tab also there? Or why is TB farther with the migration? Was converting to the new downloads backend easier in the tab, than copying the Firefox window (a common window for bookmarks and downloads, that TB does not have yet)?

Comment 6

[Richard Marti (:Paenglab)]

I don't know what FX is planning here.

I also don't know why it's made in a tab, maybe because it was easier to copy the code from FX. Hiro wrote in bug 1087233 it was a copy from browser/components/downloads/.

Comment 7

[Thomas D. (:thomas8)]

I don't believe this - we're moving important functionality (attachment downloads manager) from a window into a tab, and nobody ever lost a single word about if the resulting UX is desirable or not? Is there any UX leadership in TB?

Comment 8

[Thomas D. (:thomas8)]

(In reply to jwq from comment #3)
> Thomas D.: I'm unsure what purpose would be served by fulfilling your
> request. Suffice it to say: the saved files dialog allowed simultaneous
> viewing of an email and the saved files list, nobody asked for the dialog to
> be removed and I am asking for the dialog to be restored, please.

Why is it an advantage to view an email and the saved files list simultaneously? Any other advantages of having saved files in their own window? Any advantages of having them in a tab?

jwq, the obvious purpose of my request is
a) to understand why you want what you want, and why we should invest working hours into this
b) to make this RFE comply with basic needs of QA management / UX development (and from experience, I can add that bugs which don't follow the standards have very little chance of getting implemented unless it's crystal clear to everyone)

It was wrong to move this into a tab without any reflection about the resulting UX that I'm aware of.
It is just as wrong to simply request restoration of the old UX without reflecting the respective UX.
If you can't tell why Saved Files in a window is better for your scenarios/workflows, why should we do it? Feelings are appreciated, but we need some substance, too.

Another next step here is to ask developers how hard it would be to implement a pref and "restore" the old UI which allows displaying this in its own window.

Comment 9

[:aceman]

Maybe because they needed to migrate to JS downloads backend quickly. Copying the full Firefox window (Library) would be probably hard and slow (as TB does not have the bookmarks (maybe history too), that the Library window contains/expects).

I complained when FF removed the old downloads window and only has the current bubble now. The new way did not support one of my usecases. I am not sure it works now with the new Library window. Does happen.

So if it was a question of having a downloads tab or none, the answer was clear. Now, if you have the time and skills to reimplement some window for downloads, maybe it will get accepted. It was not said here that everything in tabs is the only future way and nothing else goes. Even Firefox does not follow that yet.

Comment 10

[jwq]

 An email provides indispensable context (sender, subject, date, descriptions in the message body) to any files enclosed with it, which is not typically the case for a file made available from a web page. FF's UI is inappropriate to TB (hence the change in summary).

 It would be appropriate, and more productive, for someone who knows to comment with what is required in practical terms to restore a windowed UI for the Save Files information.

Comment 11

[Richard Marti (:Paenglab)]

Removed the regression keyword as this is no regression because the download list works but is on a different place. And it is still not explained why it is needed to show the list in a window and not in a tab.

Comment 12

[jwq]

Richard Marti: I've already explained, see Comment 3 and Comment 10. Could you please comment with what is required in practical terms to restore a windowed UI for the Save Files information?

Comment 13

[Richard Marti (:Paenglab)]

I'm not experienced enough to say what is needed.

Comment 14

[Wayne Mery (:wsmwk)]

Firstly, I really suspect that VERY few users utilize the download panel/window/tab. To that point, using SUMO advanced search I do not find a single posting since June 1 about this change in version 38, nor anything about "saved files" in *any* context.  Given that, at this time I do not think it is worth anyone's time to implement this request.


(In reply to Richard Marti (:Paenglab) from comment #11)
> Removed the regression keyword as this is no regression because the download
> list works but is on a different place. And it is still not explained why it
> is needed to show the list in a window and not in a tab.

This goes to the earlier question to jwq about workflow.  (WRT comment 12, IMO Comment 10 does not address this question, comment 3 a little bit.)  So *not as a matter of preference* nor what's "nice to have", but as a matter of function does a tab make workflow harder than a separate download dialog window?  And how precisely was this done with standalone download window, with an example business case with numbered steps _and_ how frequently per day do you use this?   

Lastly, I stumbled upon a workaround - open a new (second) 3 pane window and the Saved Files tab - you now effectively have a separate window with just the download dialog

Comment 15

[:aceman]

Yes. Of course nobody questions that the new Downloads tab has LESS functions that the old window. That is being solved e.g. in Bug 1152743 and bug 1152736.

But if the issue here is just the form of the panel, we'd need more information on the use case. Maybe it will be found out there is some function missing that can't be done in the tab.

Comment 16

[:aceman]

(In reply to jwq from comment #3)
> Suffice it to say: the saved files dialog allowed simultaneous
> viewing of an email and the saved files list,
Yes, this can't be done with a tab. But why is it needed? The same files are there in the email so you can open them directly. Are the attachments no longer there (were detached)?

(In reply to jwq from comment #10)
>  An email provides indispensable context (sender, subject, date,
> descriptions in the message body) to any files enclosed with it, which is
> not typically the case for a file made available from a web page.
So if you need the context (the email), you have it there, with the attachment. What does the Saved files dialog add? I see only name there, not even which email it was saved from (maybe we should add that). So what is valuable in the combination of Saved files window and the email beneath?

Comment 17

[Thomas D. (:thomas8)]

(In reply to jwq from comment #10)
>  An email provides indispensable context (sender, subject, date,
> descriptions in the message body) to any files enclosed with it, which is
> not typically the case for a file made available from a web page.

If you want to keep all the email context but still outsource the attachments into your file system, have you tried using "Detach" from attachment context menu? After detaching, you can click on the attachment in the email but it will be opened from the location in your file system where you saved it to, provided path and file name have not been changed.

Having download window on top of email list will not necessarily help to safely identify to which message the downloaded attachment belongs; the same attachment file name might have been used in multiple messages. Instead, more of such message context could/should be provided with the download manager items. We already have an RFE for including sender information with download manager items (bug 1152741). Perhaps subject could somehow be added, too (in a de-emphasized or collapsed-by-default way). Backlink to the original msg might be too tricky/unstable although it would be interesting to explore that. All of this should be explored in a new bug.

> FF's UI is
> inappropriate to TB (hence the change in summary).

Well, you're requesting standalone download manager which is still part of FF.
I'd actually love having exactly the same UX as in FF, with button popup panel from download button in primary UI for the most recent downloads, and the full list somewhere as a tab (or perhaps stand-alone if we find out why that's good in this bug).

>  It would be appropriate, and more productive, for someone who knows to
> comment with what is required in practical terms to restore a windowed UI
> for the Save Files information.

It would be appropriate, and more productive, if you would just try to answer everyone's questions instead of insisting that we should just do your will without understanding why that's useful. Comment 10 is a start, but it's not sufficient as Aceman pointed out.

Comment 18

[Thomas D. (:thomas8)]

(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #14)
> Firstly, I really suspect that VERY few users utilize the download
> panel/window/tab. To that point, using SUMO advanced search I do not find a
> single posting since June 1 about this change in version 38, nor anything
> about "saved files" in *any* context.  Given that, at this time I do not
> think it is worth anyone's time to implement this request.

Wayne has said this before, and I still disagree.
An important point to consider is that many user might not even know there's something like a download manager in TB, because we never show it by default and a lot of workflows around "Saved Files" are still broken, and we DO have a number of bugs for that (and I have commented here and there describing what's wrong, but needs some more work for systematic roundup in dedicated bugs).

I think that receiving and saving file attachments is a frequent usecase, and download manager is definitely the most efficient way of accessing the downloaded files in their saved location for further actions like renaming, editing, sequential viewing etc.

Comment 19

[jwq]

 The small amount of technical discussion has reminded me why I don't use the attachment pane to access the attachments, wherever the attachments might be (yes, I commonly detach attachments). The reason is that the attachment pane UI is dysfunctional: there is no "Open containing folder" contextual menu item for detached attachments (this is very important to me); attachment names in the pane are frequently abbreviated to the point that it is very difficult to distinguish attachments (single attachment names are *always* abbreviated for some weird reason; the css hack on the MozillaZine kb no longer works); there is no indicator in the attachment pane of whether or not the attachment has been saved or detached, nor display of a path to saved/detached attachments; and the path to detached files breaks when the file is moved - which I do all the time (Bug 681790).

 Worst of all, I noted today that detaching attachments from some emails caused TB 38 to fail to show the attachment pane altogether for certain messages! That bug needs to be filed if it hasn't been already reported.

 In Bug 370792 Comment 5 I suggested a list view for the attachment pane, complete with screenshot, which would address some of the deficiencies above. I realise that the only reason I use the Saved Files window is because the attachment pane doesn't have "Open containing folder" and a list view. IMHO much of the Saved Files functionality could be incorporated into the attachment pane to great benefit. That may (or may not) be a technically easier task than placing the Saved Files list in a stand-alone window.

 That said, may I now respectfully request that you all [with the possible exception of Paenglab] please read the Bugzilla etiquette page <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html>, particularly point 1.1 regarding commenting, which begins "Unless you have something constructive and helpful to say, do not add a comment to a bug."

 I don't regard comments opposing a perfectly reasonable request as constructive or helpful. Similarly for the repetition of demands for an extremely high level of justification for what is a request to restore a UI feature.

 For a number of years, Mozilla policy has been that Bugzilla is only to be used for technical discussion. Thus unless you have something technical to contribute, or a patch :-), please refrain from commenting.

Comment 20

[:aceman]

(In reply to jwq from comment #19)
>  The small amount of technical discussion has reminded me why I don't use
> the attachment pane to access the attachments, wherever the attachments
> might be (yes, I commonly detach attachments). The reason is that the
> attachment pane UI is dysfunctional: there is no "Open containing folder"
> contextual menu item for detached attachments (this is very important to
> me);
Please file a bug.

> attachment names in the pane are frequently abbreviated to the point
> that it is very difficult to distinguish attachments (single attachment
> names are *always* abbreviated for some weird reason
I can't see this, even a 60characters long file name displays completely in the attachment pane (bellow the message). If you really see this, please file a bug and attach a screenshot.

> there is no indicator in the attachment
> pane of whether or not the attachment has been saved or detached, nor
> display of a path to saved/detached attachments;
This seems reasonable and doable, please file the bug.

>  I don't regard comments opposing a perfectly reasonable request as
> constructive or helpful. Similarly for the repetition of demands for an
> extremely high level of justification for what is a request to restore a UI
> feature.
A request without a clear justification is not reasonable. Requests to restore UI to previous state "just because I think so" are usually handled in a specific way. We also did not change the UI "just because somebody thought so", as we already explained the technical reasons.

>  For a number of years, Mozilla policy has been that Bugzilla is only to be
> used for technical discussion. Thus unless you have something technical to
> contribute, or a patch :-), please refrain from commenting.
Sure, patches welcome :)

Comment 21

[Kent James (:rkent)]

(In reply to jwq from comment #19)
>  That said, may I now respectfully request that you all [with the possible
> exception of Paenglab] please read the Bugzilla etiquette page
> <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html>, particularly
> point 1.1 regarding commenting, which begins "Unless you have something
> constructive and helpful to say, do not add a comment to a bug."
> 
>  I don't regard comments opposing a perfectly reasonable request as
> constructive or helpful. Similarly for the repetition of demands for an
> extremely high level of justification for what is a request to restore a UI
> feature.

Sorry jwq, but discussions within a bug such as this are exactly the right place to oppose a particular approach, or to ask for justification of the need for a patch. It is particularly important to give that freedom to someone like aceman, who is one of the most likely people to actually take on the bug to fix it, if you can convince him of the reasonableness and justification of the bug.

Comment 22

[jwq]

I'm not prepared to spend my time arguing. I'm particularly not prepared to argue on bugzilla, which is the wrong thing to no matter who you are. No double-standards.

-> WONTFIX per negative comments above and Bug .