Open cookiengineer opened 6 years ago
The issue is not related to window.openFileDialog()
, as it does return an array of File
object as expected.
The problem is that Object.keys([File Object])
return an empty array despite the fact the the filesize
and filename
property are listed as enumerable properties ( See https://github.com/nidium/Nidium/blob/master/src/Binding/JSFile.cpp#L794-L798 and https://github.com/nidium/Nidium/blob/master/src/Binding/ClassMapper.h#L36-L43 )
The documentation for Object.keys
says that :
The Object.keys() method returns an array of a given object's own enumerable properties, in the same order as that provided by a for...in loop (the difference being that a for-in loop enumerates properties in the prototype chain as well).
It turns out that listing the properties with for...in
loop work as expected. My guess is that since the properties are defined on the prototype of the File
object Object.keys
will not return anything defined on the prototype, only instance variable. This behavior seems to be consistent with browsers implementation of File
object and other, so I don't think this is an issue.
Pure JS example :
var Demo = function() { this.foo = "foo"; }
Demo.prototype.bar = "bar"
var d = new Demo();
console.log(Object.keys(d)); // Will only list "foo"
console.log(Object.getOwnPropertyNames(d)); // Will list "foo" and "bar" properties
@paraboul any thoughts ?
When using the
window.openFileDialog()
API, the returned list that the callback receives as a parameter is an empty object with no keys and no values.Both
Object.keys()
andObject.values()
return empty Arrays. When stringifying the entries themselves, they are just empty objects ({}
). I was trying to figure out myself what was going on inside theX11UIInterface.cpp/h
files, but to be honest I have no clue how the memory looks like and how to properly convert/verify the data there.Tested system: Up-to-date archlinux, with GNOME3 stable.