W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: FileReader question about ProgressEvent

From: James Robinson <jamesr@google.com>
Date: Mon, 26 Apr 2010 14:53:12 -0700
Message-ID: <p2oad1a0c1e1004261453sd825c43dob0b24d205821c1bf@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>, japhet@chromium.org
Cc: Jian Li <jianli@chromium.org>, Web Applications Working Group WG <public-webapps@w3.org>
On Tue, Apr 20, 2010 at 4:22 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Tue, Apr 20, 2010 at 3:51 PM, Jian Li <jianli@chromium.org> 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
> 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:

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
Received on Monday, 26 April 2010 21:53:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:07 UTC