[indexeddb] Client API state after calling trasnaction.abort
A couple of questions regarding client state vs. server state on several calls.
What should be the client behavior for subsequent calls after a transaction
abort is called? This assumes the server request hasn't been processed yet.
For example:
1.var txn = db.transaction([osName], IDBTransaction.READ_WRITE);
2.objStore = txn.objectStore(osName);
3.var rq = objStore.add(books[2]).onsuccess = function (e1) {
log("added book 2"); };
4.txn.abort();
5.try {
6. var rq2 = objStore.add(books[3]).onerror = function (e2) {
log("failed to add book 3"); };
7.catch (ex) {
8. log ("TRANSACTION_INACTIVE_ERR");
9.}
I expect that line #3 will receive the success event. However, I expect that
rq2 will throw a TRANSACTION_INACTIVE_ERR that will be processed by line #7 and
that the onerror function will never be called on line #6. My assumption is
that even if the transaction abort hasn't been processed by the server, that
the client state associated with the transaction will contain an invalid
transaction and thus fail.
Do you agree?
Israel
RE: [indexeddb] Behavior when calling IDBCursor.continue multiple times
I like what you wrote :-) Israel On Tuesday, July 12, 2011 5:18 PM, Jonas Sicking wrote: > On Tue, Jul 12, 2011 at 4:55 PM, Israel Hilerio wrote: > > I see what you're saying. > > > > What we originally wanted to convey was that calling this method > consecutively or in a row within the same onsuccess handler is not > allowed. This assumed the success handler was not invoked in between these > calls. > > Would something similar to what I just wrote be enough to clarify the > statement? > > It's not really related to it happening from the same onsuccess handler > though, right? For example when creating joins you'll likely end up > .continue'ing a cursor from the onsuccess handler of another cursor or a > .get() > request. When doing that you also need to be careful to not call continue > before > > Maybe something like: > > "Calling .continue more than once before new cursor data has been loaded is > not allowed and results in a NOT_ALLOWED_ERR exception being thrown. For > example calling .continue twice from the same onsuccess handler results in a > NOT_ALLOWED_ERR being thrown on the second call." > > But I'd definitely put it in a as to make sure that it's non- > normative so that people don't misunderstand it to mean that > NOT_ALLOWED_ERR is only thrown during the above mentioned condition. > > / Jonas
Re: [indexeddb] Behavior when calling IDBCursor.continue multiple times
On Tue, Jul 12, 2011 at 4:55 PM, Israel Hilerio wrote: > I see what you're saying. > > What we originally wanted to convey was that calling this method > consecutively or in a row within the same onsuccess handler is not allowed. > This assumed the success handler was not invoked in between these calls. > Would something similar to what I just wrote be enough to clarify the > statement? It's not really related to it happening from the same onsuccess handler though, right? For example when creating joins you'll likely end up .continue'ing a cursor from the onsuccess handler of another cursor or a .get() request. When doing that you also need to be careful to not call continue before Maybe something like: "Calling .continue more than once before new cursor data has been loaded is not allowed and results in a NOT_ALLOWED_ERR exception being thrown. For example calling .continue twice from the same onsuccess handler results in a NOT_ALLOWED_ERR being thrown on the second call." But I'd definitely put it in a as to make sure that it's non-normative so that people don't misunderstand it to mean that NOT_ALLOWED_ERR is only thrown during the above mentioned condition. / Jonas
[Bug 13229] New: The following text from the "Security considerations" part of "11 IANA considerations" is wrong: "An event stream from an origin distinct from the origin of the content consuming th
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13229 Summary: The following text from the "Security considerations" part of "11 IANA considerations" is wrong: "An event stream from an origin distinct from the origin of the content consuming the event stream can result in information leakage. To avoid this, user agen Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top 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, public-webapps@w3.org Specification: http://dev.w3.org/html5/eventsource/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: The following text from the "Security considerations" part of "11 IANA considerations" is wrong: "An event stream from an origin distinct from the origin of the content consuming the event stream can result in information leakage. To avoid this, user agents are required to block all cross-origin loads." Posted from: 2620:101:8003:200:226:bbff:fe05:3fe1 User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0a1) Gecko/20110707 Firefox/8.0a1 Firefox/8.0a1 -- 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.
RE: [indexeddb] Behavior when calling IDBCursor.continue multiple times
I see what you're saying. What we originally wanted to convey was that calling this method consecutively or in a row within the same onsuccess handler is not allowed. This assumed the success handler was not invoked in between these calls. Would something similar to what I just wrote be enough to clarify the statement? Israel On Monday, July 11, 2011 9:24 PM, Jonas Sicking wrote: > Hmm.. The fix here is somewhat unclear. Obviously you're allowed to call > .continue multiple times if a "success" event fires in between. > > The very first sentence in the definition for .continue reads: > > "If this cursor's got value flag is false, this method throws a > NOT_ALLOWED_ERR". > > Was this not enough? > > I'd be fine with keeping the current sentence, but it would need to be > clarified > to make it clear that .continue() can be called multiple times if "success" > fires > in between, and that "success" event doesn't represent reaching the end of > the cursor. Or something to that extent. > > / Jonas > > On Thu, Jul 7, 2011 at 3:32 PM, Eliot Graff wrote: > > For both IDBCursor.continue and IDBCursorSync.continue, > > > > Added one paragraph to the description: > > If you call this method multiple times, the cursor throws a > NOT_ALLOWED_ERR exception and does not continue. If you catch the error > you can then iterate through the cursor normally. > > > > Standardized the wording in the async and sync NOT_ALLOWED_ERR > description to be: > > The cursor is currently being iterated, or has iterated past its end. > > > > Eliot > > > > From: public-webapps-requ...@w3.org > > [mailto:public-webapps-requ...@w3.org] On Behalf Of Jeremy Orlow > > Sent: Monday, June 27, 2011 11:51 PM > > To: Israel Hilerio > > Cc: public-webapps@w3.org > > Subject: Re: [indexeddb] Behavior when calling IDBCursor.continue > > multiple times > > > > I thought it already was in there (or in some bug). But, if not, yeah it > > should > just be documented. > > On Thu, Jun 23, 2011 at 2:32 PM, Israel Hilerio > wrote: > > We noticed that the spec doesn't say anything about what needs to happen > if IDBCursor.continue is called multiple times. We noticed that both FF and > Chrome throw a NOT_ALLOWED_ERR exception. If the exception is not > caught, the cursor doesn't continue to iterate, an error event is triggered > (errorCode = ABORT_ERR), and the transaction is aborted. However, if the > exception is caught, the cursor will iterate normally. This model makes sense > to us. > > > > It seems this is something we should document on the spec. Do you agree? > > > > Israel > > > > > >
[widgets] Interface Implementation report
Hi, Just noting that 4 implementations now pass the widgets interface test suite (and a 5th passes 97%). The implementation report is: http://dev.w3.org/2006/waf/widgets-api/imp-report/ -- Marcos Caceres http://datadriven.com.au
Re: Frame embedding: One problem, three possible specs?
So, looking at this thread, here's what I suggest for the webappsecwg charter: We keep the deliverable in there, but make it very clear that the group should liaise particularly closely with websec "and other IETF work around framing policy" (or some such), explicitly to avoid conflicting or competing specifications. That way, if the vision of complementary specs that Brad describes materializes, we have the necessary charter coverage, but we're very clear that other work is going on and should be respected. If that's ok with everybody, I'll make the tweak before we send this to the membership. -- Thomas Roessler, W3C(@roessler) On Jul 8, 2011, at 01:07 , David Ross wrote: > #3 is a narrowly scoped effort to standardize something that works pretty > well today in practice (X-FRAME-OPTIONS). A conflict with CSP would be bad, > but per Adam it seems like overlap is looking less likely. So proceeding > down the current path on #3 sounds good to me. > > David Ross > dr...@microsoft.com > > > -Original Message- > From: Adam Barth [mailto:w...@adambarth.com] > Sent: Thursday, July 07, 2011 3:24 PM > To: Thomas Roessler > Cc: Tobias Gondrom; Arthur Barstow; Brad Hill; Eric Rescorla; Alexey > Melnikov; David Ross; Anne van Kesteren; Adrian Bateman; Brandon Sterne; > Charles McCathieNevile; Maciej Stachowiak; Peter Saint-Andre; Michael(tm) > Smith; Mark Nottingham; Jeff Hodges; public-web-secur...@w3.org; > public-webapps@w3.org; web...@ietf.org > Subject: Re: Frame embedding: One problem, three possible specs? > > My sense from talking with folks is that there isn't a lot of enthusiasm for > supporting this use case in CSP at the present time. > We're trying to concentrate on a core set of directives for the first > iteration. If it helps reduce complexity, you might consider dropping option > (1) for the time being. > > Adam > > > On Thu, Jul 7, 2011 at 2:11 PM, Thomas Roessler wrote: >> (Warning, this is cross-posted widely. One of the lists is the IETF >> websec mailing list, to which the IETF NOTE WELL applies: >> http://www.ietf.org/about/note-well.html) >> >> >> Folks, >> >> there appear to be at least three possible specifications addressing this >> space, with similar but different designs: >> >> 1. A proposed deliverable in the WebAppSec group to take up on >> X-Frame-Options and express those in CSP: >> http://www.w3.org/2011/07/appsecwg-charter.html >> >> (We expect that this charter might go to the W3C AC for review as soon >> as next week.) >> >> 2. The "From-Origin" draft (aka "Cross-Origin Resource Embedding Exclusion") >> currently considered for publication as an FPWD in the Webapps WG: >> >> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0088.htm >> l >> >> This draft mentions integration into CSP as a possible path forward. >> >> 3. draft-gondrom-frame-options, an individual I-D mentioned to websec: >> https://datatracker.ietf.org/doc/draft-gondrom-frame-options/ >> http://www.ietf.org/mail-archive/web/websec/current/msg00388.html >> >> >> How do we go about it? One path forward might be to just proceed as >> currently planned and coordinate when webappsec starts working. >> >> Another path forward might be to see whether we can agree now on what forum >> to take these things forward in (and what the coordination dance might look >> like). >> >> Thoughts welcome. >> >> Regards, >> -- >> Thomas Roessler, W3C(@roessler) >> >> >> >> > >
Re: [indexeddb] Effects of calling Cursor.Update() on an existing Index
On Tue, Jul 12, 2011 at 11:21 AM, Israel Hilerio wrote:
> Assuming you have the following records in an objectStore objStore:
>
> Record #1: {prop1: 1, prop2: "foo1"}
> Record #2: {prop1: 2, prop2: "foo2"}
> Record #3: {prop1: 3, prop2: "foo3"}
> Record #4: {prop1: 4, prop2: "foo4"}
>
> keyPath = "prop1"
>
> Now, we create an index on "prop2" called index1.
>
> Let's say get a cursor on index1 and we start iterating through it.
> When I get to Record #2, I decide to use the cursor index to call update and
> change prop2 to "foo5":
>
> var rq = objStore.index("index1").openCursor();
> rq.onsuccess = function (evt) {
> var cursor = evt.target.result;
> if (cursor) {
> if (cursor.value.prop1 == "foo2") {
I assume you mean cursor.value.prop2 here, right?
> var rq2 = cursor.update({prop1: 2, prop2: "foo5"});
> }
> cursor.continue();
> }
> };
>
> My question is what is going to happen to the cursor position when the update
> takes place?
>
> Our expectation is that the cursor value will remain unchanged in the client
> code while the database object entry (i.e. record) will change.
> This will produce the following values for cursor.key and cursor.primaryKey
> "foo2" and "2", respectively.
> Thus, we expect the cursor position to remain unchanged and continue() should
> return Record #3.
> Additionally, we expect to see the new Record #2 entry after Record #4.
>
> Do you agree?
Yes, this should be fully defined by the specification using the
cursor's internal "position" and "object store position" state in the
"steps for iterating a cursor".
I definitely agree that it would be nice to have some more readable
informal text that explains this, preferably in the form of a somewhere in the cursor description.
For what it's worth this scenario happens not just through
cursor.update. If you change the cursor.update line in the code
snippet above to
objStore.put({prop1: 2, prop2: "foo5"});
or
objStore.delete(2);
objStore.add({prop1: 2, prop2: "foo5"});
the exact same situation arises, and the exact same behavior is
expected. Similarly, if the code is
objStore.delete(2);
or
cursor.delete();
this has the exact same behavior, except that it obviously doesn't
make the Record #2 appear after Record #4 while iterating.
/ Jonas
Re: [websockets] Getting WebSockets API to Last Call
On Mon, Jul 11, 2011 at 1:15 PM, Ian Hickson wrote: > On Mon, 11 Jul 2011, Jonas Sicking wrote: >> >> >> >> Can you list the reasons for why you don't think we will not need any >> >> of the types listed in the following email: >> >> http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0732.html >> > >> > I addressed those in the e-mail you replied to earlier: >> > >> > http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0237.html >> >> This doesn't contain any arguments for why we wouldn't add any of the >> suggested properties in the future. It just gives solutions for what to >> do if we do need to add them. However all the suggested solutions create >> a more complex platform than if we simply make the second argument an >> object now. > > We wouldn't add timeout to the constructor because there's no benefit to > putting that on the constructor. > > We wouldn't put priority on the constructor because that would be a > per-message feature. You'll likely want a default priority on the socket as to avoid having to specify it on each call. But I guess both timeout and default priority can be set after constructing the WebSocket. However it would be syntactically nice if you can initialize them from the constructor. Oh well, I guess time will tell if we'll end up wanting more constructor arguments. My money is still on that we will. And I had still hoped to hear from other browser vendors. / Jonas
[indexeddb] Effects of calling Cursor.Update() on an existing Index
Assuming you have the following records in an objectStore objStore:
Record #1: {prop1: 1, prop2: "foo1"}
Record #2: {prop1: 2, prop2: "foo2"}
Record #3: {prop1: 3, prop2: "foo3"}
Record #4: {prop1: 4, prop2: "foo4"}
keyPath = "prop1"
Now, we create an index on "prop2" called index1.
Let's say get a cursor on index1 and we start iterating through it.
When I get to Record #2, I decide to use the cursor index to call update and
change prop2 to "foo5":
var rq = objStore.index("index1").openCursor();
rq.onsuccess = function (evt) {
var cursor = evt.target.result;
if (cursor) {
if (cursor.value.prop1 == "foo2") {
var rq2 = cursor.update({prop1: 2, prop2: "foo5"});
}
cursor.continue();
}
};
My question is what is going to happen to the cursor position when the update
takes place?
Our expectation is that the cursor value will remain unchanged in the client
code while the database object entry (i.e. record) will change.
This will produce the following values for cursor.key and cursor.primaryKey
"foo2" and "2", respectively.
Thus, we expect the cursor position to remain unchanged and continue() should
return Record #3.
Additionally, we expect to see the new Record #2 entry after Record #4.
Do you agree?
Israel
RfC: Last Call Working Draft of the API for Media Resources 1.0; deadline August 7
WebApps has been asked to submit comments for the LCWD of the API for Media Resources 1.0 spec: http://www.w3.org/TR/2011/WD-mediaont-api-1.0-20110712/ Individual WG members are encouraged to provide individual feedback directly to the Media Annotations WG. If you have comments, please send them to the following list by August 7: public-media-annotat...@w3.org http://lists.w3.org/Archives/Public/public-media-annotation/ If anyone in WebApps wants to propose an official WG response, please do so ASAP, in reply to this email so the WebApps WG can discuss it. -AB Original Message Subject: Last Call Working Drafts transition announcement of the API for Media Resources 1.0 Date: Tue, 12 Jul 2011 20:00:54 +0200 From: ext Thierry MICHEL Reply-To: To: cha...@w3.org , , , Ivan Herman , , , Doug Schepers , Charles McCathieNevile , 'Chris Lilley' , , , , , , , Thomas Roessler , , , , Michael Cooper , Ralph R. Swick , , , , , , , , PF group , Chairs and Team Contact, (1) This is a 2nd Last Call Working Draft Transition Announcement for the following Recommendation Track specification: (2) Document Title and URI * API for Media Resources 1.0 http://www.w3.org/TR/2011/WD-mediaont-api-1.0-20110712/ (3) Instructions for providing feedback If you wish to make comments regarding this specification please send them to which is an email list publicly archived at http://lists.w3.org/Archives/Public/public-media-annotation/ Please use "[2ndLC Comment API]" in the subject line of your email. (4) Review end date The Last Call period ends on 07 August 2011. (5) A reference to the group's decision to make this Transition The Media Annotations Working Group made the decision for this Transition at its teleconference on July 5th 2011: "Resolution: the wg agrees to move the api doc to 2nd LC" http://www.w3.org/2011/07/05-mediaann-minutes.html (6) Evidence that the document satisfies group's requirements. Include a link to requirements The Media Annotations Working Group believes that these specifications satisfy the requirements of the working group's charter at http://www.w3.org/2008/01/media-annotations-wg.html and the "Use Cases and Requirements for Ontology and API for Media Resource 1.0" at http://www.w3.org/TR/2010/WD-media-annot-reqs-20100121/ (7) The names of groups with dependencies, explicitly inviting review from them. The following groups are known or suspected to have dependencies on this specification: * Semantic Web Deployment Working Group * Semantic Web Coordination Group * Scalable Vector Graphics Working Group (SVG) * Web Applications (WebApps) Working Group * HyperText Markup Language (HTML) Working Group * The Device API and Policy (DAP) Working Group also the following groups have liaisons on one or more of these specifications: * Protocol for Web Description Resources (POWDER) Working Group * Protocols and Formats Working Group The Media Annotations Working Group requests review from each of these working groups. The chairs of the working group listed have been copied on the distribution list of this transition announcement as well as other individuals known to have expressed prior interest. (8) Report of any Formal Objections The Working Group received no Formal Objection during the preparation of this specification. (9) Patent Disclosure Page Link can be found at http://www.w3.org/2004/01/pp-impl/42786/status This Transition Announcement has been prepared according to the guidelines concerning such announcements at http://www.w3.org/2005/08/online_xslt/xslt?xmlfile=http://www.w3.org/2005/08/01-transitions.html&xslfile=http://www.w3.org/2005/08/transitions.xsl&docstatus=lc-wd-tr#trans-annc Regards, Thierry Michel (on behalf of the Media Annotations Working Group chairs) Team Contact for the Media Annotations WG.
Last Call Working Drafts transition announcement of the API for Media Resources 1.0
Chairs and Team Contact, (1) This is a 2nd Last Call Working Draft Transition Announcement for the following Recommendation Track specification: (2) Document Title and URI * API for Media Resources 1.0 http://www.w3.org/TR/2011/WD-mediaont-api-1.0-20110712/ (3) Instructions for providing feedback If you wish to make comments regarding this specification please send them to which is an email list publicly archived at http://lists.w3.org/Archives/Public/public-media-annotation/ Please use "[2ndLC Comment API]" in the subject line of your email. (4) Review end date The Last Call period ends on 07 August 2011. (5) A reference to the group's decision to make this Transition The Media Annotations Working Group made the decision for this Transition at its teleconference on July 5th 2011: "Resolution: the wg agrees to move the api doc to 2nd LC" http://www.w3.org/2011/07/05-mediaann-minutes.html (6) Evidence that the document satisfies group's requirements. Include a link to requirements The Media Annotations Working Group believes that these specifications satisfy the requirements of the working group's charter at http://www.w3.org/2008/01/media-annotations-wg.html and the "Use Cases and Requirements for Ontology and API for Media Resource 1.0" at http://www.w3.org/TR/2010/WD-media-annot-reqs-20100121/ (7) The names of groups with dependencies, explicitly inviting review from them. The following groups are known or suspected to have dependencies on this specification: * Semantic Web Deployment Working Group * Semantic Web Coordination Group * Scalable Vector Graphics Working Group (SVG) * Web Applications (WebApps) Working Group * HyperText Markup Language (HTML) Working Group * The Device API and Policy (DAP) Working Group also the following groups have liaisons on one or more of these specifications: * Protocol for Web Description Resources (POWDER) Working Group * Protocols and Formats Working Group The Media Annotations Working Group requests review from each of these working groups. The chairs of the working group listed have been copied on the distribution list of this transition announcement as well as other individuals known to have expressed prior interest. (8) Report of any Formal Objections The Working Group received no Formal Objection during the preparation of this specification. (9) Patent Disclosure Page Link can be found at http://www.w3.org/2004/01/pp-impl/42786/status This Transition Announcement has been prepared according to the guidelines concerning such announcements at http://www.w3.org/2005/08/online_xslt/xslt?xmlfile=http://www.w3.org/2005/08/01-transitions.html&xslfile=http://www.w3.org/2005/08/transitions.xsl&docstatus=lc-wd-tr#trans-annc Regards, Thierry Michel (on behalf of the Media Annotations Working Group chairs) Team Contact for the Media Annotations WG.
Re: Test suites and RFC2119
On Mon, 11 Jul 2011 19:06:57 +0200, Karl Dubost wrote: Le 11 juil. 2011 à 12:58, Aryeh Gregor a écrit : The standards we're discussing are not coercive. Just a minor semantics point. Web Standards are never coercive. They might be used by legal framework aw as a reference point for a certification process. Actually, the question is important because some standards *are* used by legal frameworks in this way, and even more important because many are used in this way in contracting processes. In both cases this can affect many people's livelihood, so understanding the impacts of what we do is probably worth the effort. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
RfC: Last Call Working Draft of Web IDL; deadline August 23
On July 12 a Last Call Working Draft of Web IDL was published: http://www.w3.org/TR/2011/WD-WebIDL-20110712/ The deadline for comments is August 23 and all comments should be sent to: public-script-co...@w3.org Cameron, Philippe - if you think it is necessary, please fwd this e-mail to ECMA TC39. -AB
Re: Overview of behavior attachment as a general problem on the Web
On Sat, Jul 9, 2011 at 1:42 PM, John J. Barton wrote: [...] > The Behavior Attachment Methods section is also super, but at the end I was > puzzled. I thought the Shadow DOM proposal only allowed one binding, and > thus it would exclude exactly the Decorator pattern we need to compose > multiple frameworks. I understand how you can solve the Dojo or Sencha or > jQuery problem better, but I don't see how you can solve the 'and' version. > IMHO there is a difference between altering the functionality of a component or decorating it. In the first case you need deep knowledge of the component's internas and thus cannot afford a random order in the inheritance chain. OTOH, in the decorator case you are explicitly not interested in internas, and have no control over order of application. I would therefore argue that inheritance (as, e.g., proposed by XBL2) is the wrong vehicle for decoration. For example, what if a decorator omits the element in its tree? It seems to me it should be sufficient to only give a rough outline where the decoration should go, perhaps similar to CSS's ::before and ::after. Conversely, a decoration should _not_ be able to see, or even modify, anything inside the original component, nor use or . Cheers, - Roland
