As a WebWorks developer, my <input type="file"> elements will trigger the file picker card

[kwallis]

Acceptance Criteria

• clicking on a element in application content will trigger the file picker system card
• If the tag has the multiple attribute defined, the file picker should be capable of returning multiple files. Otherwise a single file will be returned.
• the files chosen from the file picker should be returned to the input element and can be read by the File API
  • Use case background: using the File API, the developer can retrieve a FileList from the DOM element, and therefore process the files returned from the file picker using the File API. They could also then take these files and pass them on to other applications or cards with invoke, etc. Reference: http://www.w3.org/TR/FileAPI/#dfn-filelist
• The scenario where the card may be dismissed with no file selected should be handled gracefully by returning an empty file list to the input element.

[RonMen]

Right now, using BB10 OS version 10.0.6.386 on the dev alpha, there seem to be an issue choosing one (or even more) file(s) from filesystem with the <input type="file"> since it returns a FileList, but it doesn't return anything about the path the files are selected from. I can only see this in Web Inspector: Event.target.value = "C:\fakepath\IMG_00000003.jpg" when selecting this image (or even every other file). BTW: this also accours on PlayBook and we had a discussion on it in the support forum http://supportforums.blackberry.com/t5/Web-and-WebWorks-Development/How-to-get-path-use-lt-input-type-file-gt/m-p/1840797

The next issue with <input type="file"> is that I'm not able to select more then one file from the opened file picker.

And one more issue to be mentioned, if I choose the "Pictures" element in the file picker it doesn't show any image previews, only the select boxes which are blank/white elements.

[nukulb]

@RonMen -
Event.target.value = "C:\fakepath\IMG_00000003.jpg" that is the correct behavior according to me. Web content should not have access to real path on device.
So to get the selected
var f = evt.target.files[0];
now you have File and you can use the HTML5 file API to manipulate it.
The code below shows reading the file.

        function readSingleFile(evt) {
            var f = evt.target.files[0];

            if (f) {
                var r = new FileReader();
                r.onload = function(e) {
                    var contents = e.target.result;
                    document.getElementById('show').innerHTML = "Got the file.n"
                        +"/n name: " + f.name + "n"
                        +"/n type: " + f.type + "n"
                        +"/n size: " + f.size + " bytesn"
                        + "/n starts with: " + contents.substr(1, contents.indexOf("n"));
                }
                r.readAsText(f);
            } else {
                alert("Failed to load file");
            }
        }

document.getElementById('fileinput').addEventListener('change', readSingleFile, false);

input element is this

 <input id="fileinput" type="file">

[nukulb]

For your other issue, multi-select on a file picker will exposed through other invocation APIs and will be possible

[RonMen]

THX. As I wrote in the forum discussion, it doesn't make any sence to me to not add the filePath to the file object. Right now we are not able to handle eg. fileuploads using the HTML5 FileTransfer (or the corresponding WebWorks extension for PB + BB OS for SmartPhone) since we need to define the localPath as attribute for an upload.

I have already worked with the FileReader object you mentioned, but it doesn't make any sence to only read the content of a file when I wanted to send the whole file, isn't it?

[nukulb]

We have been discussing this issue a little bit in the last couple of days

Have you tried XHR2

http://www.html5rocks.com/en/tutorials/file/xhr2/
Incase you have not tried look at section UPLOADING A FILE OR BLOB: XHR.SEND(BLOB)

[RonMen]

THX. XHR2 isn't new to me. Since FileTransfer is there for PB (WebWorks Community API) or by default in BB10 it seem to be a step backwards when we have a nice FileTransfer API for such use cases but we "need" to work with the XHR2. I know almost all browser vendors, except FF, work in this way with a fakepath.
But since an application may have the permission to access the filesystem and the filepicker only shows files from the accessable filesystem (shared folders) it shouldn't be a security issue, isn't it?

[nukulb]

I don't personally think of this as a step backwards at all. There are two separate use cases.

1. You are either a webworks app
   In the future (not too far) there will be APIs available to invoke the file picker which will return you real paths so you will able to combine that API with the FileUpload API and do it that way.
2. You are either a mobile website and you want to also be an app using webworks
   This issue is essentially is designed to support the HTML file picker which caters to this use case. So you want to keep the same code between the mobile website and WebWorks.

Changing default HTML behaviors specially to fit WebWorks better is never a good idea. These cases should be handled through WebWorks APIs.

@kwallis thoughts?

[kwallis]

I like this train of thought of WebWorks versus re-useable web content. Once we have access to the file picker from a WebWorks API, then I think both scenarios are covered in appropriate fashion.

Ken Wallis

Product Manager – BlackBerry WebWorks

Research In Motion

(905) 629-4746 x14369

---

From: Nukul Bhasin [notifications@github.com]
Sent: Friday, August 10, 2012 9:01 AM
To: blackberry/BB10-WebWorks-Framework
Cc: Ken Wallis
Subject: Re: [BB10-WebWorks-Framework] As a WebWorks developer, my elements will trigger the file picker card (#150)

I don't personally think of this as a step backwards at all. There are two separate use cases.

1. You are either a webworks app
   In the future (not too far) there will be APIs available to invoke the file picker which will return you real paths so you will able to combine that API with the FileUpload API and do it that way.
2. You are either a mobile website and you want to also be an app using webworks
   This issue is essentially is designed to support the HTML file picker which caters to this use case. So you want to keep the same code between the mobile website and WebWorks.

Changing default HTML behaviors specially to fit WebWorks better is never a good idea. These cases should be handled through WebWorks APIs.

@kwallishttps://github.com/kwallis thoughts?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/150#issuecomment-7641323.

---

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

[RonMen]

Ok. I think @nukulb pointed things out quite well and the mentioned HTML behavior changings for only the WebWorker devs wouldn't be a good choice, but on the other hand we don't know what is on your list and what we can expect in the (near) future. I only want to notice missing things on other "stable" mobile OSs since BB10 is on it's way to one of them and we might be able to give you our ideas and thoughts about it. I'm in the process to "decompose" all the APIs and possibilities of the BB10 device in use case I can think of to get the best of all, that's my intention writing the one or other thing here. THX.

[kwallis]

We are very appreciative of all the feedback you are providing here! By all means please continue to post your thoughts here in GitHub, already you have provided valuable insight. Looking forward to seeing what you come up with from a use case perspective; there is still so much for us to do, would be good to get input on what use cases people see as important. If you have something you wish to share that goes beyond a particular issue here in GitHub, please feel free to email me directly at kwallis@rim.com and we can figure out the best way to share it (maybe a GitHub wiki page or something)

[RonMen]

I had a small discussion about the file picker situation with some other devs around and talked about the FileAPI in general. For this scenario of the file picker, wouldn't it be the better choice to return a list of FileEntries since they represent files in the FileSystem? Referring to http://www.w3.org/TR/file-system-api/#the-fileentry-interface I would vote for FileEntry, even if browser vendors (webkit, ff, opera, ie, ...) implement the other way to only return a list of files like here: http://www.w3.org/TR/FileAPI/#dfn-filelist