Skip to content
This repository

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

Closed
kwallis opened this Issue July 20, 2012 · 11 comments

3 participants

Ken Wallis RonMen Nukul Bhasin
Ken Wallis
Owner

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.

Nukul Bhasin

@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">
Nukul Bhasin

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?

Nukul Bhasin

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?

Nukul Bhasin

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?

Ken Wallis
Owner
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.

Ken Wallis
Owner

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

Nukul Bhasin nukulb referenced this issue in blackberry-webworks/BB10-WebWorks-Framework August 21, 2012
Closed

Adds support for default picker #137

Nukul Bhasin nukulb referenced this issue from a commit August 21, 2012
Commit has since been removed from the repository and is no longer available.
Nukul Bhasin nukulb referenced this issue from a commit August 21, 2012
Commit has since been removed from the repository and is no longer available.
Nukul Bhasin nukulb referenced this issue from a commit August 27, 2012
Commit has since been removed from the repository and is no longer available.
Nukul Bhasin nukulb referenced this issue from a commit August 27, 2012
Commit has since been removed from the repository and is no longer available.
Nukul Bhasin nukulb referenced this issue from a commit August 28, 2012
Commit has since been removed from the repository and is no longer available.
Nukul Bhasin nukulb referenced this issue from a commit August 28, 2012
Commit has since been removed from the repository and is no longer available.
Nukul Bhasin nukulb referenced this issue from a commit in blackberry-webworks/BB10-WebWorks-Framework August 21, 2012
Nukul Bhasin Adds support for default pickers for file picker and camera. 97a0469
Nukul Bhasin nukulb referenced this issue from a commit in blackberry-webworks/BB10-WebWorks-Framework August 21, 2012
Nukul Bhasin Adds support for default pickers for file picker and camera.
Adds manual tests.

Fixes issue blackberry/BB10-WebWorks-Framework#150
Fixes issue blackberry-webworks/BB10-Webworks-API#27

Reviewed By: Igor Shneur <ishneur@rim.com>
tested By: Igor Sheneur <ishneur@rim.com>
d007dbc
Ken Wallis kwallis closed this September 17, 2012
Nukul Bhasin nukulb referenced this issue from a commit in blackberry-webworks/BB10-WebWorks-Framework August 21, 2012
Nukul Bhasin Adds support for default pickers for file picker and camera.
Adds manual tests.

Fixes issue blackberry/BB10-WebWorks-Framework#150
Fixes issue blackberry-webworks/BB10-Webworks-API#27

Reviewed By: Igor Shneur <ishneur@rim.com>
tested By: Igor Sheneur <ishneur@rim.com>
6b497de
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.