897434 - Save received/downloaded files in one specific folder with meaningful path and filename

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia, defect)

Description

[Dominic Kuo [:dkuo]]

As many apps provide the functionality to save received/downloaded files, to have better UX and not to confuse the users when they are trying to look then copy some saved files from internal/external storages on our devices, we should try to save them in one specific folder(with meaningful path and filename), like "/Downloads" and to let users know all the saved files are in that place.

Below are the current paths that related apps using:
- Email: storage root
- Bluetooth transfer: /downloads/bluetooth (Note this path is defined in gecko)
- Browser: storage root
- MMS: storage root

And what I am imaging are something like:
- Email: /Downloads/Email
- Bluetooth transfer: /Downloads/Bluetooth
- Browser: /Downloads/Browser
- MMS: /Downloads/MMS

I am sure we should have UX people to make the final decision, and since Rob has involved the saving features on media, he should be the best one to judge this.

Comment 1

[Dominic Kuo [:dkuo]]

Rob, can you please comment on this? thanks.

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

How would we handle the localization of this path?

For example, on linux, freedesktop.org defines an xdg-user-dirs specification (http://www.freedesktop.org/wiki/Software/xdg-user-dirs/).  Since locales can change, the initial values are latched to a configuration file (~/.config/user-dirs.dirs) early on in the first login process.

Inside Gecko, nsIDirectoryService exists for indirection purposes since we have to bounce ourselves off the relevant platform mechanisms.  Interesting/relevant files:
http://mxr.mozilla.org/mozilla-central/source/xpcom/io/nsDirectoryServiceDefs.h
http://mxr.mozilla.org/mozilla-central/source/xpcom/io/nsAppDirectoryServiceDefs.h
http://mxr.mozilla.org/mozilla-central/source/xpcom/io/nsDirectoryService.cpp

The set of possibilities for how to expose this would seem to be (all of which should involve latching the path based on the initial locale the user chooses):

- Use the settings API to name a device-storage partition (probably 'sdcard') and path within that partition.  This seems least desirable because adding more dependencies on the settings API is bad.

- Have navigator expose or instances returned by navigator.getDeviceStorage() include some dictionary of juicy information like the name/location of the downloads folder.

- Add an additional device storage just called 'downloads' with the semantics of 'sdcard' plus maybe some additional magic crammed in there that would siphon off attachments based on their mime-type[1].


1: An over-arching but somewhat orthogonal problem is that things get complex if there is no overlap between 'sdcard' and the mime-type specific storage areas.  Arguably, we apps could just text the MIME type and partition based on that, but then there are additional semantics issues that are complex.  I do not want an mp3 of a voicemail sent to me by google voice/similar to end up in my music player.  I don't really want a .png scan of a contract that someone who didn't know how to make PDF's sent me to show up in my gallery.

Comment 3

[Stephany Wilkes]

Reassigning from Rob to Francis as Francis is on Systems Front-End. Francis, please reassign as necessary.

Comment 4

[Stephany Wilkes]

Removing ni? on Francis since this is superseded and addressed by 1.3 work on download manager and settings drawer.

Comment 5

[BMO Automation]

Firefox OS is not being worked on