I am using node-webkit/nw.js as an automation tool to test my web application.
My application has a record mode to capture all click events and keyboard events.
All the captured events are logged into a file and while in play mode, the logged events are run from clean state.
However, since file uploads open up a File dialog, I cannot emulate a file selection. Since am using node webkit, I can programmatically read a file from the user system and upload it as blob using FormData and Blob . However, based on the file upload, there are events that have to be triggered, and after the upload is complete other fields have to populated say with an image.
Is there a way I can attach a file in the form data programmatically?
I can understand it is not possible in a normal browser since it would be a security issue. In a node webkit environment am anyways able to access and upload user file in the background. So, will it be possible to modify the input file value or by some other means add a blob inside the Form and upload the file?
It seems the steps involved is elaborated in the github page of nw.js but not on docs.
Steps to get reference of form node and input node.
//Detect if button clicked is inside a form.
//In my case all attachments use same component. So I know the no. of levels to move up
if(activeElm.parentNode.parentNode.parentNode.tagName=="FORM"){
//Navigate to input elm and save it as new activeElm.
//Navigation will differ based on your page.
activeElm = activeElm.parentNode.parentNode.parentNode.getElementsByTagName('input')[0];
}
Steps to emulate file attachment.
var f = new File('/path/to/file', 'name');
var files = new FileList();
files.append(f);
elm.files = files;
Related
I have the next input on a webpage
<input accept="image/jpeg" class="class1" type="file">
And I'm trying to set it's file location via chrome console , I've tried to do the next thing
var Files = ['C:/Users/user/Desktop/dir/toUpload/file.jpg'];
var upload=document.getElementsByClassName("class1");
upload.files = Files;
But it seems to have no effect on the page at all.
How can I achieve to upload a file that way? (There is no submit button just file input)
I'm 90% sure that this isn't possible from JavaScript. The browser creates a File object after a user gesture. Allowing the page to create files without user gestures would enable random pages to read local files on user's computers.
File objects are generally retrieved from a FileList object returned as a result of a user selecting files using the element, from a drag and drop operation's DataTransfer object, or from the mozGetAsFile() API on an HTMLCanvasElement. In Gecko, privileged code can create File objects representing any local file without user interaction (see Implementation notes for more information.)
https://developer.mozilla.org/en-US/docs/Web/API/File
My code for uploading a file is this:
var uploadEl = document.getElementById("upload"); // div
page.upload(uploadEl, 'C:/temp/1.JPG');
This actually hangs, so my question is, what is the proper way to upload a file to a dropzone with PhantomJS?
The way a user manually upload a file is like a user clicks the upload div browser opens a native File upload select, the user selects the file and hits the Open button and the website triggers the upload via ajax.
The correct way to upload files in PhantomJS is this:
var page = require('webpage').create();
page.uploadFile('input[name=image]', '/path/to/some/photo.jpg');
It should also work for Dropzone, because uploadFile method behaves as if a user picked a file with a file dialog:
This function is used to automate the upload of a file, which is usually handled with a file dialog in a traditional browser. Since there is no dialog in this headless mode, such an upload mechanism is handled via this special function instead.
Source: http://phantomjs.org/api/webpage/method/upload-file.html
I want to create plugin mechanizm. It is, you can load js file on my website and run your js "plugin" (function) when this plugin is set to run (toggled as running).
All this I want to do without any server.
I mean, I want to keep in localstorage js files or path to this files.
It looks to be hard to do because js can't easy access files path.
I handle file by <input type="file"/>
And I react on onchange event. I get event where I can find selected file by event.srcElement.files[0]
With that I can create URL of that object by : URL.createObjectURL(event.srcElement.files[0])
And I tried to store that URL in localstorage but this URL is temporary.
Also I tried to store whole event or just file (event.srcElement.files[0]).
But I need to create string from that if I want to put it to the function .setItem :
localStorage.setItem("functionURL", JSON.stringify(this.functionURL));
.toString() creates [Object Event/File]
JSON.stringify() creates {} from [Object Event/File]
So, maybe is there a way to somehow remember file which we can use as a function without any server ?
So, maybe is there a way to somehow remember file which we can use as a function without any server ?
Basically, no. :-) Web storage only stores strings. You can't use a string to access a file on the user's local filesystem from your web page, for obvious security reasons.
You could, instead:
Make it possible for them to "upload" the file into your page (without a server) by having them identify the file in an input[type=file], reading its text (via the File API), and then storing that text in local storage
On page load, if local storage has code to run, run it
Offer the user a way to delete or update the code they've uploaded to the page
Since all of that happens in the browser, you don't need a server.
Web storage does have size limits, though they're pretty generous, (around 2.5-5MB) and per-origin, so you have that largely to yourself. But if you run into those limits, you could take it further by caching those files via a service worker, but the complexity goes up markedly. I'd start with web storage and only move on if you really need to support massive files.
#1 (reading the script file the user identifies via an input[type=file]) is really simple on modern browsers:
var file = input.files[0];
var fr = new FileReader();
fr.onload = function() {
// Use `fr.result` here, it's a string containing the text
};
fr.readAsText(file);
I am making a browser based audio player. So for making a playlist from the local directory I am using :
<input type="file" id="getFile" />
Then I am using a button to confirm the playlist.On clicking the button I am calling a javascript function to change the src of the audio tag to play the new audio file selected in the playlist. I want the exact path of the file from the input file to run in the HTML5 audio player but it starts taking the path as C://Fakepath/filename.mp3. Can someone help me with this.
This is a security feature, by design. You should not be able to read the original file path of a file input into a browser form. File input is for reading file contents only, not metadata like path on the user's file system.
The good news is that you don't need the original file path. You can use FileReader's readAsDataURL to convert the file contents into a base64-encoded data URL and use that as the audio src. To read from #myUploadInput and output through #myAudioElement (also available as a working fiddle):
var reader = new FileReader();
reader.onload = function (event) {
document.getElementById("myAudioElement").src = event.target.result;
};
reader.readAsDataURL(document.getElementById("myUploadInput").files[0]);
if the user is 'building' / creating the playlist based on files they have locally you could do a 'browse' field (s) where they select the local audio files, then take the contents of the field (that Should include the paths to those images), build an array of the count/id, filename.mp3, and path... then, based on what is 'chosen' to play, just reassemble the full local path and play that file.
that would be an approach I would take anyway to see if it would work. the necessary piece here is getting the user to disclose the paths to the audio files... but Im still not 100% sure it would work given the security feature that the earlier commenter posted a link to.
if this were included in an application the user approved for local installation you could just refer to it using the 'application directory' and copy the file to that 'safe location' but since its web based it just really opens up a whole can of worms in terms of a potentially unapproved / authorized web function knowing your local directory structure. good luck, let me know if you find a solution.
If a user tries to drag and drop a folder to my file uploader control for uploading it, then I need to show an error message to the user saying that only files can be uploaded. The problem is I couldn't distinguish a file from a folder.
One way I thought was to check for file type property of jQuery. Supposing that the name of the file is "test.txt", then file type would return "text/plain". For a normal folder name such as "TestFolder", file type would be blank and its file size would return 0. However if the folder name included an extension like "TestFolder.txt", then file type would return "text/plain".
So I could have checked for file type and file size but it would not work correctly for folder name like "TestFolder.txt". Could any one suggest me a good solution to fix this using jQuery or other methods?
The ability to determine if a folder has been dropped is dependent on the user agent's support of the Filesystem API. If the user agent DOES support the Filesystem API (currently only Chrome 21+), you can make use of the Entry interface, which has two child interfaces: DirectoryEntry and FileEntry. The interface itself has isDirectory and isFile functions. Without support for this interface, there is no way to determine if dropped items are folders when examining the DataTransfer object.
Since you are not going to allow folder to drag and drop, first check if it's folder or file, second only if it's not folder then check for file extension. But IE < 11 does not support file API to handle. Hope it helps.
As far as I'm aware the browser (And javascript inherently) doesn't have access to any file access methodologies for security purposes so you cannot check what the file actually is.
I have worked with this problem myself in the past and the best option I have found that works is to handle the file server-side, and return the error back to the page after upload has completed.
I would be happy to see better alternatives myself though.