Re: [XHR] Event processing during synchronous request
On 09/09/2012 06:33 PM, Mike Wilson wrote: Is it defined how the browser should behave wrt calling unrelated event handlers in user code during synchronous XHR requests? (with "unrelated" I refer to events that are not related to the ongoing synchronous request itself) I didn't find statements directly addressing this in http://www.w3.org/TR/XMLHttpRequest/ or http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resourc es.html but maybe there are indirect relationships between specification sections that I am missing? Or maybe it's deliberately undefined? I ask because Firefox behaves differently to the other popular browsers, in that it triggers event handlers for other asynchronous XHR requests while blocking for a synchronous XHR request. That is a well-known bug in Gecko (other engines have or have had different kinds of bug related to sync XHR, like locks etc). But since synchronous XHR in UI-thread is by all means effectively deprecated and very bad for the ux, I wouldn't expect the bug in Gecko to be fixed any time soon (at least not by me :) ). -Olli Thanks Mike Wilson
Re: [FileAPI] Blob constructor should probably take a sequence, not an IDL array object
On 9/9/12 12:13 PM, Glenn Maynard wrote:
In particular, a Blob represents immutable binary data. That means
that it has to copy the input anyway. Given that, it doesn't make
sense to pass the input by reference if the caller _does_ happen to
have an WebIDL array object.
That doesn't mean it copies the array itself, though.
That's true, but in most cases (certainly the ones where a JavaScript
array will be passed in) that would happen anyway.
(Though both ways, this seems like an implementation detail
It's not quite.
I'd expect a mature binding system to let you annotate implementations to say
things like "make a copy for me instead of passing it in by reference"
and "don't make a copy even though WebIDL requires it, because we
fulfill that requirement as a side-effect".)
Those are both incredibly fragile. Consider some other random spec that
has IDL like this.
interface Foo {
// Returns the argument passed to the constructor
(ArrayBuffer or ArrayBufferView or Blob or DOMString)[]
getInitData();
};
Blob implements Foo;
Now suddenly your annotation is a bug.
So in practice binding systems aren't particularly likely to implement
such annotations because of the increased fragility they introduce. The
whole point of having IDL for bindings is to _reduce_ fragility
The upshot is that there are practical drawbacks (slowing down the
common use case, as far as I can tell) and at best theoretical benefits
(since nothing actually _produces_ platform arrays of the above union!).
By the way, note that if something produces a DOMString[] and you pass
_that_ to a blob constructor as currently defined, then what will happen
per spec is that the input will be converted to a sequence
and then a new platform array object will be created and the sequence
copied into it. So you'll still get passing by value, not by reference.
The only way to get passing by reference is if you're given a T[]
where T exactly matches your array element type.
Basically, platform arrays are only useful if you both produce and
consume them in the same interface, as far as I can tell...
-Boris
[XHR] Event processing during synchronous request
Is it defined how the browser should behave wrt calling unrelated event handlers in user code during synchronous XHR requests? (with "unrelated" I refer to events that are not related to the ongoing synchronous request itself) I didn't find statements directly addressing this in http://www.w3.org/TR/XMLHttpRequest/ or http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resourc es.html but maybe there are indirect relationships between specification sections that I am missing? Or maybe it's deliberately undefined? I ask because Firefox behaves differently to the other popular browsers, in that it triggers event handlers for other asynchronous XHR requests while blocking for a synchronous XHR request. Thanks Mike Wilson
Re: [FileAPI] Blob constructor should probably take a sequence, not an IDL array object
On Sun, Sep 9, 2012 at 9:34 AM, Boris Zbarsky wrote: > In particular, a Blob represents immutable binary data. That means that > it has to copy the input anyway. Given that, it doesn't make sense to pass > the input by reference if the caller _does_ happen to have an WebIDL array > object. > That doesn't mean it copies the array itself, though. Unless your internal Blob representation is the same as the array you receive from your Blob ctor binding, you're going to end up making another copy anyway. (For example, you may be storing the underlying representations of the data rather than the JavaScript Blob objects themselves.) I'd also expect implementations to want to flatten other Blobs, so they don't need to be recursive. If you're passed [blob1, blob2], and blob1 itself is actually [blobA, blobB], you'd be storing [blobA, blobB, blob2], so there's no point in copying [blob1, blob2]. (Though both ways, this seems like an implementation detail. I'd expect a mature binding system to let you annotate implementations to say things like "make a copy for me instead of passing it in by reference" and "don't make a copy even though WebIDL requires it, because we fulfill that requirement as a side-effect".) -- Glenn Maynard
[FileAPI] Blob constructor should probably take a sequence, not an IDL array object
In particular, a Blob represents immutable binary data. That means that it has to copy the input anyway. Given that, it doesn't make sense to pass the input by reference if the caller _does_ happen to have an WebIDL array object. But worse yet, actual real-life callers call this with JS arrays. So the current IDL forces creation of a new WebIDL array object which is then thrown away because Blob makes a copy of the data anyway. Seems like a waste. -Boris
[Bug 18809] New: Some examples in the index section (3.3.4) have errors
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18809
Summary: Some examples in the index section (3.3.4) have errors
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: trivial
Priority: P4
Component: Indexed Database API
AssignedTo: dave.n...@w3.org
ReportedBy: art.bars...@nokia.com
QAContact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
The following email reported errors in the examples in the "index" section
(3.3.4):
[[
http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0672.html
As far as I can tell, there is no "openIndex" method as shown in the "var
index" example below. I think it should be objectStore.index() ? Also, I am
assuming that the var vtx is a versionchange transaction object, but vtx is not
defined anywhere else in the documentation. Just figured I would pass these
along :)
3.3.4 Index
var db = indexedDBSync.open('AddressBook', 2, function(trans, oldVersion) {
if (oldVersion === 1) {
trans.db.createObjectStore('Contact', {keyPath:'id', autoIncrement:true});
}
var store = vtx.objectStore('Contact');
store.createIndex('ContactName', {unique:false, multiEntry:false});
});
var index = store.openIndex('ContactName');
var id = index.get('Lincoln');
// id === 1
]]
--
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
