848371 - [Meta][Browser] HTTP Downloads through the browser

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::System, defect, P1)

Description

[David Palomino [:dpalomino]]

As a user I would be able to download any kind of content accessible through the Browser to my SD Card.

Many operators (most of them) offer contents to their customers through web portal, so HTTP download is needed for this.

Comment 1

[Rob MacDonald [:robmac]]

I've uploaded a draft spec for feedback:

https://www.dropbox.com/s/aolxy3mzrdfvg17/browser-downloading.pdf

There are a lot of assumptions and open issues I'm hoping we can address. 

UX Assumptions
- Users can only save files that are compatible with the existing Gallery, Video and Music applications (excludes PDFs, flash videos, etc.)
- For video and audio, the file must be self-contained file downloadable via a
hyperlink (as opposed to embedded within the browser window). 
- Browser downloads can be displayed in the utility tray

Open issues
This spec does not currently cover the following: 
- supported file types
- digital rights management
- document management / multiple drives
- handling of incompatible files (TBD)
- error cases (TBD)

Also, a technical question... Are we able to obtain the file size? If so, we likely need to surface this in the UI.

I look forward to everyone's comments/questions/suggestions.

- Rob

Comment 2

[Ben Francis [:benfrancis]]

(In reply to Rob MacDonald [:robmac] from comment #1)
> I've uploaded a draft spec for feedback:
> 
> https://www.dropbox.com/s/aolxy3mzrdfvg17/browser-downloading.pdf

This seems very over-complex for a first iteration of a download manager, we don't even have most of these features on Fennec do we?

I think a good start would be that whenever gecko comes across a MIME type it doesn't know how to render, it triggers some kind of download event which is caught by the system app so that the system app can handle the download, store the file in Device Storage and show the appropriate notifications in the status bar.

Comment 3

[Rob MacDonald [:robmac]]

(In reply to Ben Francis [:benfrancis] PTO until 2nd April from comment #2)
> (In reply to Rob MacDonald [:robmac] from comment #1)
> 
> I think a good start would be that whenever gecko comes across a MIME type
> it doesn't know how to render, it triggers some kind of download event which
> is caught by the system app so that the system app can handle the download,
> store the file in Device Storage and show the appropriate notifications in
> the status bar.

Hi Ben - Can you elaborate on which of the elements are the ones that are considered most complex? Would you be referring mainly to the flows on pages 9-11? With the long tap option on pages 6-8 this is something similar to what happens now when you long tap on an image that appears on its own in a tab.

I also have a few additional questions...

One of the assumptions in comment 1 above is that video and audio that is displayed inline is out of scope for this feature. The assumption was that, if it's not downloadable via tapping on a hyperlink to a compatible file, that there would be no standard way to download it. A long tap or tap, for example, may have different actions with inline playback. Can you confirm that this is the case?

Thanks for your help!

Rob

Comment 4

[Stephany Wilkes]

It looks the spec for this is complete. Ben, can you confirm?

Comment 5

[Ben Francis [:benfrancis]]

There have been some discussions going on about this in a private email thread, I'm going to recommend that discussion be moved to dev-gaia

Also see my questions in bug 853351

Comment 6

[Ben Francis [:benfrancis]]

Please see https://groups.google.com/d/msg/mozilla.dev.gaia/_gxHb_0RjTw/o_z_kEw4X-YJ

Comment 7

[Rob MacDonald [:robmac]]

I had a good conversation with Ben today and here's a quick re-cap. (Ben, please correct me if I've misinterpreted anything!)

- The flows on pages 9 and 10 of the 0.1 spec (https://www.dropbox.com/s/aolxy3mzrdfvg17/browser-downloading.pdf) do not appear to be feasible within the version 1.1 timeframe. As a result, these will likely be deferred. That said, I'd definitely like to raise this for future releases as the natural flow is to view/play the file and then save it. Also, the long tap, whether it be of the link or during playback, suffers from discoverability issues.

- Showing download status in the utility tray (page 11) may be feasible and Ben is looking into this. I will update the wireframes to reflect minor changes in how the download cancellation dialog is displayed.

- We also need to consider how incompatible files are saved. The goal here is to warn users before downloading files that cannot be accessed or deleted. We have flows for this and will add these to the spec as well.

Hopefully this all makes sense!

- Rob

Comment 8

[Ben Francis [:benfrancis]]

(In reply to Rob MacDonald [:robmac] from comment #7)
> - Showing download status in the utility tray (page 11) may be feasible and
> Ben is looking into this. I will update the wireframes to reflect minor
> changes in how the download cancellation dialog is displayed.

My thinking is that we can add a Download item to the context menu on hyperlinks which takes the URL (the same way Open in New Tab does) and fires a download web activity). The system app will then initiate and manage the download itself. This will still have problems with authenticated downloads where the authentication happened in the browser app but the system app won't be authenticated.

> - We also need to consider how incompatible files are saved. The goal here
> is to warn users before downloading files that cannot be accessed or
> deleted. We have flows for this and will add these to the spec as well.

Rob made a very good point about this. It could be possible to download files that you can not open or even delete if there's no app on the device to handle that kind of file.

Comment 9

[Ralph Giles (:rillian)]

(In reply to Ben Francis [:benfrancis] from comment #8)

> Rob made a very good point about this. It could be possible to download
> files that you can not open or even delete if there's no app on the device
> to handle that kind of file.

This is a problem if the files are large and fill up the storage card. However I'd still rather be able to download the file, then go look for an app or copy it somewhere else later, than have to go find the app first. Especially while 3rd-party view webactivities don't seem to be working yet.

I can put unhandled files on the phone with a bluetooth transfer. I can add and remove unhandled files if I plug in the phone and mount it as usb mass storage. What I can't do is download a file from a website when I'm actually mobile. That doesn't feel webby.

Comment 10

[testit]

(In reply to Ben Francis [:benfrancis] from comment #2)
> I think a good start would be that whenever gecko comes across a MIME type
> it doesn't know how to render, it triggers some kind of download event which
> is caught by the system app so that the system app can handle the download,
> store the file in Device Storage and show the appropriate notifications in
> the status bar.

Like for PDF it should be possible for an app to register a "view" webactivity for a specific MIME type. When a download is started for this MIME type, it should be handed over to the registered app.

Comment 11

[Rob MacDonald [:robmac]]

It appears that the link to the specs in Dropbox was broken:

https://www.dropbox.com/s/35ndjqsp4yokxdi/browser-downloading.pdf

Also two additional relevant pattern links:

https://www.dropbox.com/s/vbxes8onsv58ir7/meta-pattern-previews.pdf
- Shows how items are previewed and saved

https://www.dropbox.com/s/6y3urw3g2x7levx/Transfer-Progress.pdf
- Shows download status in utility tray and the flow for unhandled files

Comment 12

[Rob MacDonald [:robmac]]

(In reply to Rob MacDonald [:robmac] from comment #7)
> - The flows on pages 9 and 10 of the 0.1 spec
> (https://www.dropbox.com/s/aolxy3mzrdfvg17/browser-downloading.pdf) do not
> appear to be feasible within the version 1.1 timeframe. As a result, these
> will likely be deferred. That said, I'd definitely like to raise this for
> future releases as the natural flow is to view/play the file and then save
> it. Also, the long tap, whether it be of the link or during playback,
> suffers from discoverability issues.

It seems that the flows on pages 9 and 10 of the spec (updated url 
https://www.dropbox.com/s/35ndjqsp4yokxdi/browser-downloading.pdf) are feasible so please disregard the above comment and flag me if more information is required.

Comment 13

[Stephany Wilkes]

I think UX is complete for this, yes?

Comment 14

[Chris Lee [:clee]]

Can we close this meta given bug 853351 and bug 838042 have both landed?

Comment 15

[Ben Francis [:benfrancis]]

If you're happy to sign off the current implementation then yes Chris. It doesn't match the UX spec but it works.

Comment 16

[Stephany Wilkes]

Chris (and others), there's an issue here. From what I can suss out, it seems like an accidental "left hand didn't know what right hand was doing," with both doing work (on this) with the best of intentions to finish this. That said...

This has not been implemented to spec, I think because the folks who were aware of the spec (in this here bug and in email threads) were not the same folks who actually implemented this, which was Taipei (and Taipei was not aware there was a spec, per all of the conversation and spec links in this bug). 

Let me know how UX can help in deciding what to do here as far as shipping. Ideally we'd have time to do a delta/audit between the spec and what's been implemented with all of the folks who are actually involved, and make a list of work coming out of that, but I'm not sure we have time for that. This is pretty important, though.

Comment 18

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Hi Peter, there's a disparity between implementation and spec at this point in time, could you please take a look to see where we should go from here?

Comment 19

[Peter Dolanjski [:pdol]]

This has been handled in the child bugs.

Comment 20

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

multiple test cases handling downloads.
See moztrap (search for download/firefox os)

example:
https://moztrap.mozilla.org/manage/case/13539/

TEF covered this feature.

Comment 21

[BMO Automation]

Firefox OS is not being worked on