Closed Bug 796384 Opened 10 years ago Closed 10 years ago

[system] Upload a file

Categories

(Firefox OS Graveyard :: Gaia, defect)

defect
Not set
normal

Tracking

(blocking-basecamp:-)

RESOLVED DUPLICATE of bug 801635
blocking-basecamp -

People

(Reporter: ghtobz, Unassigned)

Details

(Whiteboard: [label:story][label:system])

[GitHub issue by nhirata on 2012-07-10T23:22:29Z, https://github.com/mozilla-b2g/gaia/issues/2312]
As a user I want to upload a photo to Facebook from my device.

Originally filed as a bug, as below...

## Environment
* Otoro phone, build 2012-07-10
* Gaia commit: d0fc2f0cdbec7bd94d6bd3fd782803b8787f8040

## Repro
1. launch browser webapp
2. go to http://people.mozilla.com/~nhirata/html_tp/bug725953.html
3. click on the browse button

## Expected:
* browse the directory structure or launch an app that will browse the file structure

## Actual:
* nothing occurs

## Note: logcat:

07-10 23:17:54.969: I/IdleService(121): Reset idle timeout: tell observer 66ea18 user is back
07-10 23:17:55.149: I/Gecko(383): unable to open file picker
07-10 23:17:55.149: I/Gecko(383): [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMJSWindow.openDialog]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: jar:file:///system/b2g/omni.ja!/components/nsFilePicker.js :: <TOP_LEVEL> :: line 229"  data: no]
07-10 23:17:55.149: E/GeckoConsole(383): [JavaScript Error: "this.mFilesEnumerator is undefined" {file: "jar:file:///system/b2g/omni.ja!/components/nsFilePicker.js" line: 92}]
07-10 23:17:55.159: E/GeckoConsole(121): [JavaScript Error: "this.mFilesEnumerator is undefined" {file: "jar:file:///system/b2g/omni.ja!/components/nsFilePicker.js" line: 92}]
07-10 23:17:55.979: I/IdleService(121): Get idle time: time since reset 836 msec

User Story: 
1. uploading a picture to facebook from gallery
[GitHub comment by nhirata on 2012-07-10T23:49:25Z]
see related bug: https://github.com/mozilla-b2g/gaia/issues/2319
[GitHub comment by benfrancis on 2012-07-11T16:12:24Z]
Am I right in saying that we don't plan to support either file uploads or downloads for the v1 browser app @cleemoz ?

Previously it wasn't clear where you would even upload and download *to*, but I think now you could probably argue for using the Media Storage API for this?
[GitHub comment by cleemoz on 2012-07-12T01:03:21Z]
Uploading/download from the browser is not planned for v1.  Being able to upload a photo from a web app (i.e. Facebook) should be doable and managed within the app.  Do we need the first to be able to do the latter here?
[GitHub comment by benfrancis on 2012-07-13T14:42:07Z]
On Thu, Jul 12, 2012 at 2:03 AM, cleemoz <
reply@reply.github.com
> wrote:

> Uploading/download from the browser is not planned for v1.  Being able to
> upload a photo from a web app (i.e. Facebook) should be doable and managed
> within the app.  Do we need the first to be able to do the latter here?


Yes, Facebook (and any other app) will have the same problem. The issue is
that the file picker would usually pick a file from the filesystem but web
apps and web content can't access the file system. On Android when you try
to pick a file to upload like this it raises a kind of intent UI which lets
you pick which app to upload a file from. We don't have that.
[GitHub comment by benfrancis on 2012-09-14T14:35:15Z]
de-tagging as browser, tagging as system, converting to story instead of bug and nominating for basecamp.

This seems like a pretty important feature if we don't already have it, and needs to somehow interact with activities and/or device storage.

@cleemoz you say this isn't a requirement for the browser, so is it OK for the browser to simply do nothing when a file picker browse button is clicked?
[GitHub comment by autonome on 2012-09-14T16:12:30Z]
Not going to be a common use-case for V1. We have activities and FB integration for this specific sharing in this release, so not blocking.
[GitHub comment by autonome on 2012-09-14T16:12:54Z]
@benfrancis I think it's ok for input type=file to do nothing for V1.
[GitHub comment by cleemoz on 2012-09-15T02:16:58Z]
Yes, functionally this is not a v1.  @jcarpenter @lco to comment on the UX for this.
[GitHub comment by lco on 2012-09-28T18:20:50Z]
I think it's fine for it to do nothing, but we need to somehow inform the user so that they don't think the system is unresponsive. This may be the case for many sites that request uploads. Maybe a simple banner notification that says "Sorry, file uploading not available." or something like that
[GitHub comment by benfrancis on 2012-09-28T18:35:34Z]
Unfortunately that would require a new platform feature (to even know a file element had been clicked), so is unlikely to make it into v1 now :(
[GitHub comment by cleemoz on 2012-09-28T18:39:19Z]
Not a v1 blocker.
What rules does the migration script use to move issues from Github to Bugzilla? This is a v2 feature, not a v1 blocking bug. Are we now moving everything over or is it because this issue was missing a magic flag?
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 801635
You need to log in before you can comment on or make changes to this bug.