[Bug 7104] New: Disagreement on handling of null value for localStorage.setItem()
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7104 Summary: Disagreement on handling of null value for localStorage.setItem() Product: WebAppsWG Version: unspecified Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: normal Priority: P2 Component: Web Storage AssignedTo: i...@hixie.ch ReportedBy: br...@python.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Created an attachment (id=718) -- (http://www.w3.org/Bugs/Public/attachment.cgi?id=718) test page that shows what localStorage.getItem() thinks null should be In Safari 4, if you use null as a value when setting a new key it will end up returning the string null. But in Firefox 3.5, you get back null itself. I have attached a dead-simple HTML file that shows the differences when run in the two browsers. Not sure who is right since the spec says a DOMString is expected and I am not sure if null is considered a valid DOMString. And in both browsers you end up with a key being set. While in Safari that makes sense since you are getting back a string, but in Firefox that's confusing as the value for the key is the same as the value used to signify that no value exists for the key. That means in Firefox the only way to know that the key is actually set explicitly to null is to iterate through all the keys using localStorage.key() to try to see if the key has actually been given a value. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 7104] Disagreement on handling of null value for localStorage.setItem()
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7104 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added CC||i...@hixie.ch Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #5 from Ian 'Hixie' Hickson i...@hixie.ch 2009-08-09 22:04:35 --- I propose to make the spec just use the default behaviour specified by Web IDL. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 7720] New: Redundant definition of openDatabase methods
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7720
Summary: Redundant definition of openDatabase methods
Product: WebAppsWG
Version: unspecified
Platform: All
URL: http://dev.w3.org/html5/webdatabase/#databases
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Web Database
AssignedTo: i...@hixie.ch
ReportedBy: nikunj.me...@oracle.com
QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org
There seems to be no difference between the openDatabase methods defined in
WindowDatabase and WorkerUtilsDatabase.
It is possible to restructure these interfaces differently so that there is
less redundancy. My proposal is the following IDL:
[Supplemental, NoInterfaceObject]
interface DatabaseAsyncOpen {
Database openDatabase(in DOMString name, in DOMString version, in DOMString
displayName, in unsigned long estimatedSize, in optional DatabaseCallback
creationCallback);
};
Window implements DatabaseAsyncOpen;
[Supplemental, NoInterfaceObject]
interface DatabaseSyncOpen {
DatabaseSync openDatabaseSync(in DOMString name, in DOMString version, in
DOMString displayName, in unsigned long estimatedSize, in optional
DatabaseCallback creationCallback);
};
WorkerUtils implements DatabaseSyncOpen;
WorkerUtils implements DatabaseAsyncOpen;
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
[Bug 7938] New: SECURITY_ERR when disallowing Database open is inconsistent with QUOTA_EXCEEDED_ERR for disallowing setItem
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7938 Summary: SECURITY_ERR when disallowing Database open is inconsistent with QUOTA_EXCEEDED_ERR for disallowing setItem Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Web Storage AssignedTo: i...@hixie.ch ReportedBy: nikunj.me...@oracle.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org In WebDatabase: The user agent may raise a SECURITY_ERR exception instead of returning a Database object if the request violates a policy decision (e.g. if the user agent is configured to not allow the page to open databases). Under setItem(), the Web Storage spec says: # If it couldn't set the new value, the method must raise an # QUOTA_EXCEEDED_ERR exception. (Setting could fail if, e.g., the user has # disabled storage for the site, or if the quota has been exceeded.) Per Jonas [1]: It seems silly to [sic] for *every* feature mention that the UA may do something different if the user has opted to disable a feature for whatever reason. [1] http://www.w3.org/mid/63df84f0909211145y2837d45fpb50f5285f7401...@mail.gmail.com Both cases look similar enough and it feels inappropriate to proliferate error codes for each different situation. Proposal: Use one error code for both. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 7938] SECURITY_ERR when disallowing Database open is inconsistent with QUOTA_EXCEEDED_ERR for disallowing setItem
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7938 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added CC||i...@hixie.ch Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #1 from Ian 'Hixie' Hickson i...@hixie.ch 2009-10-21 09:09:45 --- EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: QUOTA_EXCEEDED_ERR makes sense when you're trying to _set_ something, because disabling setting is like making the quota zero. SECURITY_ERR makes sense when _opening_ something, because that's what's used on the platform consistently for that kind of error. I think making these two consistent would be inappropriate. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 8358] New: Fix for the localStorage mutex problem - release for *any* API operation except localStorage itself
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8358 Summary: Fix for the localStorage mutex problem - release for *any* API operation except localStorage itself Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Web Storage AssignedTo: i...@hixie.ch ReportedBy: robert.enn...@intel.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org This is a proposal I made earlier on the whatwg mailing list, and then presented at TPAC. I believe I said I would file a proper bug report for it. How about this for a solution for the localStorage mutex problem: the user agent MAY release the storage mutex on *any* API operation except localStorage itself This guarantees that the common case of several storage operations in a row with nothing in-between works, but gives the implementors the freedom to release the storage mutex wherever else they find they need to. I ran this by a few people at the W3C tpac (where I am now) and everyone I talked to seemed to think this would work. -Rob -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 8358] [WA] Fix for the localStorage mutex problem - release for *any* API operation except localStorage itself
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8358 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #1 from Ian 'Hixie' Hickson i...@hixie.ch 2009-11-25 23:54:13 --- Implementors on the WHATWG list didn't seem happy with this unfortunately. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 8406] New: Stricter Specifications on Mouse Events Specifically primary, auxillary, and secondary default actions
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8406 Summary: Stricter Specifications on Mouse Events Specifically primary, auxillary, and secondary default actions Product: WebAppsWG Version: unspecified Platform: All URL: http://dev.w3.org/2006/webapi/DOM-Level-3- Events/html/DOM3-Events.html#events-mouseevents OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DOM3 Events AssignedTo: schep...@w3.org ReportedBy: warcraftthre...@sbcglobal.net QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org This covers a few things related to MouseEvents. In order to get rid of OnContextMenu and to supply a standard way to deal with the middle mouse button mouseup should have its Default action defined in the specification. The button for MouseEvent already has the comment: During mouse events caused by the depression or release of a mouse button, button shall be used to indicate which pointer device button changed state. 0 must indicate the primary button of the device (in general, the left button or the only button on single-button devices, used to activate a user interface control or select text). 2 must indicate the secondary button (in general, the right button, often used to display a context menu). 1 must indicate the auxiliary button (in general, the middle button, often combined with a mouse wheel). Some mice may provide or simulate more buttons, and values higher than 2 may be used to represent such buttons. - http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-Events-MouseEvent-button So we have 0 - Left Mouse Button 1 - Middle Mouse Button 2 - Right Mouse Button Since the event click already handles buttons and links and has a prevent default that means for mousedown and mouseup the left mouse button doesn't require any changes. However, middle mouse button does have a default action whether the specification says so or not. In many browsers it creates a scroll icon allowing the user to scroll by moving the mouse. This behavior should be denoted as the default action when button = 1. For button = 2 (right mouse button) the context menu should be denoted as the default action. Using the preventDefault should allow one to cancel these default actions at the browser level. http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-event-type-preventDefault This should clear up any confusion about mouse buttons and should allow for a seamless transition into web applications. With this the left, middle, and right mouse buttons can be utilized. How browsers implement or override this functionality is up to them, but right now this is a mess and it needs to be specified. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 8758] New: Define DOMContentLoaded
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8758 Summary: Define DOMContentLoaded Product: WebAppsWG Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DOM3 Events AssignedTo: schep...@w3.org ReportedBy: ms2...@gmail.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org HTML5 fires a DOMContentLoaded event. [1] It would probably be useful to define it in DOM3Events. [1] http://www.whatwg.org/html5/#stop-parsing -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 8241] Named properties on window
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8241 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Ian 'Hixie' Hickson i...@hixie.ch 2010-01-17 07:39:03 --- Oops, I screwed up adding the diff link. My bad. Anyway the change is pretty simply IIRC, I just added [ReplaceableNamedProperties] to Window. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 8814] New: Introduction paragraph and example are out of sync
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8814 Summary: Introduction paragraph and example are out of sync Product: WebAppsWG Version: unspecified Platform: All URL: http://dev.w3.org/html5/webdatabase/ OS/Version: All Status: NEW Severity: trivial Priority: P5 Component: Web Database AssignedTo: i...@hixie.ch ReportedBy: tdillo...@gmail.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org The introduction has a paragraph that explains the JavaScript example. In that paragraph is says it calls a section function, getDatabase(). First, I think section is a typo and instead you were meaning second. Secondly, there is no function called getDatabase in the example. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9562] New: Opening a database with a different description is underspecified
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9562 Summary: Opening a database with a different description is underspecified Product: WebAppsWG Version: unspecified Platform: All URL: http://www.mail-archive.com/public-webapps@w3.org/msg0 8084.html OS/Version: All Status: NEW Severity: normal Priority: P2 Component: WebSimpleDB AssignedTo: nikunj.me...@oracle.com ReportedBy: sdwi...@forerunnerdesigns.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org The spec is unspecified as to what we should do when a database is opened with a different description than it was previously opened. I'd assume we'd want to update the description. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9653] New: How to handle nullable violations is not specified.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9653 Summary: How to handle nullable violations is not specified. Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: WebSimpleDB AssignedTo: nikunj.me...@oracle.com ReportedBy: sdwi...@forerunnerdesigns.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org The spec doesn't say what the correct course of action is if a consumer passes null to something that is not null. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9698] New: Rename all instances of noOverwrite to overwite
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9698 Summary: Rename all instances of noOverwrite to overwite Product: WebAppsWG Version: unspecified Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P2 Component: WebSimpleDB AssignedTo: nikunj.me...@oracle.com ReportedBy: sdwi...@forerunnerdesigns.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org We should rename all instances of noOverwrite to just overwrite and flip the default in the spec. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9738] New: Improve IDL documentation
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9738 Summary: Improve IDL documentation Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Keywords: editorial Severity: minor Priority: P2 Component: WebSimpleDB AssignedTo: eliot...@microsoft.com ReportedBy: nikunj.me...@oracle.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org 1. Use Complete sentences. 2. Sequence constraints before attributes before methods. 3. Change On getting ... sentences to match the style in http://dev.w3.org/html5/spec-author-view/urls.html#reflecting-content-attributes-in-idl-attributes -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9739] New: Editorial review from timeless on March 24, 2010
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9739 Summary: Editorial review from timeless on March 24, 2010 Product: WebAppsWG Version: unspecified Platform: All URL: http://krijnhoetmer.nl/irc-logs/webapps/20100324 OS/Version: All Status: NEW Keywords: editorial Severity: normal Priority: P2 Component: WebSimpleDB AssignedTo: eliot...@microsoft.com ReportedBy: nikunj.me...@oracle.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org so, i had trouble following the last part 'the key applicable for some index that references that object store' i don't see how that precise thing actually gives me the right individual record it maybe be 'some applicable key for an index that references it in its object store' but i'm not sure A key range is a continuous interval over some data type used for keys. can you write 'some key refdata type/ref' ? A key range may be left-bounded or right-bounded if there is a value that is, respectively, smaller than or larger than all its elements. i think less/greater, but i'm not certain (it's midnight, i'm exhausted, and sick, and have a headache) A key range is said to be bounded if it is both left- and right-bounded and unbounded otherwise. 'otherwise unbounded' A valid key range must be either half-bounded or bounded. i don't think you've defined 'half-bounded' The storage operations are performed on the underlying index or an object store. I think you can omit 'The' A cursor comprises a range of records in either an index or an object store. A cursor maintains a position over this series, which moves in a direction that is either monotonically increasing or decreasing order of the record keys. you start by talking about a 'range' and then switch to a 'series' If the scope is static, it can cover either all the object stores and indexes in a database or it may include a subset of them. and if it's dynamic? A connection may have at most one transaction at any given time. i think you need a word before 'at' something like 'open' or 'running' or 'active' Moreover, there may not be any overlap among the scopes of all open connections to a given database. this is confusing if scopes are limited to transactions, then i think it'd be better to say 'among the scope of all (active?) transactions to a given database' or perhaps scopes Conforming user agents may terminate transactions that take too long to complete in order to free up storage resources that are locked by a long running transaction. the may is interesting, as a useragent, i'd be tempted to terminate transactions that take too much ram :) 3.2.1 Opening the database should it be 'a' ? The steps for opening a database are as follows. the first thing that follows isn't a step These steps must be run with an origin, a database name and description. drop 'a' from before 'database', or add 'a' before 'description' All the steps must be run atomically: drop 'the'? note that i'm not sure what 'All' means here does it mean that each step is atomic, or the effect of the entire set of steps is atomic? If there is already a database with the given name from the origin origin origin origin :( 3.2.2 Object Store Storage steps 3.2.1 didn't include 'steps', why does 3.2.2? These steps must be run with four parameters: the object store, a value, an optional key, and an optional no-overwrite flag. 'must'/'four' seems odd given that two are optional If store uses out-of-line keys but no key generator, then a key must be passed to these steps. If not, terminate these steps and set error code DATA_ERR. i think it'd rather this be one if condition If (store.uses(out_of_line_keys) !store.has_(key_generator) !key) then terminate( ) If store uses in-line keys, then let key be the property of object at store's key path. what happens if 'key' was an argument? Using store's key generator, produce the next key and store it as key. i'd avoid using the phrase 'store it' If store uses in-line keys, then store key as the property value for object at store's key path. using 'store' 3 times in a sentence with sometimes different meanings is really confusing :( If any indexes are auto-populated for store, then store a record in that index according to index maintenance conditions. 'any indexes' is plural -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9745] New: We should require nextprotoneg support when doing the TLS handshake for WebSocket.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9745 Summary: We should require nextprotoneg support when doing the TLS handshake for WebSocket. Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#ope ning-handshake-0 OS/Version: other Status: NEW Severity: normal Priority: P3 Component: WebSocket API (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: i...@hixie.ch, m...@w3.org, public-webapps@w3.org Section: http://www.whatwg.org/specs/web-apps/current-work/complete.html#opening-handshake-0 Comment: We should require nextprotoneg support when doing the TLS handshake for WebSocket. Posted from: 98.248.33.53 by i...@hixie.ch -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9766] New: We should expose the subprotocol for the case of the client not specifying one but the server specifying one
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9766 Summary: We should expose the subprotocol for the case of the client not specifying one but the server specifying one Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#web socket OS/Version: other Status: NEW Severity: normal Priority: P3 Component: WebSocket API (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: i...@hixie.ch, m...@w3.org, public-webapps@w3.org Section: http://www.whatwg.org/specs/web-apps/current-work/complete.html#websocket Comment: We should expose the subprotocol for the case of the client not specifying one but the server specifying one Posted from: 98.248.33.53 by i...@hixie.ch -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9768] New: Indexes should hang off of objectStores rather than the IDBDatabaseRequest/Sync objects
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9768 Summary: Indexes should hang off of objectStores rather than the IDBDatabaseRequest/Sync objects Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: WebSimpleDB AssignedTo: nikunj.me...@oracle.com ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Indexes should hang off of objectStores rather than the IDBDatabaseRequest/Sync objects. This makes sense since indexes are always associated with 1 (and only 1) objectStore. This has been discussed several times, the latest being in the thread with the subject [IndexDB] Proposal for async API changes [1]. [1] http://www.mail-archive.com/public-webapps@w3.org/msg08825.html -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9769] New: IDBObjectStoreRequest/Sync.put should be split into 3 methods
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9769 Summary: IDBObjectStoreRequest/Sync.put should be split into 3 methods Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: WebSimpleDB AssignedTo: nikunj.me...@oracle.com ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org IDBObjectStoreRequest/Sync.put currently takes an optional parameter noOverwrite But as was discussed in [IndexedDB] Changing the default overwrite behavior of Put [1] what we really need is a tri-state: only insert, only modify, or either. Maciej suggested we should just have 3 separate functions. This was re-iterated with Mozilla's proposal (well, 3 guys _from_ Mozilla's proposal :-) in [IndexDB] Proposal for async API changes [2]. I think the current leading proposal naming wise is add/modify/addOrModify. It's unfortunate that the common case (addOrModify) is the most verbose one, but as discussed in the second thread, it's the most clear set of names anyone's proposed so far. [1] http://www.mail-archive.com/public-webapps@w3.org/msg08646.html [2] http://www.mail-archive.com/public-webapps@w3.org/msg08825.html -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9786] New: WebIDL bugs in IndexedDB spec
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9786 Summary: WebIDL bugs in IndexedDB spec Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: WebSimpleDB AssignedTo: nikunj.me...@oracle.com ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org -- Forwarded message -- From: Dominique Hazael-Massieux d...@w3.org Date: Fri, May 21, 2010 at 9:57 AM Subject: IndexedDB WebIDL bugs To: public-webapps public-webapps@w3.org Hi, Glancing quickly at the editors draft of http://dev.w3.org/2006/webapi/WebSimpleDB/ and with help from the WebIDL checker, I've found the following problems: * none of the interfaces/exceptions are marked with the extended attribute [NoInterfaceObject] I doubt they are all meant to be visible in the global namespace * The IDBDatabaseException Interface uses the attribute keyword for code and message - exceptions don't have attributes, the keyword should be removed * IDBDatabaseSync.createObjectStore uses an extended attribute [Null=Null] on its second parameter - I suspect it was meant to be [TreatUndefinedAs=Null], and if so, the type of the parameter should be DOMString? rather than DOMString Based on the discussions on the list, and as the beginning of 3.3 seems to allude to, synchronous operations are only going to be used in Workers; I suggest to state that clearly, and also to start the first example of the spec with the async example if that's the one that is most likely to be used. Dom -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9789] New: We should use the IDB prefix on all IDB interfaces
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9789 Summary: We should use the IDB prefix on all IDB interfaces Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: nikunj.me...@oracle.com ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Andrei Popescu proposed a couple naming changes to the interfaces within IndedexDB deep within the [IndexDB] Proposal for async API changes thread [1]. One of them suggested we consistently use the IDB prefix on all IndexedDB interfaces. Jeremy, Shawn, and Jonas have concurred. - I know we need to keep the IDB prefix in order to avoid collisions with other APIs. I would therefore think we should keep the IDB prefix and make sure all the interfaces start with it (right now they don't). [1] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0801.html -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9790] New: Request is not a good suffix for all the async interfaces in IndexedDB
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9790 Summary: Request is not a good suffix for all the async interfaces in IndexedDB Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: nikunj.me...@oracle.com ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Andrei Popescu proposed a couple naming changes to the interfaces within IndedexDB deep within the [IndexDB] Proposal for async API changes thread [1]. One of the proposals was to change the Request suffix that's used for all the asynchronous interfaces (but not necessarily the IDBRequest object, since that's a bit different). The voices are Andrei, Shawn, Jonas, and Jeremy in that order: - The Request suffix is now used to denote the asynchronous versions of the API interfaces. These interfaces aren't actually Requests of any kind, so I would like to suggest changing this suffix. In fact, if the primary usage of this API is via its async version, we could even drop this suffix altogether and just add Sync to the synchronous versions? I agree that Request seems confusing and seems to be contrary to what other specs use. We should try to follow what other specs do here. Agreed on both accounts. There unfortunately isn't much in the way of precedence here. There are three other specs to look at here, which specify API for both workers and main thread. * Web Workers spec http://www.whatwg.org/specs/web-workers/current-work/ This spec doesn't actually use different interfaces for workers and main thread. * File API http://dev.w3.org/2006/webapi/FileAPI/ Specifies FileReader and FileReaderSync. The two interfaces are separate and doesn't inherit from a common base * WebSQLDatabase http://dev.w3.org/html5/webdatabase/ Specifies separate interfaces, like Database and DatabaseSync. The two interfaces are separate and doesn't inherit from a common base. I think we should follow the same convention as File API and WebSQLDatabase. There really isn't anything to be gained by having a common base interface, it just makes the spec harder to read as functionality is distributed between the base interface and the sync/async interface. I additionally like the naming convention. The async interfaces is probably the interface that people will use first. Additionally that interface is available both to workers and to the main thread. So it makes sense to give the async interface the simpler name. Agreed on all counts. I would add that, if we did decide to keep base interfaces, we could always suffix them with Base (which I think makes it more clear they're base interfaces)...but it sounds like that might not be necessary. [1] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0801.html -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9791] New: IDBDatabase should (possibly) be renamed to IDBConnection
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9791 Summary: IDBDatabase should (possibly) be renamed to IDBConnection Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: nikunj.me...@oracle.com ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Andrei Popescu proposed a couple naming changes to the interfaces within IndedexDB deep within the [IndexDB] Proposal for async API changes thread [1]. One of the proposals was to change IDBDatabase to IDBConnection. This proposal met with some opposition (unlike the other two) and thus should probably be discussed further and possibly marked as invalid. The voices are Andrei, Shawn, Jonas, and Jeremy in that order: - Some of the interfaces could have names that would more closely reflect their roles in the API. For instance, IDBDatabase could be renamed to IDBConnection, since in the spec it is described as a connection to the database. This sounds good as well. Not really sold on this. I've always hated the connection abstraction. With our suggested API IDBDatabase really just holds metadata information about the database, and doesn't need to represent a connection at all. Well, if we don't make these proposed changes, then I think it's pretty important to rename to connection since the current spec does distinguish between each connection. With your proposal, this is not currently true, but I think it's hard to say whether or not these concepts will creep back in in later versions. In addition, the entire spec is related to databases, so I think naming it a connection rather than a database helps distinguish it from the rest. That said, if IndexedDatabase* becomes IDBFactory* then there certainly is a lot less confusion already, and this change is less important. [1] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0801.html -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9793] New: Allow dates and floating point numbers in keys
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9793 Summary: Allow dates and floating point numbers in keys Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: nikunj.me...@oracle.com ReportedBy: pablo.cas...@microsoft.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Currently the spec requires the values referenced by the key path to be integers or strings. I strongly believe that we should also allow dates and floating point numbers (am I missing any other important types?). While dates and floating point numbers alone are not good for a primary key, they are important for non-unique indexes and as part of a composite key, allowing for things such as scanning in temporal order. This is the change I'd like to propose: Section 3.1.1 Keys of the currently published draft reads: - In order to efficiently retrieve records stored in an indexed database, a user agent needs to organize each record by its key. Conforming user agents must support the use of values of IDL data types [WEBIDL] DOMString and long as well as the value null as keys. For purposes of comparison, a DOMString key is always evaluated higher than any long key. Moreover, null always evaluates lower than any DOMString or long key. - New proposed text: - In order to efficiently retrieve records stored in an indexed database, a user agent needs to organize each record by its key. Conforming user agents must support the use of values of IDL data types [WEBIDL] DOMString, long, float, and the Date JavaScript object, as well as the value null as keys. For purposes of comparison, all DOMString values are evaluated as greater than long, float, and Date values; Date values are evaluated as greater than long and float values; and long and float values are evaluated by their numeric value with no need to separate them by type. Moreover, null always evaluates less than any other key value that is a non-null value. For the particular case of floating point numbers, the value NaN is not allowed. - I realize that it's weird to have Date as a JavaScript object and the rest as Web IDL types, but there doesn't seem to be any reference to Date() in Web IDL, and I don't want to leave it out just because it's not there. Last time we discussed this topic Nikunj wasn't sure if this was the right time, but there was support [1] [2] and no pushback. Assuming we're still there, then Eliot (who'll start helping Nikunj with editing) can incorporate it into the spec. [1] http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0353.html [2] http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0664.html -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9796] New: IndexedDB's async interface should be available within workers
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9796 Summary: IndexedDB's async interface should be available within workers Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: nikunj.me...@oracle.com ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Pablo originally suggested this in [IndexedDB] Detailed comments for the current draft [1]: Currently the async API is only available on the window object and not to workers. Libraries are likely to target only one mode, in particular async, to work across all scenarios. So it would be important to have async also in workers. As far as I can tell, no one has ever disagreed with this comment and recently it came up again late in the [IndexedDB] Proposal for async API changes thread [2]. On Thu, May 20, 2010 at 9:37 PM, Shawn Wilsher sdwi...@mozilla.com wrote: On 5/20/2010 12:19 PM, Jonas Sicking wrote: I additionally like the naming convention. The async interfaces is probably the interface that people will use first. Additionally that interface is available both to workers and to the main thread. So it makes sense to give the async interface the simpler name. That is not how it is currently specified (and our proposal doesn't indicate either way). The asynchronous versions are not available to worker threads. I do recall discussion on this, however... That makes Mozilla, Google, and Microsoft all in favor of this feature. We should do it. There's one small snag though: the current spec has an indexedDB property on Window and WorkerUtils that point to different interfaces (one sync, one not). We should probably change WorkerUtils.indexedDB to WorkerUtils.indexedDBSync to be more inline with what other synchronous APIs have done (that have an async counterpart). [1] http://www.mail-archive.com/public-webapps@w3.org/msg07386.html [2] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0806.html -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9823] New: Add maxExecutionContexts property with number of hardware execution contexts
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9823 Summary: Add maxExecutionContexts property with number of hardware execution contexts Product: WebAppsWG Version: unspecified Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Web Workers (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: robert.enn...@intel.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org It is likely that people will want to use the Web Workers API for creating multiple threads to perform some kind of CPU-bound computation more efficiently than they could with a single thread. In particular, Section 1.2.6 (Delegation) talks about splitting a task across multiple workers in order to gain performance. In this particular example, the number of workers is fixed at 10, but this is likely to be the wrong number in most cases. Right now, the spec gives no guidance to developers about how many workers they should use for compute-bound jobs. In the absence of such information, it seems likely that developers will do something ugly like choose a fixed number that seemed to work well on the device they tested on, attempt to identify which of a finite number of known devices the app is running on using user-agent sniffing, or just create far more workers than needed in the hope that the user agent will deal with the problem. I suggest we just add a simple maxExecutionContexts property with descriptive text like: This value is the maximum number of hardware execution contexts that may be available to applications running in the User Agent. Other activity in the User Agent or on the system may be using these resources at any time (including during or after the request for information is made). It is not the number of free, unused resources. User Agents may exclude dedicated processors that they know are not available for applications or may choose to set thread priorities low for applications that overuse system resources by starting too many WebWorkers on a busy system. maxExecutionContexts is not an optimal or recommended number of workers to create. If another app is using some of the cores, then the optimal number of cores may be lower. If your workers are often IO bound, then the optimal number of cores may be higher. Similarly if worker-communication costs are significant, it may not be useful to use all available cores. maxExecutionContexts is however a number that can be useful for an app that wants to choose an appropriate number of workers to create. At the simplest level, the fact that maxExecutionContexts is greater than 1 tells an app that it may be able to gain some performance from some level of parallelism, and the fact that maxExecutionContexts is a large number may indicate that it is wise for the app to split its work into finer-grain chunks than if it was smaller. It is up to an individual developer to determine how the number of workers they create corresponds to maxExecutionContexts; however it is likely that the availability of this number will help them make better decisions than they would if this information was not available. -Rob -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9698] Rename all instances of noOverwrite to overwite
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9698 Jeremy Orlow jor...@chromium.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jor...@chromium.org Resolution||DUPLICATE --- Comment #1 from Jeremy Orlow jor...@chromium.org 2010-06-02 14:01:23 --- *** This bug has been marked as a duplicate of bug 9769 *** -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9832] New: keyPath is underspecified
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9832 Summary: keyPath is underspecified Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: nikunj.me...@oracle.com ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org KeyPaths and their underspecification has come up in several threads, but especially [IndexedDB] KeyPaths and missing properties [1]. We need to have normative text describing how to parse keyPath and how a keyPath maps to properties of a value. We need to decide whether we want to allow explicit index management and whether we want this to be done via ObjectStore's add/modify/addOrModify or whether we want to have methods hanging off of each index to do this. We need to decide what to do if the key corresponding to a keyPath doesn't exist (insert null, insert nothing, or raise error). This list may be incomplete. [1] http://www.mail-archive.com/public-webapps@w3.org/msg08862.html -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9882] New: Behavior when attempting to write data to an objectStore opened as read only unspecified
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9882 Summary: Behavior when attempting to write data to an objectStore opened as read only unspecified Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: nikunj.me...@oracle.com ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org When you open an objectStore with a read only mode, any subsequent write operation should probably result in an error. I don't see anywhere in the spec that specifically says this or mentions what error code should be used. Currently in the spec, writing with the noOverwrite flag set causes a CONSTRAINT_ERR, so I'm guessing that's the best one to go with for this condition as well? -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9789] We should use the IDB prefix on all IndexedDB interfaces
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9789 Andrei Popescu andr...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Andrei Popescu andr...@google.com 2010-06-10 16:27:38 --- Fixed in http://dvcs.w3.org/hg/IndexedDB/rev/d697d377f9ac -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9903] New: Need to define specification and use of collations for string sorting
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9903 Summary: Need to define specification and use of collations for string sorting Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P1 Component: Indexed Database API AssignedTo: nikunj.me...@oracle.com ReportedBy: pablo.cas...@microsoft.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Currently the spec does not define what collation algorithm should be used for string sorting. In order to properly support international applications we need to define both how implementations should use collations and how the API exposes options for the developer to choose a collation for a certain scope (database, index, etc.) Original WG message for context: From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Mikeal Rogers Sent: Wednesday, June 09, 2010 2:42 PM To: Webapps WG Subject: [IndexDB] Collation Algorithm? One of the things I noticed that seems to be missing from the IndexDB specification is the collation algorithm used for sorting the index keys. There are lots of collation differences between databases, if left unspecified I'm afraid this would negatively affect interoperability between IndexDB implementations. CouchDB has a good collation specification for rich keys (any JSON type) and defers to the Unicode Collation Algorithm once it hits string comparisons. This might be a good starting point. http://wiki.apache.org/couchdb/View_collation#Collation_Specification http://www.unicode.org/reports/tr10/ -Mikeal -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9921] New: IDBIndexedDatabase should be called IDBFactory
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9921 Summary: IDBIndexedDatabase should be called IDBFactory Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: andr...@google.com ReportedBy: andr...@google.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org IDBIndexedDatabase serves as the entry point into the Indexed Database API and its role is to provide methods for creating various IDB objects (e.g. IDBDatabase, KeyRanges, etc). See also the changes to IDBIndexedDatabase proposed by Jonas in http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0717.html The group agreed to rename IDBIndexedDatabase to IDBFactory in http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0966.html -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9921] IDBIndexedDatabase should be called IDBFactory
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9921 Andrei Popescu andr...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Andrei Popescu andr...@google.com 2010-06-14 11:00:53 --- Fixed in https://dvcs.w3.org/hg/IndexedDB/rev/fd6e8c03ce1c -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9561] IDBRequest should inherit from EventTarget
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9561 Nikunj Mehta nikunj.me...@oracle.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #2 from Nikunj Mehta nikunj.me...@oracle.com 2010-06-14 16:47:48 --- Fixed in f4e65358110c -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9903] Need to define specification and use of collations for string sorting
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9903 Nikunj Mehta nikunj.me...@oracle.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Nikunj Mehta nikunj.me...@oracle.com 2010-06-15 20:00:55 --- The spec already does what the bug asks for. Check WebIDL for more help with access constants defined in interfaces. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9903] Need to define specification and use of collations for string sorting
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9903 Nikunj Mehta nikunj.me...@oracle.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | --- Comment #2 from Nikunj Mehta nikunj.me...@oracle.com 2010-06-15 20:01:46 --- Wrong comment and closure -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9888] Constants are not accessible when they're needed for most IndexedDB interfaces.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9888 Nikunj Mehta nikunj.me...@oracle.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WORKSFORME --- Comment #7 from Nikunj Mehta nikunj.me...@oracle.com 2010-06-15 20:02:27 --- The spec already does what the bug asks for. Check WebIDL for more help with access constants defined in interfaces. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9768] Indexes should hang off of objectStores rather than the IDBDatabaseRequest/Sync objects
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9768 Nikunj Mehta nikunj.me...@oracle.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9563] The events passed to the event handlers are underspecified
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9563 Nikunj Mehta nikunj.me...@oracle.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9769] IDBObjectStoreRequest/Sync.put should be split into 3 methods
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9769 Nikunj Mehta nikunj.me...@oracle.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9769] IDBObjectStoreRequest/Sync.put should be split into 3 methods
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9769 Jeremy Orlow jor...@chromium.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #6 from Jeremy Orlow jor...@chromium.org 2010-06-17 15:29:32 --- How was this agreed upon??? You posted your suggestion to the list and less than half a day later implemented it despite an on-going discussion on the list and no one agreeing with you. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9793] Allow dates and floating point numbers in keys
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9793 Eliot Graff eliot...@microsoft.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Eliot Graff eliot...@microsoft.com 2010-06-20 15:13:41 --- Changed per text with minor editing to language to increase readability. Thanks for the clear proposed text. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9973] New: If the entry's name is sec-websocket-protocol 0 please don't put normative requirements in parenthesis
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9973 Summary: If the entry's name is sec-websocket-protocol 0 please don't put normative requirements in parenthesis Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#est ablish-a-websocket-connection OS/Version: other Status: NEW Severity: normal Priority: P3 Component: WebSocket API (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Section: http://www.whatwg.org/specs/web-apps/current-work/complete.html#establish-a-websocket-connection Comment: If the entry's name is sec-websocket-protocol 0 please don't put normative requirements in parenthesis Posted from: 88.131.66.80 -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9975] New: Mozilla async API proposal
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9975 Summary: Mozilla async API proposal Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: nikunj.me...@oracle.com ReportedBy: jo...@sicking.cc QAContact: member-webapi-...@w3.org CC: m...@w3.org, andr...@google.com, public-webapps@w3.org A few people from mozilla recently made a proposal for improvements to the Indexed DB asynchronous interface. The proposal in its entirety is here: http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0717.html http://docs.google.com/View?id=dfs2skx2_4g3s5f857 The main changes are: 1. Once a database has been opened (a database connection has been established) read access to meta-data, such as objectStore and index names, is synchronous. Changes to such meta data, such as creating objectStores and indexes, is still asynchronous. 2. You can only add requests to read and write data to a transaction during a transaction callback. There is one exception to this rule (more below). 3. Transactions are automatically committed. Once a request in a transaction finishes and there are no more requests queued against the transaction, the transaction is committed. 4. Cursors do not fire error events if a request to open a cursor yields zero results or when iterating using a cursor reaches the end of the found results. Instead, a success event is fired which indicates that no more results are available. 5. All reads and writes are done through transactions. However in some places the transaction is implicit (but defined). 6. Access to index objects are done through API on objectStore objects. 7. Separate functions for add/add-or-modify. 8. Calling abort() on read request always cancels the request, even if the implementation has already read the data and is ready to fire a success event. The error event is always fired if abort() is called, and the success event is suppressed. 9. You are allowed to have multiple transactions per database connection. However if they use overlapping tables, only the first one will receive events until it is finished (with the usual exceptions of allowing multiple readers of the same table). There was one thing in our initial proposal which have met resistance and so have been dropped: We're not suggesting any changes to factory functions for KeyRanges at this point. KeyRange construction changes might not be needed and in any case is orthogonal to the rest of the proposal so lets not discuss it now. Additionally, some people were concerned about the getAll/getObjectAll functions. Though toward the end of that discussion it seemed like people were less concerned so we might want to include it after all. In any case mozilla is planning on putting it in our preliminary implementation. / Jonas -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9790] Request is not a good suffix for all the async interfaces in IndexedDB
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9790 Andrei Popescu andr...@google.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #1 from Andrei Popescu andr...@google.com 2010-06-22 13:56:55 --- Fixed in http://dvcs.w3.org/hg/IndexedDB/rev/378e74fd2c7a -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9989] New: Is the number of replacement characters supposed to be well-defined? If not this should be explicitly noted. If it is then more detail is required.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9989 Summary: Is the number of replacement characters supposed to be well-defined? If not this should be explicitly noted. If it is then more detail is required. Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#han dling-errors-in-utf-8-from-the-server OS/Version: other Status: NEW Severity: normal Priority: P3 Component: WebSocket API (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Section: http://www.whatwg.org/specs/web-apps/current-work/complete.html#handling-errors-in-utf-8-from-the-server Comment: Is the number of replacement characters supposed to be well-defined? If not this should be explicitly noted. If it is then more detail is required. Posted from: 88.131.66.80 -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10000] New: Allow expressions in addition to keyPaths when creating indexes
http://www.w3.org/Bugs/Public/show_bug.cgi?id=1 Summary: Allow expressions in addition to keyPaths when creating indexes Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: nikunj.me...@oracle.com ReportedBy: jo...@sicking.cc QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org For details, see http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/1094.html The idea is to allow a full javascript expression to be passed to createIndex. This expression would be run every time a new or modified object is stored in an objectStore. The expression would produce zero or more index values that should be associated with the stored object. There's lots of details to figure out still, such as the syntax of the expression and which context it will be running in. And how non-js implementations would supply this expression. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9790] Request is not a good suffix for all the async interfaces in IndexedDB
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9790 Nikunj Mehta nikunj.me...@oracle.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #2 from Nikunj Mehta nikunj.me...@oracle.com 2010-06-26 23:59:54 --- Because all the abstract interfaces were removed, it was necessary to correct NoInterfaceObject modifiers on IDBObjectStore, IDBCursor, IDBObjectStoreSync, and IDBCursorSync -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10027] New: Remove explicit add/remove functions from IDBIndex
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10027 Summary: Remove explicit add/remove functions from IDBIndex Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: nikunj.me...@oracle.com ReportedBy: jo...@sicking.cc QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org The spec currently allows entries to be manually added and removed from indexes. While this is one solution to the problem of indexing on computed values, it's not one that seems very popular. There are currently a few other proposals that have been made for example [1] and [2]. Until we figure out how to do more complex indexes, I propose we remove the add/put/remove functions from IDBIndex. Similarly I propose that calling update() on a cursor opened using IDBIndex.openCursor is not allowed. [1] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/1094.html [2] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0882.html -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10052] New: Specify setVersion details
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10052
Summary: Specify setVersion details
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Indexed Database API
AssignedTo: nikunj.me...@oracle.com
ReportedBy: jo...@sicking.cc
QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org
In the thread started at [1] there were some discussions about how setVersion
should work. It seems like there was consensus (at least among the participants
in the thread) for the following behavior
When setVersion(X) is called, perform the following steps:
1. Create a IDBRequest object, /request/.
2. If there are no other IDBDatabase objects open to the same database, skip to
next step.
Otherwise, asynchronously fire a versionchange event targeted at those
IDBDatabase objects. The versionchange event implements a
IDBVersionChangeEvent interface defined below, and has the 'version' property
is set to X. Also asynchronously fire a 'blocked' event on /request/.
3. Return the /request/ object and finish the setVersion call.
4. Once all other IDBDatabase objects are closed, initiate a transaction with
mode VERSION_CHANGE. As long as this transaction is open, no other IDBDatabase
objects can be opened to the same database.
5. Fire a 'success' event on /request/ with .transaction set to the transaction
created in step 5.
6. Follow the normal steps for transactions (i.e. allow requests to be placed,
etc)
When createObjectStore/createIndex/removeObjectStore/removeIndex is called,
perform the following steps:
1. If we're not currently firing a 'success' event on a VERSION_CHANGE
transaction, throw an exception. I.e. only 'success' event handlers inside a
VERSION_CHANGE transaction can make schema related modifications. However note
that it's not just the 'success' event from the original setVersion call that
is allowed to make schema changes. You can also make them from, for example,
the success event fired after a 'get' request, as long as that 'get' request
was made on a VERSION_CHANGE transaction.
2. If removeObjectStore or removeIndex is called, remove the relevant object if
it exists and return from the function. If it doesn't exist, do nothing and
return from the function.
3. If createObjectStore/createIndex is called with invalid parameters, such as
an invalid keyPath, throw an exception. Likewise, if the objectStore or index
already exists, throw an exception.
4. Create the requested object and add it to the database. Return the newly
created object and return from the function.
Add a .close() function to IDBDatabase. When the function is called, perform
the following steps:
1. Set a internal /closePending/ flag to true. If .transaction is called, and
/closePending/ is true, an exception is thrown (or should we just make
.transaction return null?)
2. Once all pending transactions are finished, the IDBDatabase is fully closed.
This unblocks any pending setVersion calls made on other IDBDatabase objects
connected to the same database.
IDL for related APIs:
IDBDatabase {
...
IDBObjectStore createObjectStore(in DOMString name,
[TreatNullAs=EmptyString]
in optional DOMString keyPath,
in optional boolean autoIncrement);
readonly attribute bool closePending;
void close();
...
};
IDBObjectStore {
...
IDBIndex createIndex(in DOMString name, in DOMString keyPath,
in optional boolean unique);
...
};
interface IDBVersionChangeEvent : IDBEvent {
readonly attribute string version;
};
[1] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/1141.html
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
[Bug 10056] New: IDBEvent should inherit from DOM Level 3 Event
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10056 Summary: IDBEvent should inherit from DOM Level 3 Event Product: WebAppsWG Version: unspecified Platform: PC URL: http://www.w3.org/TR/DOM-Level-3-Events/#interface-Eve nt OS/Version: Windows NT Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: nikunj.me...@oracle.com ReportedBy: sdwi...@forerunnerdesigns.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Per http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/thread.html#msg1178, we should make IDBEvent inherit from Event. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10064] New: Modifying functions should throw when called under invalid conditions
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10064 Summary: Modifying functions should throw when called under invalid conditions Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: andr...@google.com ReportedBy: jo...@sicking.cc QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org There are a number of situations where we immediately upon call to modifying functions know that the call was made in error without consulting the database. This applies in the following situations: 1. When IDBObjectStore.add, IDBObjectStore.put, IDBObjectStore.remove, IDBCursor.update or IDBCursor.remove is called from a READ_ONLY transaction. 2. When the object provided to add/put/update can't be cloned using the structured clone algorithm. (we can rely on HTML5 to define when and what this throws) 3. When IDBCursor.update is called in such a way that it alters the key of the object. (only apples to in-line keys) 4. When IDBObjectStore.add or IDBObjectStore.put is called on an objectStore which doesn't use a key generator, and no key is provided (note that keys are supplied in-line in some stores) For more details about rationale, see the thread started at http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0002.html -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10064] Modifying functions should throw when called under invalid conditions
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10064 Andrei Popescu andr...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Andrei Popescu andr...@google.com 2010-07-02 20:01:54 --- Fixed in http://dvcs.w3.org/hg/IndexedDB/rev/e039f9694056 http://dvcs.w3.org/hg/IndexedDB/rev/0ac9282957a0 -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10088] New: The spec does not define what happens if an object store is modified while a cursor is iterating it.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10088 Summary: The spec does not define what happens if an object store is modified while a cursor is iterating it. Product: WebAppsWG Version: unspecified Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: andr...@google.com ReportedBy: andr...@google.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org It is possible to modify an object store while a cursor is iterating over its objects in the same transaction. Right now, the behavior of the cursor is unspecified. We discussed the 3 solutions for handling this situation: 1. Making the cursor iterate over a snapshot of the data, that is, modifications done during the iteration are not visible when the cursor callbacks fire. The snapshot would be taken when the cursor is created. 2. As 1, except that the snapshot is taken when the transaction starts. 3. Cursors iterate over live data and modifications to the object store are visible during the iteration. The consensus for now is to go with solution 3. For pros and cons of each approach as well as motivation for picking the current solution, please see: http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0056.html -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10127] New: EventSource does not need to deal with HTTP 3xx responses as they are dealt with by the fetching algorithm.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10127 Summary: EventSource does not need to deal with HTTP 3xx responses as they are dealt with by the fetching algorithm. Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#pro cessing-model-4 OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Server-Sent Events (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, ann...@opera.com, public-webapps@w3.org Section: http://www.whatwg.org/specs/web-apps/current-work/complete.html#processing-model-4 Comment: EventSource does not need to deal with HTTP 3xx responses as they are dealt with by the fetching algorithm. Posted from: 83.85.115.123 by ann...@opera.com -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10128] New: Step 4 of the EventSource algorithm should reference the fail the connection algorithm.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10128 Summary: Step 4 of the EventSource algorithm should reference the fail the connection algorithm. Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#dom -eventsource OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Server-Sent Events (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, ann...@opera.com, public-webapps@w3.org Section: http://www.whatwg.org/specs/web-apps/current-work/complete.html#dom-eventsource Comment: Step 4 of the EventSource algorithm should reference the fail the connection algorithm. Posted from: 83.85.115.123 by ann...@opera.com -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10129] New: The end of this WebSocket section links to EventSource with fail the connection. It should link to the WebSocket fail the connection instead.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10129 Summary: The end of this WebSocket section links to EventSource with fail the connection. It should link to the WebSocket fail the connection instead. Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#sen ding-the-server's-opening-handshake OS/Version: other Status: NEW Severity: normal Priority: P3 Component: WebSocket API (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, ann...@opera.com, public-webapps@w3.org Section: http://www.whatwg.org/specs/web-apps/current-work/complete.html#sending-the-server's-opening-handshake Comment: The end of this WebSocket section links to EventSource with fail the connection. It should link to the WebSocket fail the connection instead. Posted from: 83.85.115.123 by ann...@opera.com -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10130] New: The steps to dispatch the event within EventSource should first remove the LF from the data buffer before checking whether it is empty. Otherwise it can never be empty.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10130 Summary: The steps to dispatch the event within EventSource should first remove the LF from the data buffer before checking whether it is empty. Otherwise it can never be empty. Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#dis patchMessage OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Server-Sent Events (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, ann...@opera.com, public-webapps@w3.org Section: http://www.whatwg.org/specs/web-apps/current-work/complete.html#dispatchMessage Comment: The steps to dispatch the event within EventSource should first remove the LF from the data buffer before checking whether it is empty. Otherwise it can never be empty. Posted from: 83.85.115.123 by ann...@opera.com -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10131] New: Please make it clear that Last-Event-ID has a value that consists of UTF-8 octets. HTTP headers do not have strings.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10131 Summary: Please make it clear that Last-Event-ID has a value that consists of UTF-8 octets. HTTP headers do not have strings. Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#pro cessing-model-4 OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Server-Sent Events (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, ann...@opera.com, public-webapps@w3.org Section: http://www.whatwg.org/specs/web-apps/current-work/complete.html#processing-model-4 Comment: Please make it clear that Last-Event-ID has a value that consists of UTF-8 octets. HTTP headers do not have strings. Posted from: 83.85.115.123 by ann...@opera.com -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10143] New: how long is the comment going to be?
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10143 Summary: how long is the comment going to be? Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#int roduction-6 OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Web Messaging (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Section: http://www.whatwg.org/specs/web-apps/current-work/complete.html#introduction-6 Comment: how long is the comment going to be? Posted from: 122.169.72.128 -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10165] New: IDBRequest.abort() should throw on non-read-only requests or simply be removed
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10165 Summary: IDBRequest.abort() should throw on non-read-only requests or simply be removed Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: nikunj.me...@oracle.com ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org As discussed in the thread [IndexedDB] IDBRequest.abort on writing requests [1], it's dangerous to allow IDBRequest.abort() to be called on any request that has side effects. The best solution brought up in the thread was to have it throw if you call it on any request that isn't read only. But later on in the thread, I think it became fairly questionable that IDBRequest.abort() provides any value in the current spec since none of the read only operations should be particularly long running and in the few cases where you might truly need to do an abort, you can simply roll back the transaction. [1] http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0190.html -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9975] Mozilla async API proposal
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9975 Andrei Popescu andr...@google.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Andrei Popescu andr...@google.com 2010-07-15 17:18:20 --- Fixed in http://dvcs.w3.org/hg/IndexedDB/rev/f05d8668e4ac There may be errors / things I got wrong. I think we should open separate bugs for such problems. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10211] New: Remove the no host-specific component requirement for targetOrigin, see implementor discussion in http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027136.html and su
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10211 Summary: Remove the no host-specific component requirement for targetOrigin, see implementor discussion in http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/20 10-July/027136.html and subsequent messages Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#pos ting-messages OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Web Messaging (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Section: http://www.whatwg.org/specs/web-apps/current-work/complete.html#posting-messages Comment: Remove the no host-specific component requirement for targetOrigin, see implementor discussion in http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027136.html and subsequent messages Posted from: 84.208.127.109 -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10213] The definition of absolute url makes https:foo not an absolute url, since its behavior depends on whether the base is https: or not. Is that desired? In particular, using this defini
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10213 Simon Pieters sim...@opera.com changed: What|Removed |Added CC||public-webapps@w3.org Component|HTML5 spec (editor: Ian |WebSocket API (editor: Ian |Hickson)|Hickson) Product|HTML WG |WebAppsWG QAContact|public-html-bugzi...@w3.org |member-webapi-...@w3.org --- Comment #1 from Simon Pieters sim...@opera.com 2010-07-20 21:34:35 --- Changing component so Hixie sees this while working on websockets. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9766] We should expose the subprotocol for the case of the client not specifying one but the server specifying one
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9766 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9973] If the entry's name is sec-websocket-protocol 0 please don't put normative requirements in parenthesis
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9973 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||NEEDSINFO --- Comment #1 from Ian 'Hixie' Hickson i...@hixie.ch 2010-07-22 05:25:27 --- Not sure what this is referring to. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9989] Is the number of replacement characters supposed to be well-defined? If not this should be explicitly noted. If it is then more detail is required.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9989 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||NEEDSINFO --- Comment #1 from Ian 'Hixie' Hickson i...@hixie.ch 2010-07-22 05:27:48 --- I don't understand what isn't well-defined. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10129] The end of this WebSocket section links to EventSource with fail the connection. It should link to the WebSocket fail the connection instead.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10129 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||FIXED -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10213] The definition of absolute url makes https:foo not an absolute url, since its behavior depends on whether the base is https: or not. Is that desired? In particular, using this defini
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10213 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||NEEDSINFO --- Comment #2 from Ian 'Hixie' Hickson i...@hixie.ch 2010-07-22 05:39:43 --- ws:foo isn't absolute, therefore per spec it's treated as non-absolute. Am I missing something? Are browsers not implementing the spec here? -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10213] The definition of absolute url makes https:foo not an absolute url, since its behavior depends on whether the base is https: or not. Is that desired? In particular, using this defini
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10213 Boris Zbarsky bzbar...@mit.edu changed: What|Removed |Added Status|RESOLVED|REOPENED CC||bzbar...@mit.edu Resolution|NEEDSINFO | --- Comment #3 from Boris Zbarsky bzbar...@mit.edu 2010-07-22 05:50:07 --- ws:foo isn't absolute, How is a browser supposed to know that? Trying to create a URI from that string without a base URI successfully creates one, for example... Are browsers not implementing the spec here? Nope. Neither Gecko nor webkit throw on such a url, for example. In Gecko's case, because the concept of absolute url the spec uses (one which resolves to different things depending on the base) matches nothing that Necko exposes, and because by the definition normally used in Gecko (it's an absolute URL if you can parse it as a url even if there is no base) this url is absolute. See also https://bugzilla.mozilla.org/show_bug.cgi?id=580234 which is what prompted me to read this section to start with. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9989] Is the number of replacement characters supposed to be well-defined? If not this should be explicitly noted. If it is then more detail is required.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9989 Simon Pieters sim...@opera.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|NEEDSINFO | --- Comment #2 from Simon Pieters sim...@opera.com 2010-07-22 13:25:19 --- The spec says to replace bytes *or* sequences of bytes that are not valid utf-8 with U+FFFD. It is thus not well-defined how many U+FFFD are expected for any given sequence of bytes that are not valid utf-8. It could be one or the same amount of bytes that are not valid, or anything in between. (The same applies to text/html parsing.) -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10234] New: Unused argument in example function prepareDatabase()
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10234 Summary: Unused argument in example function prepareDatabase() Product: WebAppsWG Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Web Database (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: eu...@debian.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Argument 'ready' in example function prepareDatabase() is never used. Because of this next use of prepareDatabase() in the example will not execute useful code. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10269] New: Step 2 of the WebIDL [[Delete]] algorithm is wrong
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10269 Summary: Step 2 of the WebIDL [[Delete]] algorithm is wrong Product: WebAppsWG Version: unspecified Platform: PC URL: http://dev.w3.org/2006/webapi/WebIDL/#delete OS/Version: All Status: NEW Severity: normal Priority: P2 Component: WebIDL AssignedTo: c...@mcc.id.au ReportedBy: m...@apple.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org http://dev.w3.org/2006/webapi/WebIDL/#delete Step 2 is: 2. If O has the DontDelete attribute, return false. It should be: 2. If the property with name P on object O has the DontDelete attribute, return false. (Of course, this will need to change for ES5 anyway.) -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10302] New: Introduce exception handlers at the transaction/database scope
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10302 Summary: Introduce exception handlers at the transaction/database scope Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: nikunj.me...@oracle.com ReportedBy: pablo.cas...@microsoft.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org In many cases error handling will the same for most database access points throughout an application, so having a hierarchy of error handlers would have a good effect in reducing redundant setup of error handlers all over the code. As proposed by Jonas we could have operation-, transaction- and database-scoped error handlers. I'm not sure about tying up .preventDefault() to wether the trasaction gets aborted because you may just want to stop the event from bubbling, but we can discuss this when we come up with the actual write up for this for the spec. Snippet from relevant thread[1] copied below. Somewhat unrelated, but I wonder if we should consider a global (per database session) error handler or something like that. Database operations are just too granular, so maybe the usual deal where you setup an error handler per-operation is not the right thing to do. This is a great idea. What we could do is to first fire the 'error' event on the IDBRequest. If .preventDefault() is not called, we'll fire an 'error' event on the IDBTransaction. If .preventDefault() still hasn't been called, we fire an 'error' event on the IDBDatabase. If .preventDefault() *still* hasn't been called, we roll back the transaction. This is very similar to error handling in Workers. It might be overly complex implementation wise, but it does seem like a nice API for authors. [1] http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0231.html -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10304] New: Rename remove method on object store to delete
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10304 Summary: Rename remove method on object store to delete Product: WebAppsWG Version: unspecified Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: nikunj.me...@oracle.com ReportedBy: k...@sitepen.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Based on the mailing list discussion, it was generally agreed that we could rename the remove method on the object store API back to it's original name of delete. This was originally renamed due to EcmaScript reserved word concern, but since all implementations are targeting EcmaScript 5, and delete is contextually unreserved in ES5, the use of delete is perfectly fine, and the most clear word for the action of the method. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10305] New: [IndexedDB] Transactions need to be clarified
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10305 Summary: [IndexedDB] Transactions need to be clarified Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: andr...@google.com ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org It seems that we weren't all on the same page in terms of how transactions were supposed to work. I think it was agreed that the language is a bit vague and that we should put more detail in the spec about how they should work. Jonas' email [1] on the thread ([IndexedDB] Implicit transactions) probably sums the expected behavior up best. [1] http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0376.html -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10307] New: [indexedDB] The default version string is not specified
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10307 Summary: [indexedDB] The default version string is not specified Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: andr...@google.com ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org When you create a new database, we need to specify what the version string defaults to. might be a good answer. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10321] New: [IndexedDB] Description attribute of IDBDatabase doesn't play nicely with run to completion
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10321 Summary: [IndexedDB] Description attribute of IDBDatabase doesn't play nicely with run to completion Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: andr...@google.com ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org When opening a database, one of the parameters is description. If you specify it, that description is set on the database, no matter what the previous description was. There's also a description attribute on IDBDatabase(+ Sync). Since IndexedDB is usable by workers (and other pages' event loops, in some implementations) this presents a problem with run to completion. The easiest solution is to spec IDBDatabase(Sync).description to be the description you passed in to .open (and not a live value). I believe this is the only synchronous attribute with such a problem. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10322] New: open() should not throw for non same-origin URL
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10322 Summary: open() should not throw for non same-origin URL Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: XHR 1.0 AssignedTo: ann...@opera.com ReportedBy: ann...@opera.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org At the moment XMLHttpRequest Level 1 prescribes that open() invoked with a non same-origin URL should throw. This is incompatible with XMLHttpRequest Level 2. Instead we should align with XMLHttpRequest Level 2 (and some implementations) and treat non same-origin URLs as a network error during the request phase (i.e. after send() is invoked). This gives a better migration path towards CORS and allows us to test this requirement in browsers that implement (parts of) XMLHttpRequest Level 2. Along with this we should then also start throwing when the user/password arguments of open() are non-null for a non same-origin URL as XMLHttpRequest Level 2 does that as well. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10323] New: responseXML for HTML documents
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10323 Summary: responseXML for HTML documents Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: XHR 1.0 AssignedTo: ann...@opera.com ReportedBy: ann...@opera.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Since we have a dependency on HTML already for responseText (and elsewhere) we should just bite the bullet and add the dependency on responseXML as well and align here with XMLHttpRequest Level 2 so responseXML can remain unchanged. I.e. responseXML for a text/html resource would give a Document representing that resource. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10324] New: send() should set Content-Type to text/html for HTML documents
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10324 Summary: send() should set Content-Type to text/html for HTML documents Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: XHR 1.0 AssignedTo: ann...@opera.com ReportedBy: ann...@opera.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org When the Document object passed to send is created by createHTMLDocument() or an HTML parser the media type should not be application/xml. The Document object will be serialized according to HTML rules already, but the Content-Type set for it is currently incorrect. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10325] New: single conformance class
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10325 Summary: single conformance class Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: XHR 1.0 AssignedTo: ann...@opera.com ReportedBy: ann...@opera.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org We should drop the XML conformance class in favor of requiring XML support from everyone. XMLHttpRequest Level 2 already does this and there is no implementation that does not support XML. This only complicates keeping the two drafts in sync for no benefit. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10326] New: make user:password in URLs a SYNTAX_ERR
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10326 Summary: make user:password in URLs a SYNTAX_ERR Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: XHR 1.0 AssignedTo: ann...@opera.com ReportedBy: ann...@opera.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Currently user:password is an optional feature and I would rather kill support for it entirely than leave it as such. Now it cannot be tested basically. Can we do this? -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10327] New: supported URL schemes in open()
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10327 Summary: supported URL schemes in open() Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: XHR 1.0 AssignedTo: ann...@opera.com ReportedBy: ann...@opera.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org I would like to have clearer language for URLs regarding their supported scheme component. I.e. I would like it to be clear from the draft what happens if you use any of the following: mailto:f...@example.org; about:blank tag:example.org tel:+316... data:text/html,... My preferred solution would be to throw unless the URL scheme is one of a whitelist which contains: http https ftp file (implementation specific, must throw a SYNTAX_ERR if the current scheme is not file) We can add to this whitelist in the future, such as the blob URL scheme. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10328] New: change Accept-Charset to should not
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10328 Summary: change Accept-Charset to should not Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: XHR 1.0 AssignedTo: ann...@opera.com ReportedBy: ann...@opera.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Currently the specification states that Accept-Charset should be set as appropriate by the user agent. However, Accept-Charset is a useless header that is on its way out. Opera already dropped it from requests and Mozilla is planning to. Alternatively maybe the specification should not say anything about Accept-Charset and Accept-Encoding except that authors do not have control over them and that content-encodings used in transmission are automatically decoded by the user agent. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10052] Specify setVersion details
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10052 Andrei Popescu andr...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Andrei Popescu andr...@google.com 2010-08-09 22:25:09 --- Fixed in http://dvcs.w3.org/hg/IndexedDB/rev/e03a6bfd0c2e -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10337] New: add [Supplemental] support
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10337 Summary: add [Supplemental] support Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: WebIDL AssignedTo: c...@mcc.id.au ReportedBy: i...@hixie.ch QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org For specification process reasons, some interface definitions don't get organised the same way as we want from implementations. I've assumed that [Supplemental] will exist, and used it as follows: - Setting [Supplemental, NoInterfaceObject] on an interface X with no ancestor and then saying: Y implements X; ...implies that the members in X are imported into Y as if the definition of Y always had X in it. - Setting [Supplemental, NoInterfaceObject] on an interface X that inherits from Y implies that there are objects called Y that have all the members of X and Y with X not appearing on the prototype chain. - Setting [Supplemental] on an interface that has the same name as an interface definition without [Supplemental]. The distinction between these cases is that I have three different cases where I need to do this. One is where I have some objects, e.g. Window, that are made up of APIs defined in other specs, and those APIs are also used by other interfaces. So I define Window, and then other specs slide stuff into Window, and slide stuff into other interfaces (like Worker- related ones). Another is WorkerGlobalScope, which I want to be the name of the interface implementing the global scope for workers, but there are two types of workers, and they have slightly different interfaces. And the third is the deprecated interfaces, where one interface, e.g. HTMLAnchorElement, is defined in two places. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10211] Remove the no host-specific component requirement for targetOrigin, see implementor discussion in http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027136.html and subsequ
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10211 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||FIXED --- Comment #2 from Ian 'Hixie' Hickson i...@hixie.ch 2010-08-11 01:11:15 --- EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given below Rationale: Concurred with reporter's comments. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10349] New: [IndexedDB] IDBDatabase.description should be removed from the spec and made optional
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10349 Summary: [IndexedDB] IDBDatabase.description should be removed from the spec and made optional Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: andr...@google.com ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Per the [IndexedDB] question about description argument of IDBFactory::open() thread [1], we shouldremove IDBDatabase.description and make the param optional. [1] http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0459.html -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10357] New: [IndexedDB] Remove the SNAPSHOT_READ transaction mode
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10357 Summary: [IndexedDB] Remove the SNAPSHOT_READ transaction mode Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P1 Component: Indexed Database API AssignedTo: nikunj.me...@oracle.com ReportedBy: pablo.cas...@microsoft.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org We currently have two read-only transaction modes, READ_ONLY and SNAPSHOT_READ, that are identical in every aspect (point-in-time consistency for readers, allow multiple concurrent readers, etc.), except that they have different concurrency characteristics, with READ_ONLY blocking writers and SNAPSHOT_READ allowing concurrent writers come and go while readers are active. We agreed (see [1]) that we could remove the concept and only have READ_ONLY, leaving it up to the implementation whether writers block readers or readers are allowed and some mechanism is used to maintain point-in-time consistency semantics. [1] http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0485.html -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9745] We should require nextprotoneg support when doing the TLS handshake for WebSocket.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9745 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Ian 'Hixie' Hickson i...@hixie.ch 2010-08-13 07:25:35 --- Done. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10379] New: This is working
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10379 Summary: This is working Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#por ts-and-garbage-collection OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Web Messaging (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Section: http://www.whatwg.org/specs/web-apps/current-work/complete.html#ports-and-garbage-collection Comment: This is working Posted from: 216.239.45.4 -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10381] New: [IndexedDB] Structured clones should be created synchronously
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10381 Summary: [IndexedDB] Structured clones should be created synchronously Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: nikunj.me...@oracle.com ReportedBy: pablo.cas...@microsoft.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org The spec for the asynchronous put and add methods in object store as well as update in cursors don't explicitly state when clones are created, and can even be read as if clones should be created after the function call returned, when the queued up task is executed. This leads to problems where the clone may be modified after the call to put/add/update happens. Spec needs to be updated to indicate that the actual creation of the clone should happen synchronously while the put/add/update method is running, so the state of the object used to perform the database operation is as it was at the time the call was made, regardless of the timing of the actual execution of the method, timing of the callbacks, etc. Related discussion thread here: http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0501.html -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10382] New: [IndexedDB] Note on avoiding reader/writer starvation
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10382 Summary: [IndexedDB] Note on avoiding reader/writer starvation Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: nikunj.me...@oracle.com ReportedBy: pablo.cas...@microsoft.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Since in locking-based implementations it's going to be relatively easy to get into a situation where readers starve writers when working concurrently, we should have a note in the transactions section that encourages implementations to have explicit mechanisms to avoid starvation. We don't want to be too prescriptive, perhaps simply this statement: UAs need to ensure a reasonable level of fairness across readers and writers to prevent starvation. For reference, we discussed this here: http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0504.html -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10379] This is working
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10379 Anne ann...@opera.com changed: What|Removed |Added Status|NEW |RESOLVED CC||ann...@opera.com Resolution||INVALID -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 7720] Redundant definition of openDatabase methods
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7720 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||REMIND --- Comment #1 from Ian 'Hixie' Hickson i...@hixie.ch 2010-08-18 01:32:47 --- If the spec goes anywhere, this might be worth doing. Closing for now, though, since the spec seems dead. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10396] New: [IndexedDB] LEFT_BOUND and RIGHT_BOUND could be a bit more clear
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10396 Summary: [IndexedDB] LEFT_BOUND and RIGHT_BOUND could be a bit more clear Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: andr...@google.com ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Had a conversation with someone today who thought LEFT_BOUND and LEFT_OPEN were mutually exclusive. I think it couldn't hurt for the spec to be a bit more clear about what the flags mean and make it clear that, for example, LEFT_BOUND will be set iff bound or leftBound are used to create the key range. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10397] New: [IndexedDB] upper and lower bounds would be much clearer than right/left
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10397 Summary: [IndexedDB] upper and lower bounds would be much clearer than right/left Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: andr...@google.com ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org The spec refers to the various bounds of IDBKeyRange as right and left bounds. It then defines left as being a lower bound and right as being an upper. It seems silly not to just name the bounds upper and lower rather than right and left. At very least, the text in http://www.w3.org/TR/IndexedDB/#range-concept could be more clear. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10400] New: [IndexedDB] IDBCursor.continue should return an IDBRequest
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10400 Summary: [IndexedDB] IDBCursor.continue should return an IDBRequest Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: andr...@google.com ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org The IDL for IDBCursor.continue has it returning a boolean, but it's pretty clear it's supposed to be returning an IDBRequest. (The text for continue even talks about firing a success events on the returned object.) It also says that result should be null in the case of hitting the end of the range. It doesn't specify what it should be in the case that it's not at the end, though. Returning the key or the value doesn't make any sense because the key or value itself could be null (and thus there's no way to distinguish between the end and a null key/value). Returning null doesn't make sense because you still can't distinguish. The sync interface returns a bool to say whether it's at the end of the range. So it seems pretty clear to me that the async variation should too return a bool through the success event. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
