876769 - [Browser] Save media from webpage: Content-Disposition header

Status: RESOLVED FIXED

(Firefox OS Graveyard :: General, defect)

Description

[Noemí Freire (:noemi)]

The requirement is to cover the following scenario when saving media from web pages:
   
Direct links to media files with a Content-Disposition header: 
Content-Disposition: attachment; filename="<file name.ext>"

Comment 1

[Wayne Chang [:wchang]]

Setting [leo-triage] after discussing with partner.

Comment 2

[Ben Francis [:benfrancis]]

I think we need to figure out how we handle downloading files of an unknown MIME type in order to resolve this bug, this was left as TBD in the Browser Downloading UX spec https://www.dropbox.com/s/35ndjqsp4yokxdi/browser-downloading.pdf

In bug 830203 I said that if the user navigates to a file of an unknown MIME type then we should fire a VIEW web activity to give any app the opportunity to view the file. The viewer app could then provide the ability to save it where appropriate.

In the use case described in this bug it's a little more explicit that the file should be downloaded. The problem again is where to save files that are served with this HTTP header but are of an unknown MIME type. Currently we have no download app or file manager app so you could end up saving a file that can neither be viewed or deleted.

I would suggest we build a "Downloads" app which allows the user to view all downloaded files from all the buckets in device storage and can save files of an uknown MIME type to a generic Downloads bucket. We could then fire a web activity when we encounter this header (not sure if that should be VIEW, SHARE or something else) which either the Downloads or System app could consume in order to initiate the download. We may want to use the System app to manage the downloads so we can show the notifications shown the UX spec, and the Downloads app to enumerate downloaded files.

Comment 3

[Wayne Chang [:wchang]]

Triage agrees not blocking for 1.1, track to see what possibilities are and how soon we can have this improved.

Comment 4

[Noemí Freire (:noemi)]

Hi,

Regarding, the current behavior, I’ve tried http://symkat.com/downloads/troll.gif, as an example, and the current result on my Unagi device is that nothing happens, this example is forcing an automatic image download.

As commented in Bug 876376, there would be 2 approaches, over the current implementation that could be considered:
1- implement a generic "Save Link" option which can save any type of file taking into account that there might be files that can not be viewed or deleted(temporary solution till the download or file manager will be ready)
2- go directly to implement a download or file manager

Asking also Leo team for their input/feedback.

Comment 5

[Stephany Wilkes]

Assigning to Francis to track as part of 1.2. Blockers still take UX priority.

Comment 6

[Francis Djabri [:djabber]]

A download manager user story has been added to the System Components agile team backlog.

Comment 7

[Noemí Freire (:noemi)]

Per comment #6 nominating to koi.

Comment 8

[Leo]

As per the discussion on Bug 876376, we prefer to have a Download manager in next version.

Comment 9

[Ben Francis [:benfrancis]]

A download manager is being worked on, but is not listed as a 1.2 must have so I don't think this bug should be koi+ https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AtVT90hlMtdSdEd4TVVjWXNfU3ctMlVhWFRrWkpweVE#gid=12

See related non-blocking bugs:

https://bugzilla.mozilla.org/show_bug.cgi?id=906255
https://bugzilla.mozilla.org/show_bug.cgi?id=906256
https://bugzilla.mozilla.org/show_bug.cgi?id=906257
https://bugzilla.mozilla.org/show_bug.cgi?id=906265
https://bugzilla.mozilla.org/show_bug.cgi?id=906263

Comment 10

[bhavana bajaj [:bajaj]]

(In reply to Ben Francis [:benfrancis] from comment #9)
> A download manager is being worked on, but is not listed as a 1.2 must have
> so I don't think this bug should be koi+
> https://docs.google.com/a/mozilla.com/spreadsheet/
> ccc?key=0AtVT90hlMtdSdEd4TVVjWXNfU3ctMlVhWFRrWkpweVE#gid=12
> 
> See related non-blocking bugs:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=906255
> https://bugzilla.mozilla.org/show_bug.cgi?id=906256
> https://bugzilla.mozilla.org/show_bug.cgi?id=906257
> https://bugzilla.mozilla.org/show_bug.cgi?id=906265
> https://bugzilla.mozilla.org/show_bug.cgi?id=906263

Moving to 1.3 given this.

Comment 11

[Stephany Wilkes]

Bhavana, that's correct: download manager is for 1.3. For any additional questions, feel free to flag Peter Dolanjski, who is PM on that effort.

Comment 12

[Kai-Chih Hu [:khu]]

Is there a user story ID for this?

Comment 13

[Marcelino Veiga Tuimil [:sonmarce]]

As far as I know there is no user story for this bug, but it can be considered as one of the cases covered by bug 929532.

Comment 14

[bhavana bajaj [:bajaj]]

NI on Peter(based on comment 11)  to confirm we need this for bug 929532.

Comment 15

[Peter Dolanjski [:pdol]]

(In reply to bhavana bajaj [:bajaj] from comment #14)
> NI on Peter(based on comment 11)  to confirm we need this for bug 929532.

That's correct.  This blocks bug 929532 as Marce described.

Comment 16

[Jason Smith [:jsmith]]

This is a targeted feature, not a committed feature. So not a blocker.

Comment 17

[Stephany Wilkes]

But does this block a committed feature?

Comment 18

[Jason Smith [:jsmith]]

(In reply to Stephany Wilkes from comment #17)
> But does this block a committed feature?

Not to my understanding. The blocking bugs here are targeted features, not committed features.

Comment 19

[Peter Dolanjski [:pdol]]

Should have been fixed in 1.4 (as per Aus).