On Tue, Apr 20, 2010 at 4:22 PM, Jonas Sicking <[email protected]> wrote:
> On Tue, Apr 20, 2010 at 3:51 PM, Jian Li <[email protected]> wrote: > > According to the spec, we will dispatch a progress event for a read > method. > > But per the "Progress Events 1.0" spec, the attributes "loaded" and > "total" > > are defined as "unsigned long". > > interface ProgressEvent : events::Event { > > ... > > readonly attribute unsigned long loaded; > > readonly attribute unsigned long total; > > ... > > The type "unsigned long" is not enough to represent the file size. Do we > > want to update the Progress Event spec to use "unsigned long long"? Or we > > could limit the FileReader to only read from the file with size less than > > MAX_UINT. > > I think the progress events spec needs to be amended here yes. Though > one complication is that ECMAScript can't represent all values of a > unsigned long long. > > Ideally webidl would define an integer type with 53 bits (which iirc > is the largest size you can precisely represent in an ECMAScript > value). > The Blob interface defines 'size' and the 'slice' interface in terms of unsigned long longs: www.w3.org/TR/file-upload/#dfn-Blob It's impossible to generate ECMAScript bindings that satisfy this interface since no ECMAScript types can represent every possible value of type 'unsigned long long' as WebIDL defines it: www.w3.org/TR/WebIDL/#idl-unsigned-long-long. What are we supposed to do? I am thinking that for Chromium the obvious thing to do is to just treat these fields as EMCAScript Number types and be wrong here for values greater than 2^53. - James > > / Jonas > >
