Hi All - the publication of the File API LC was delayed because of some
logistical issues for Arun as well as some additional edits he intends to make.
This delay also resulted in Eric's two File * specs not being published since
they have a dependency on the latest File API spec.
Arun - can
2012/3/29 Bronislav Klučka bronislav.klu...@bauglir.com
If I understand you, you find it problematic that by using weak ref, URL
would for some time reference actual Blob and other time it would not?
The problem is that the following code might or might not work, depending
on the behavior of
On 30.3.2012 15:21, Glenn Maynard wrote:
2012/3/29 Bronislav Klučka bronislav.klu...@bauglir.com
mailto:bronislav.klu...@bauglir.com
If I understand you, you find it problematic that by using weak
ref, URL would for some time reference actual Blob and other time
it would not?
On Fri, Mar 30, 2012 at 5:39 AM, Arthur Barstow art.bars...@nokia.com wrote:
Hi All - the publication of the File API LC was delayed because of some
logistical issues for Arun as well as some additional edits he intends to
make.
This delay also resulted in Eric's two File * specs not being
On 02/15/2012 10:09 AM, Vincent Scheib wrote:
Mounir, I ran into the same confusion regarding how does the API expose
locking?. May I suggest that you explicitly state in the abstract that
the API is pending?
I just updated the draft so the locking part is now part of it.
Cheers,
--
Mounir
Great!
Am 30.03.12 11:28 schrieb Mounir Lamouri unter mou...@lamouri.fr:
On 02/15/2012 10:09 AM, Vincent Scheib wrote:
Mounir, I ran into the same confusion regarding how does the API expose
locking?. May I suggest that you explicitly state in the abstract that
the API is pending?
I just
2012/3/30 Bronislav Klučka bronislav.klu...@bauglir.com
url = createObjectURL(blob);
blob = null;
setTimeout(function() { img.src = url; }, 0);
That should not be problematic; yes, GC may actually free that blob
allocated memory later than that timeout function triggers, but there is
As far as I can tell, the WebIDL specification doesn't define anything
about what really happens when a constructor is invoked, once the
arguments have been converted to the IDL types, except the conversion of
the return value from an IDL type to an ES type. It defers the exact
behavior of
See the [[Scope]] internal property of function objects from ECMA-262
13.2, 10.4.3, etc.
/be
Boris Zbarsky wrote:
As far as I can tell, the WebIDL specification doesn't define anything
about what really happens when a constructor is invoked, once the
arguments have been converted to the IDL
On 3/30/12 9:22 PM, Brendan Eich wrote:
See the [[Scope]] internal property of function objects from ECMA-262
13.2, 10.4.3, etc.
Nothing in WebIDL or XHR says to use [[Scope]]. If it did, that would
constitute a definition of the behavior, yes.
-Boris
10 matches
Mail list logo