Re: [indexeddb] Issues stated on the current spec
Awesome list! > 1. Sections: 3.1.2 Object Store > Issue Text: specify that generators are not shared between stores. > Feedback: We prefer this approach. We should state this in the spec and > remove the issue. Agreed. This was the intent, but it might not be spelled out. Generators are not shared, and always produce the lowest integer larger than the highest key that has ever been inserted in the object store. This ensures that generators never generate a number that has existed in the object store. One tricky problem is what to do if someone inserts a non-numeric key in the object store. Such a key could be higher than any number that the generator could generate. I can think of three approaches: 1. Treat this the same way as inserting the number 2^64-1 into the object store. I.e. make it impossible to generate more numbers. The object store will have to be removed and recreated without recreating the high-valued key. 2. Throw a exception if a record is inserted with a non-numeric key in a object store which uses generators 3. Make generators generate numbers higher than the highest *numeric* value ever inserted. I'm leaning towards 3. The best implementation strategy for generators seems to be to record any insertions with explicit keys and make sure to update the generator current value to a higher number. To implement 3 all you'd need to do is to only do this for numeric keys. > 2. Section: 3.1.11 The IDBDatabaseException Interface > Issue Text: These codes are in flux and may change entirely as > exception/error handling may be changing in the WebIDL spec. > Feedback: It seems we can remove this comment and still go to last call. We > can always change these codes later. Actually, what we should do is use the new exception strategy that WebIDL uses. Which is that exceptions are differentiated using a .name, which is a string, rather than a numeric .code. > 3. Section: 3.2.3 Opening a database [IDBFactory.cmp()] > Issue Text: This should probably take a collation parameter as well. In fact, > it might make sense for this to be on the IDBDatabase, IDBObjectStore, and > IDBIndex as well and do the comparison with their default collation. > Feedback: Since we're not introducing collations in our APIs for v1, I > believe we can remove this comment. Agreed. > 4. Section: 3.2.7 Cursor [IDBCursor.delete()] > Issue Text: This method used to set this cursor's value to null. Do we want > to keep that? > Feedback: We believe that for the asynchronous APIs, the cursor is a cached > value and therefore it can still be accessed after we call delete. The > reason is that delete is an asynchronous operation that should only affect > the server value of the current record. The impact should only be felt the > next time you try to access this record from the server in any operation. We > should be able to specify this on the spec and remove the issue. Agreed. > 5. Section: 3.3.3 Object Store [In example] > Issue Text: The scenario above doesn't actually work well because you have to > unwind to the event loop to get the version transaction to commit before you > can do something else. Leaving it like this for now, as this will get sorted > out when we add callbacks for transactions in the sync API (we'll have to do > it for the setVersion transaction as well). > Feedback: I believe this will be simplified with the new version of open > which includes the db version. At that point, I expect this issue to go away. Agreed. > 6. Section: 3.3.4 Index [in example] > Issue Text: The scenario above doesn't actually work well because you have to > unwind to the event loop to get the version transaction to commit before you > can do something else. Leaving it like this for now, as this will get sorted > out when we add callbacks for transactions in the sync API (we'll have to do > it for the setVersion transaction as well). > Feedback: I believe this will be simplified with the new version of open > which includes the db version. At that point, I expect this issue to go away. Agreed. > 7. Section: 3.3.5 Cursor [in IDBCursorSync.delete()] > Issue Text: This method used to set this cursor's value to null. Do we want > to keep that? > Feedback: We believe that for synchronous APIs we need to ensure that the > client state reflects the server state. Since this call is synchronous, the > value associated with the cursor should be set to null after the delete API > is called. We should be able to specify this in the spec and remove the issue. I don't think that even in the synchronous API we want cursor.value to always reflect the value in the object store. For example if the object store is modified directly, rather than through a cursor, this wouldn't affect the value of the cursor. If we *do* want to ensure that cursor.value always reflected the value in the cursor, we'd have to run a database query every time cursor.value was accessed, which in the common case (i.e. when the obj
[indexeddb] Compound Key support for Primary Keys and Indexes
We looked at the spec to see what it would take to be able to support
multi-column keys on primary keys & indexes and we found some inconsistencies
that need to be addressed. Below is our proposal/assumptions on how to
constrain the problem and what needs to be updated in the spec to support this:
. Cursors are automatically sorted in ascending order but they can be retrieved
in descending order depending on the value passed to the
IDBObjectStore.createIndex. In other words, all of the attributes that make up
the index or the primary key will share the same direction. The default
direction will match the single index case.
. KeyRanges will act on the first element of the compound key (i.e. the first
column).
. IDBObjectStore.get and IDBIndex.get will be able to take in an array value.
Each value in the array will be mapped against the compound key defined in the
IDBObjectStore and the record will be queried using all of the compound key
values specified in the array. If using an IDBKeyRange, the range will only be
able to act on the first element of the compound key. Because the current type
of the get method parameter is an any, this will automatically support both
single and array values. For example,
---When retrieving the record of a single key index they do this:
var request = index.get("Israel Hilerio");
request.onsuccess = function (evt) { var record = this.result; }
---When retrieving the record of a compound key index they will query like
this:
var request = index.get(["PM","IE"]);
request.onsuccess = function (evt) { var record = this.result; };
. IDBIndex.getKey will be able to take in an array value. Each value in the
array will be mapped against the compound key defined in the IDBObjectStore and
the record will be queried using all of the compound key values specified in
the array. The result will be an array of values that can be accessed using
the property order of the compound key. Because the current type of the get
method parameter is an any and the type of the IDBRequest.result is an any,
this will automatically support both single and array values. For example,
---When retrieving the primaryKey of a single key record they do this:
var request = index.getKey("Israel Hilerio");
request.onsuccess = function (evt) { var primaryKey = this.result; }
---When retrieving the primaryKey of a compound key record they will query like
this:
var request = index.getKey(["PM","IE"]);
request.onsuccess = function (evt) { var firstKey = this.result[0]; var
secondKey = this.result[1] };
---This will also support an indexed property that doesn't contain any arrays
but the primary key of the record is an array. Notice that passing a string
into getKey will return an array as the result.
var request = index.getKey("Israel Hilerio");
request.onsuccess = function (evt) { var firstKey = this.result[0]; var
secondKey = this.result[1] };
. IDBCursor.key and IDBCursor.primaryKey won't have to change signature since
they are already any attributes. The current definition should allow them to
return an array if the key or primaryKey is a compound key. For example,
---When retrieving the value of a single key they do this:
var myKey = cursor.key;
---When retrieving the value of a compound key they will do this:
var myFirstKey = cursor.key[0];
var mySecondKey = cursor.key[1];
. The autoInc property will only apply to the first element on the compound
key. This will be consistent with our proposed KeyRange suggestion.
. We should change the signature of IDBObjectStore.keyPath to be DOMStringList
instead of DOMString. This will make it more intuitive that it supports arrays.
Let me know what you think.
Israel
Re: Mouse Lock
-- What if target is removed from DOM, or is not currently in DOM? -- Additional issues from Olli Pettay on w3 bug. I believe mouse lock should fail to acquire if the target is not in the DOM tree, and should be exited if the target of an existing lock is removed from the tree. -- Are user gestures generated while under mouse lock? -- >From a security point of view, should we sanitize the events generated when in mouse lock (click, down, up, ...) to be 'synthetic' and not 'user gestures'? E.g. in Chrome I believe you can only pop up new windows with window.open from script code triggered by a user gesture event. If we don't, and assuming security model allowing only mouse lock for DOM within top level document origin, then a page could direct user gesture events to any DOM element in their origin they wanted. That may be used for a form of 'click jacking'. On Thu, Aug 25, 2011 at 5:54 PM, Vincent Scheib wrote: > Continuing the discussion of some of the open issues I'm aware of: > > -- If MouseEvent types are returned under mouse lock, what should > .clientX/Y and screenX/Y be? -- > Spec as drafted states they should be the center of the target element. > That's likely a poor idea, as discussed, and a better solution is to > freeze .clientX/Y and screenX/Y to whatever their last value from the user > agent was. > > (Pending feedback, I will update spec to state that .clientX/Y .screenX/Y > will report the same constant values of the last known cursor position just > as mouse lock was entered. This will also be the location the system cursor > will be placed at when mouse lock is exited) > > -- Modify MouseEvent, or a new type returned by new mouse events? -- > Spec as drafted now has simply added .movementX/Y data members to the > MouseEvent type which is returned by mouse events: click, mousedown, > mouseup, mouseover, mousemove, mouseout. No new mouse event types are > introduced. > Several, including Glenn Maynard, Robert O'Callahan have brought up points > against this, suggesting different events and types. > > Let me enumerate options and my perceived pro/cons: > > Option A: as currently drafted: reuse existing mouse events, make minimal > modification to MouseEvent to include movementX/Y valid regardles of mouse > lock state, mouseover & mouseout will never be fired under mouse lock. > > pro 1. minimal change to existing events and types > pro 2. movementX/Y available even when mouse is not locked. Purely a > convenience, apps could compute similar data by tracking the last position > of a mouse event and computing deltas (resetting last position on a > mouseover event). > pro 3. event handling code that can operate both with and without mouse > lock being acquired can do so easily using the same functions and taking the > same MouseEvent data type input. e.g. rotateView(mouse_event) could be > called from a mousemove event regardless of mouse lock state and still use > .movementX/Y. > > con 1. When under mouse lock, clientX/Y screenX/Y will not offer any useful > data - or worse implementations may not follow spec and provide misleading > data of the actual hidden cursor location. > con 2. Not all mouse events using MouseEvent are appropriate, mouseover and > mouseout should be suppressed. Glen continued that it is """probably cleaner > to stop firing *all* mouse movement events entirely, as if the mouse isn't > moving, and to use a separate "mousedelta" event when locked which only has > "deltaX" and "deltaY".""" Robert reiterated that point. > > Option B: make no use of or modification to any existing mouse event or the > MouseEvent type. New mouse events created with unique names for click, down, > up, move, e.g. mouselockclick, mouselockdown, mouselockup, mouselockmove. > New events return a MouseLockEvent type derived from UIEvent that contains > movementX/Y, ctrlKey, shiftKey, altKey, metaKey, button. The events and data > types are completely mutually exclusive based on the state of mouse lock. > > pro 1. (dual of Option A con 1): clientX/Y screenX/Y do not exist under > mouse lock. > pro 2. (dual of Option A pro 3): Functions designed specifically to operate > only under mouse lock, or only when not under mouse lock, are only triggered > when appropriate. > > con 1. (dual of Option A pro 1): Larger change, introducing 4 new events > and a new return type. > con 2. (dual of Option A pro 2): movementX/Y must be calculated manually by > apps when not under lock. > > Some hybrid could be considered, e.g. only make a new mouselockmove event > but reuse the click/down/up events. I don't think that hybrid is worth > discussing. > > My opinion: > - Option A con 1 (.client .screen not useful, could be wrong): I don't > perceive much damage here, and if implementation are making mistakes much > more could go wrong elsewhere, but they don't get new data even with faulty > client and screen data. > - Option A con 2 (not all events returning MouseEvent are appropriate in > mouse lock) isn't substanti
[indexeddb] Issues stated on the current spec
Eliot and I went through the spec and identified the various issues stated in it. Below is our opinion on each of the open issues based on our understanding of the text. Based on this, there doesn't seem to be anything major that is blocking our ability to successfully move this spec to Last Call beyond the updating of the spec to reflect the new open/setVersion API. Let us know if you have a different point of view on how to resolve these issues. Israel Issues List: 1. Sections: 3.1.2 Object Store Issue Text: specify that generators are not shared between stores. Feedback: We prefer this approach. We should state this in the spec and remove the issue. 2. Section: 3.1.11 The IDBDatabaseException Interface Issue Text: These codes are in flux and may change entirely as exception/error handling may be changing in the WebIDL spec. Feedback: It seems we can remove this comment and still go to last call. We can always change these codes later. 3. Section: 3.2.3 Opening a database [IDBFactory.cmp()] Issue Text: This should probably take a collation parameter as well. In fact, it might make sense for this to be on the IDBDatabase, IDBObjectStore, and IDBIndex as well and do the comparison with their default collation. Feedback: Since we're not introducing collations in our APIs for v1, I believe we can remove this comment. 4. Section: 3.2.7 Cursor [IDBCursor.delete()] Issue Text: This method used to set this cursor's value to null. Do we want to keep that? Feedback: We believe that for the asynchronous APIs, the cursor is a cached value and therefore it can still be accessed after we call delete. The reason is that delete is an asynchronous operation that should only affect the server value of the current record. The impact should only be felt the next time you try to access this record from the server in any operation. We should be able to specify this on the spec and remove the issue. 5. Section: 3.3.3 Object Store [In example] Issue Text: The scenario above doesn't actually work well because you have to unwind to the event loop to get the version transaction to commit before you can do something else. Leaving it like this for now, as this will get sorted out when we add callbacks for transactions in the sync API (we'll have to do it for the setVersion transaction as well). Feedback: I believe this will be simplified with the new version of open which includes the db version. At that point, I expect this issue to go away. 6. Section: 3.3.4 Index [in example] Issue Text: The scenario above doesn't actually work well because you have to unwind to the event loop to get the version transaction to commit before you can do something else. Leaving it like this for now, as this will get sorted out when we add callbacks for transactions in the sync API (we'll have to do it for the setVersion transaction as well). Feedback: I believe this will be simplified with the new version of open which includes the db version. At that point, I expect this issue to go away. 7. Section: 3.3.5 Cursor [in IDBCursorSync.delete()] Issue Text: This method used to set this cursor's value to null. Do we want to keep that? Feedback: We believe that for synchronous APIs we need to ensure that the client state reflects the server state. Since this call is synchronous, the value associated with the cursor should be set to null after the delete API is called. We should be able to specify this in the spec and remove the issue. 8. Section: 4.2 Transaction Creation steps Issue Text: This should be specified more precisely. Maybe with some sort of global variable locked Feedback: Is this not addressed in the current spec? 9. Section: 4.8 VERSION_CHANGE transaction steps Issue Text: If .close() is called immediately but a transaction associated with the connection keeps running for a "long time", should we also fire a blocked event? Feedback: This seems like an optimization that individual User Agents can choose to make without affecting compatibility. Because of the asynchronous nature of the APIs, this behavior seems to be unavoidable. 10. Section: 4.10 Database deletion steps Issue Text: Should we allow blocked to be fired here too, if waiting takes "too long"? Feedback: We don't see the value of calling onblock twice because we don't provide a mechanism to cancel the db deletion transaction. All the onblock provides web developers is a mechanism for them to notify their users that the db is pending deletion. This doesn't seem to require more than one onblock. 11. Section: 4.12 Fire an error event Issue Text: TODO: need to define more error handling here. Feedback: Not sure what else we need. 12. Section: 5.7 Cursor Iteration Operation Issue Text: This should only be done right before firing the success event. Not asynchronously before. Not sure how/where to express that. Feedback: This seems more like a note rather than an issue. I believe we can just capture what you stated a
Re: [selectors-api] Return an Array instead of a static NodeList
> >> That works, but what is the advantage? And .push/.pop or other > >> mutating functions wouldn't work. > > > > All mutable functions will work (forEach, map, etc.) and bring a better > > expressiveness to the code. > > Not if he 'this' object is a NodeList. Yes, sorry I meant all “immutable” functions will work. Julien
Re: xdash name prefixes (was Re: Component Model Update)
On Fri, Aug 26, 2011 at 1:07 AM, Roland Steiner
wrote:
> On Thu, Aug 25, 2011 at 9:12 AM, Adam Barth wrote:
>>
>> On the other hand, it seems likely that some of these xdash names will
>> come into multi-party use. For example, the following use cases
>> involve xdash names chosen by one party and then used by another:
>>
>> http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Widget_Mix-and-Match
>> http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Contacts_Widget
>> http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Like.2F.2B1_Button
>
>
> Since the components that are used on a page are under the control of the
> page's author, it should be possible to avoid clashes by separating a
> component's definition (potentially pulled from third party) from its tag
> registration (done by page author), e.g.
> // Importing component definition for Facebook "Like" button
> // Importing component definition for Google+ "+1" button
> // ... later:
> Element.register("x-fb", Facebook.LikeButton)
> Element.register("x-gg", GooglePlus.PlusOneButton)
Doesn't it seem more likely that the third-party will do the
registration in whatever script you include that implements the Like
button, or whatever?
Adam
>> That's something like 40% of the use cases...
>>
>> I don't have much of a better suggestion. You're running up against
>> all the usual distributed extensibility issues.
>
> We could use namespaces... *ducks and runs* :D
>
> Cheers,
> - Roland
>
Re: [Component Model]: Shadow DOM Subtree per element: One or Many?
On Fri, Aug 26, 2011 at 12:24 AM, Roland Steiner wrote: > Unless I'm misunderstanding something, I believe this actually is - or at > least touches upon - several questions in disguise: > .) Do we want to allow decoration of elements that are already in the DOM > tree? If by "decoration" you mean "new ShadowRoot" then I think the answer is "yes." Why would you disallow it? It throws one more obstacle in the author’s way. > - which is for all intents and purposes a corollary of: > .) Do we allow calling of "new ShadowRoot" outside of an element > constructor? >From the DOM bindings point of view, it is very difficult to decide when a "constructor" is running. How would you do it? Stack walking? I don’t think any other bindings do this sort of thing. > If no, then we don't have a problem with "dead elements", because the author > can only declare new elements (and use encapsulation), but not meddle with > existing ones. FWIW, I don't think there is any real use-case for calling > "new ShadowRoot" within the constructor twice. I take the point that if you can only call it once, and only in constructors, then you can easily assign meaning to "new ShadowRoot(x) where x is not an extension element." It throws. But you could just make that restriction without all of these other restrictions on constructors, once only, etc. I don’t want us to confound being able to call it only once or more than once for a given element, being able to call it for extension elements only or built-in element types too, and being able to call it only inside constructors or also outside of constructors. > However, in this case we have to answer how encapsulation can address the > stated use cases for decoration. This probably means answering: > .) How is attribute forwarding handled from the host element to a nested > (form) element? +1. We should think about concrete proposals. Also: Do the use cases need it? And if we did nothing, what would authors do in response (ie how ugly are mutation listeners?) > .) How can components participate in forms (and other fun)? > ... or just leave decoration out for the time being (which I think is quite > reasonable). We should brainstorm other "fit" issues. What about the selection? Does it leak shadow nodes (probably not.) So can confined scripts ever read the selection? etc. > OTOH, if the answer to the decorators question is "yes", then the above > mentioned issues with multiple shadow roots arise. I think we need to think about these issues anyway. But maybe the multiple shadows problem is a good one to tackle early. Dominic
Re: Component Model Update
On Fri, Aug 26, 2011 at 12:42 AM, Roland Steiner wrote: > On Thu, Aug 25, 2011 at 4:24 PM, Dominic Cooney wrote: >> >> Here is a quick first cut: >> >> How about use cases like these: >> >> - Extension that wants to inspect and warn you >> when you are entering you password in an insecure form (from abarth >> earlier in the thread.) >> - Password manager that wants to find anything that looks like a login >> panel and decorate it/fill it. >> - Extension that removes formatting from a page to make it easier for >> on-screen reading. >> - Extension that finds phone numbers in a page and embosses them with >> links to a crank call service. >> - Extension that replaces all ads in a page with pictures of kittens. >> Or an extension that detects pictures of kittens and monetizes them >> with ads. >> - Extension that on hover looks up >> dictionary/thesaurus/translation/urban dictionary/wikipedia/etc. > > This is a great list! > As for allowing extensions to inspect the shadow DOM: unless we want to > break isolation/confinement again, I believe this should be handled by the > relevant browser APIs for extensions, along the lines of "shadow = > extensions.getShadowFor(element)". If the extension shouldn't be able to > mess with shadows, it can be blocked at this point. Yes, I think a separate function for doing the lookup is a good idea. It keeps the set of attributes and methods on a given DOM object the same for pages and extensions. Dominic
Re: Components/constructable DOM elements: mandatory tag registration?
I think HTMLElement.call should throw if there’s not an associated tag name.
However exactly how that association happens, I am not sure.
JavaScript can’t rely on the 'constructor' property. Shadowing the
tagName attribute on the prototype is not ideal, because it may be
mutable and it would be confusing if it was mutated.
Alternatively we could require subtypes of some specific tag, like
HTMLDivElement, and use that tag name if there's no registered tag
name. That means the UA can't limit special casing to x- elements,
although I think that is OK.
Dominic
On Fri, Aug 26, 2011 at 1:16 AM, Roland Steiner
wrote:
> From the discussion about "x-" prefixed names another question crossed my
> mind: Suppose an author defines a component, but doesn't register a tag
> name. AFAICT, at this point nothing prevents him from inserting such a new
> element into the DOM. E.g.:
>
>
> function MyNewElement() {
> HTMLElement.call(this);
> // ...
> }
> var div = document.getElementById("div");
> div.appendChild(new MyNewElement());
>
> // ... Look Ma, no Element.register() call!
>
> var text = div.innerHTML; // <- what does this return?
>
>
> Cheers,
> - Roland
Components/constructable DOM elements: mandatory tag registration?
>From the discussion about "x-" prefixed names another question crossed my
mind: Suppose an author defines a component, but doesn't register a tag
name. AFAICT, at this point nothing prevents him from inserting such a new
element into the DOM. E.g.:
function MyNewElement() {
HTMLElement.call(this);
// ...
}
var div = document.getElementById("div");
div.appendChild(new MyNewElement());
// ... Look Ma, no Element.register() call!
var text = div.innerHTML; // <- what does this return?
Cheers,
- Roland
Re: xdash name prefixes (was Re: Component Model Update)
On Thu, Aug 25, 2011 at 9:12 AM, Adam Barth wrote:
> On the other hand, it seems likely that some of these xdash names will
> come into multi-party use. For example, the following use cases
> involve xdash names chosen by one party and then used by another:
>
> http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Widget_Mix-and-Match
> http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Contacts_Widget
> http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Like.2F.2B1_Button
>
Since the components that are used on a page are under the control of the
page's author, it should be possible to avoid clashes by separating a
component's definition (potentially pulled from third party) from its tag
registration (done by page author), e.g.
// Importing component definition for Facebook "Like" button
// Importing component definition for Google+ "+1" button
// ... later:
Element.register("x-fb", Facebook.LikeButton)
Element.register("x-gg", GooglePlus.PlusOneButton)
That's something like 40% of the use cases...
>
> I don't have much of a better suggestion. You're running up against
> all the usual distributed extensibility issues.
>
We could use namespaces... *ducks and runs* :D
Cheers,
- Roland
Re: Component Model Update
On Thu, Aug 25, 2011 at 4:24 PM, Dominic Cooney wrote: > Here is a quick first cut: > > How about use cases like these: > > - Extension that wants to inspect and warn you > when you are entering you password in an insecure form (from abarth > earlier in the thread.) > - Password manager that wants to find anything that looks like a login > panel and decorate it/fill it. > - Extension that removes formatting from a page to make it easier for > on-screen reading. > - Extension that finds phone numbers in a page and embosses them with > links to a crank call service. > - Extension that replaces all ads in a page with pictures of kittens. > Or an extension that detects pictures of kittens and monetizes them > with ads. > - Extension that on hover looks up > dictionary/thesaurus/translation/urban dictionary/wikipedia/etc. > This is a great list! As for allowing extensions to inspect the shadow DOM: unless we want to break isolation/confinement again, I believe this should be handled by the relevant browser APIs for extensions, along the lines of "shadow = extensions.getShadowFor(element)". If the extension shouldn't be able to mess with shadows, it can be blocked at this point.
Re: [Component Model]: Shadow DOM Subtree per element: One or Many?
Unless I'm misunderstanding something, I believe this actually is - or at least touches upon - several questions in disguise: .) Do we want to allow decoration of elements that are already in the DOM tree? - which is for all intents and purposes a corollary of: .) Do we allow calling of "new ShadowRoot" outside of an element constructor? If no, then we don't have a problem with "dead elements", because the author can only declare new elements (and use encapsulation), but not meddle with existing ones. FWIW, I don't think there is any real use-case for calling "new ShadowRoot" within the constructor twice. However, in this case we have to answer how encapsulation can address the stated use cases for decoration. This probably means answering: .) How is attribute forwarding handled from the host element to a nested (form) element? .) How can components participate in forms (and other fun)? ... or just leave decoration out for the time being (which I think is quite reasonable). OTOH, if the answer to the decorators question is "yes", then the above mentioned issues with multiple shadow roots arise.
