Issue metadata
Sign in to add a comment
|
Errors when processing files dropped onto page with file:// URL |
||||||||||||||||||||||||
Issue descriptionVersion: 52.0.2743.116 (Official Build) (64-bit) OS: Linux What steps will reproduce the problem? (1) git clone https://github.com/Spiritdude/OpenJSCAD.org.git (2) Open index.html from the root directory. (3) Drag and drop examples/benchmark_cag.jscad onto the white drop area in the lower left. ("Drop one or more supported files here ...") What is the expected output? The web app loads the file. What do you see instead? There's an error on the console logging a DOMException EncodingError. If you poke in the debugger you'll see the drop event handler (conveniently right above the error callback) doing item.file(...); that callback is failing. I poked at this in the debugger a bit, and it seems browser is telling webfilesystem this failed with base::File::FILE_ERROR_INVALID_URL. I didn't spelunk back through browser. Is drag and drop blocked for file:///? The resulting error in pages--encoding error--is pretty mysterious. Also reported on Chrome 51.0.2704.106 (64-bit) here: https://github.com/Spiritdude/OpenJSCAD.org/wiki/Release-0.5.1-PC-Browser-Testing
,
Aug 19 2016
I don't think we do anything explicit in DnD to break dragging local files to local files. Does it work if the web app is hosted somewhere?
,
Aug 19 2016
Yes, if you serve the root of the git repo and open /index.html with HTTP, drag and drop works. Also --allow-file-access-from-files and it works. If this isn't by design, maybe it is some colateral damage.
,
Aug 19 2016
There is a check in FileAPIMessageFilter::ValidateFileSystemURL() which calls FileSystemURLIsValid(), which returns false because |url| is not valid because OnCreateSnapshotFile is being called with an empty |url|. My guess is this is for security purposes, which is why --allow-file-access-from-files fixes this issue. cc'ing kinuko@ for her thoughts.
,
Aug 29 2016
Re: "Can we improve the error message?" - there's also issue 608060 where we let a "this filesystem URL doesn't make sense" error bubble out to script as an EncodingError when we should really have a better error name/message, e.g. InvalidAccessError
,
Sep 6 2016
The full error provided to the handler looks like...
FileError {
code:5
message: "A URI supplied to the API was malformed, or the resulting Data URL has exceeded the URL length limitations for Data URLs."
name: "EncodingError"
}
It is intentional to deny access to files from file:/// urls. Of the errors defined in FileError.cpp, kSecurityErr is probably the most appropriate.
,
Sep 7 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 18 2017
,
Sep 19
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 20
Updating title
,
Sep 27
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by dominicc@chromium.org
, Aug 19 2016