Re: [FileAPI] FileReader.readAsXXX when pased null
On 7/6/11 10:13 PM, Cameron McCormack wrote: Hi Arun, Adrian Bateman: The spec doesn't seem to state this explicitly and I can't tell if there is supposed to be an implicit requirement from WebIDL. Perhaps the expectation is that this falls into the error condition and should set readyState to DONE, result to null, and process the error steps? Any thoughts? Arun Ranganathan: My thoughts are that this should be an OperationNotAllowedException, and that this should be better defined. IMHO WebIDL doesn't touch on what happens when a method within a given API is called with null, so I think you're right to point this issue out (thanks!). There was a recent change in Web IDL which made interface types (like the readAsXXX argument types) not include null by default, and if you want to allow null, to write it as “Type?”. If you don’t change the type in the File API spec to include the question mark, then Web IDL defines it so that passing null means a TypeError will be thrown. If you want to do some additional processing beyond throwing an exception (e.g. setting readyState), then you would need to allow null by using “Blob?” as the type and then say what happens when null is passed in. Wow, not only do I stand corrected, but I'm also gladdened :) This change to WebIDL is a good one, and I'm sorry I missed it when it came out. Adrian: this should answer your original question, although I still think that in general, user agents differ pretty substantially over the type of exceptions that are being thrown (and this is yet another example). Hopefully this is something we can fix with updates. -- A*
Re: Mutation events replacement
On 7/7/2011 6:38 PM, Jonas Sicking wrote: On Thu, Jul 7, 2011 at 5:23 PM, Rafael Weinstein wrote: So yes, my proposal only solves the usecase outside mutation handlers. However this is arguably better than never solving the use case as in your proposal. I'm sure people will end up writing buggy code, but ideally this will be found and fixed fairly easily as the behavior is consistent. We are at least giving people the tools needed to implement the synchronous behavior. Ok. Thanks for clarifying. It's helpful to understand this. I'm glad there's mostly common ground on the larger issue. The point of contention is clearly whether accommodating some form of sync mutation actions is a goal or non-goal. Yup, that seems to be the case. I think the main reason I'm arguing for allowing synchronous callbacks is that I'm concerned that without them people are going to stick to mutation events. If I was designing this feature from scratch, I'd be much happier to use some sort of async callback. However given that we need something that people can migrate to, and we don't really know what they're using mutation events for, I'm more conservative. / Jonas Hmm... you don't believe the use cases and info on how mutation events are being used that Dave and I have posted and you don't have any alternatives. Perhaps the conservative solution is do nothing. You might ask Prof. Jan Vitek if his infrastructure can give you any information on mutation event uses. He may also other ways to get such answers. jjb jjb
Re: [indexeddb] Calling update on a cursor index with a unique value constraint
On Thu, Jul 7, 2011 at 6:35 PM, Israel Hilerio wrote: > On Thursday, July 07, 2011 1:46 PM, Jonas Sicking wrote: >> On Wed, Jul 6, 2011 at 9:41 PM, Jeremy Orlow >> wrote: >> > On Wed, Jul 6, 2011 at 10:06 AM, Israel Hilerio >> > >> >> We believe an error should be thrown because of the violation of the >> >> unique value index constraint and the error code should be set to >> >> CONSTRAINT_ERR. What do you think? >> > >> > IIRC, we decided update should essentially be an alias to delete and >> > then an add on the parent object store--probably an atomic one. So by >> > that logic it does seem to me CONSTRAINT_ERR would be the right error. >> >> Hmm.. it's not exactly a delete and a add since if the add produces an error >> but the error handler calls .preventDefault, you don't want only the delete >> to >> be executed. >> >> I'd rather say that a .update is the same as a .put. >> >> > Btw, ObjectStore.add()'s exception section doesn't mention >> > CONSTRAINT_ERR though it probably should. >> >> IDBObjectStore.add never throws CONSTRAINT_ERR since that's detected >> asynchronously, so the spec seems fine here. However >> IDBObjectStoreSync.add and IDBObjectStoreSync.put should and does list it as >> an exception. >> >> / Jonas > > Attached is the sample page you requested. The sample creates a unique index > on the property "foo" and updates a record with a duplicate value for "foo". > In FF, I was able to update the entry with a duplicate value for "foo". I > agree with you that we should generate an error event with a .code set to > CONSTRAIN_ERR if there is a collision when calling .update. Thanks! > Also agree that we should update the IDBObjectStoreSync.add and > IDBObjectStoreSync.put to include CONSTRAINT_ERR as part of its exception > list. See the "and does" part above. It's already there :) / Jonas
Re: Mutation events replacement
On Thu, Jul 7, 2011 at 5:23 PM, Rafael Weinstein wrote: >> So yes, my proposal only solves the usecase outside mutation handlers. >> However this is arguably better than never solving the use case as in >> your proposal. I'm sure people will end up writing buggy code, but >> ideally this will be found and fixed fairly easily as the behavior is >> consistent. We are at least giving people the tools needed to >> implement the synchronous behavior. > > Ok. Thanks for clarifying. It's helpful to understand this. > > I'm glad there's mostly common ground on the larger issue. The point > of contention is clearly whether accommodating some form of sync > mutation actions is a goal or non-goal. Yup, that seems to be the case. I think the main reason I'm arguing for allowing synchronous callbacks is that I'm concerned that without them people are going to stick to mutation events. If I was designing this feature from scratch, I'd be much happier to use some sort of async callback. However given that we need something that people can migrate to, and we don't really know what they're using mutation events for, I'm more conservative. / Jonas
RE: [indexeddb] Calling update on a cursor index with a unique value constraint
On Thursday, July 07, 2011 1:46 PM, Jonas Sicking wrote: > On Wed, Jul 6, 2011 at 9:41 PM, Jeremy Orlow > wrote: > > On Wed, Jul 6, 2011 at 10:06 AM, Israel Hilerio > > > >> We believe an error should be thrown because of the violation of the > >> unique value index constraint and the error code should be set to > >> CONSTRAINT_ERR. What do you think? > > > > IIRC, we decided update should essentially be an alias to delete and > > then an add on the parent object store--probably an atomic one. So by > > that logic it does seem to me CONSTRAINT_ERR would be the right error. > > Hmm.. it's not exactly a delete and a add since if the add produces an error > but the error handler calls .preventDefault, you don't want only the delete to > be executed. > > I'd rather say that a .update is the same as a .put. > > > Btw, ObjectStore.add()'s exception section doesn't mention > > CONSTRAINT_ERR though it probably should. > > IDBObjectStore.add never throws CONSTRAINT_ERR since that's detected > asynchronously, so the spec seems fine here. However > IDBObjectStoreSync.add and IDBObjectStoreSync.put should and does list it as > an exception. > > / Jonas Attached is the sample page you requested. The sample creates a unique index on the property "foo" and updates a record with a duplicate value for "foo". In FF, I was able to update the entry with a duplicate value for "foo". I agree with you that we should generate an error event with a .code set to CONSTRAIN_ERR if there is a collision when calling .update. Also agree that we should update the IDBObjectStoreSync.add and IDBObjectStoreSync.put to include CONSTRAINT_ERR as part of its exception list. Israel <<< text/html; name="cursor_update_unique.htm": Unrecognized >>>
Re: [indexeddb] openCursor optional parameters issue
On Thu, Jul 7, 2011 at 5:24 PM, Eliot Graff wrote: > Done and pushed to Mercurial. > > Updated sync and async versions of openCursor on ObjectStore and Index as > follows: > made type of 'range' equal to any > made 'range' nullable I think you missed updating one of the cursor opening functions on IDBIndex (there's both openCursor and openKeyCursor). Also, it would be great if you could update overview.html every time you update a speclet as to make it easier to review by simply looking at the specification. / Jonas
RE: [indexeddb] openCursor optional parameters issue
Done and pushed to Mercurial.
Updated sync and async versions of openCursor on ObjectStore and Index as
follows:
made type of 'range' equal to any
made 'range' nullable
Eliot
> -Original Message-
> From: public-webapps-requ...@w3.org [mailto:public-webapps-
> requ...@w3.org] On Behalf Of Jonas Sicking
> Sent: Thursday, June 30, 2011 2:30 PM
> To: Israel Hilerio
> Cc: public-webapps@w3.org; Adam Herchenroether; Victor Ngo
> Subject: Re: [indexeddb] openCursor optional parameters issue
>
> On Thu, Jun 30, 2011 at 1:19 PM, Israel Hilerio
> wrote:
> > On Tuesday, June 28, 2011 7:31 PM, Jonas Sicking wrote:
> >> On Tue, Jun 28, 2011 at 4:59 PM, Israel Hilerio
> >>
> >> wrote:
> >> > On Tuesday, June 28, 2011 12:49 PM, Jonas Sicking wrote:
> >> >> On Tue, Jun 28, 2011 at 10:53 AM, Israel Hilerio
> >> >>
> >> >> wrote:
> >> >> > On Monday, June 27, 2011 8:21 PM, Jonas Sicking wrote:
> >> >> >> On Mon, Jun 27, 2011 at 11:42 AM, Israel Hilerio
> >> >> >>
> >> >> >> wrote:
> >> >> >> > The IDBObjectStore.openCursor method is defined to have two
> >> >> >> > optional
> >> >> >> parameters:
> >> >> >> > * IDBRequest openCursor (in optional any range, in optional
> >> >> >> > unsigned short direction) raises (IDBDatabaseException);
> >> >> >> >
> >> >> >> > Based on the examples in the spec, it seems we're envisioning
> >> >> >> > the method
> >> >> >> to be used in the following ways:
> >> >> >> > * objStore.openCursor();
> >> >> >> > * objStore.openCursor(keyRange);
> >> >> >> > * objStore.openCursor(keyRange, IDBCursor.PREV);
> >> >> >> > * objStore.openCursor(IDBCursor.PREV);
> >> >> >>
> >> >> >> No, that's not how optional parameters work in WebIDL. In order
> >> >> >> to specify an optional parameter, you always have to specify
> >> >> >> all preceding optional parameters. So only the following
> >> >> >> syntaxes are
> >> >> >> valid:
> >> >> >>
> >> >> >> * objStore.openCursor();
> >> >> >> * objStore.openCursor(keyRange);
> >> >> >> * objStore.openCursor(keyRange, IDBCursor.PREV);
> >> >> >>
> >> >> >> > Having "any" for the keyRange type makes it difficult to
> >> >> >> > detect the correct
> >> >> >> overloaded parameter for openCursor.
> >> >> >>
> >> >> >> The reason the first parameter is of type 'any' is so that you
> >> >> >> can pass either a IDBKeyRange or a value. So for example:
> >> >> >>
> >> >> >> req = objStore.openCursor("hello"); req = index.openCursor(4);
> >> >> >>
> >> >> >> are valid. When called with a simple value on an object store
> >> >> >> the cursor will obviously always return 0 or 1 rows. For
> >> >> >> indexes it could return any number of rows though.
> >> >> >>
> >> >> >> This is actually already specified if you look at the steps for
> >> >> >> opening a
> >> >> cursor.
> >> >> >> The same holds true for many other functions, such as .get and
> .delete.
> >> >> >>
> >> >> >> However it's a very subtle feature that's easy to miss. If you
> >> >> >> have suggestions for how to make this more clear in the spec
> >> >> >> I'd love to hear them. I've been thinking that we should add
> >> >> >> non-normative, easy-to-understand text to explain each
> >> >> >> function, similar to what the
> >> >> >> HTML5 spec does when defining APIs.
> >> >> >>
> >> >> >> / Jonas
> >> >> >
> >> >> > What you're saying makes a lot of sense. That was what I
> >> >> > originally thought
> >> >> but what confused me was some of the examples in the current spec
> >> >> which suggest we want to do the following (Section 3.3.5):
> >> >> > * objStore.openCursor(IDBCursor.PREV);
> >> >>
> >> >> I don't think we should allow this. The benefit of saving the
> >> >> author from writing objStore.openCursor(nulll, IDBCursor.PREV)
> >> >> isn't worth the complexity that is introduced. IMHO. We should
> >> >> just fix the example
> >> instead.
> >> >>
> >> >> > Independent of how up to date the examples are, the issue with
> >> >> > the way it is
> >> >> currently spec'ed is that there is an implied dependency between
> >> >> keyRange and Cursor direction. In other words, you can't open a
> >> >> cursor without any keyRange and just a direction. One possible
> >> >> way to resolve this is to allow the keyRange to be nullable. This
> >> >> will allow us to define a cursor without a keyRange and with a
> >> >> direction:
> >> >> > * objStore.openCursor(null, IDBCursor.PREV);
> >> >> >
> >> >> > Without something like this, it is not easy to get a list of all
> >> >> > the records on
> >> >> the store going in the opposite direction from IDBCursor.NEXT.
> >> >>
> >> >> Indeed, it was the intent that this should be allowed. I suspect
> >> >> we simply haven't kept up to date with WebIDL changing under us.
> >> >> But I do think that the text in the algorithm does say to do the
> >> >> right thing when no keyrange (or key
> >> >> value) is supplied.
> >> >>
> >> >> / Jonas
> >> >
> >> > My concern is not having a clean mechanism to retrieve a regular
> >> > cursor
> >> with an inverted order with
Re: Mutation events replacement
On Thu, Jul 7, 2011 at 3:19 PM, Jonas Sicking wrote: > On Thu, Jul 7, 2011 at 2:32 PM, Rafael Weinstein wrote: >> On Thu, Jul 7, 2011 at 1:58 PM, Ryosuke Niwa wrote: >>> On Thu, Jul 7, 2011 at 12:18 PM, Jonas Sicking wrote: I don't think John J Barton's proposal to fire "before mutation notifications" is doable. >>> >>> I concur. Being synchronous was one of the reasons why the existing DOM >>> mutation events don't work. We shouldn't adding yet-another synchronous >>> event here. In short before spending more time on this, I'd like to see a comprehensive proposal, including a description of the use cases it solves and how it solves them. I strongly doubt that this approach is practical. >>> >>> Totally agreed. I really like Rafael's proposal to pass a list of mutations that has happened to the notification callbacks. This has the advantage that scripts get *all* the changes that has happened at once, making it possible to make decisions based on all changes made, rather than piece-wise getting the information in separate callbacks. It also has the advantage that we can provide much more detailed information without having to make multiple calls from C++ to JS which is good for performance. For example it seems very doable to provide lists of all nodes that has been removed and added while still keeping performance reasonable. >>> >>> Enthusiastically agreed. I'll write up a proposal based on this idea. Others should feel free to beat me to it :) >>> >>> Nice! Looking forward to it. The main concern that I have with this proposal is that it's so different from mutation events that it might not satisfy the same use cases. Consider a widget implementation that currently observes the DOM using mutation events and makes it possible to write code like: myWidgetBackedElement.appendChild(someNode); myWidgetBackedElement.someFunction(); where someFunction depends on state which is updated by the mutation event handler. Such a widget implementation is simply not doable with these semi-asynchronous callbacks. >>> >>> Right. But on the other hand, if this code were to run inside a mutation >>> observer, it won't work in your proposal either. So the questions is >>> whether writing a function that depends on state updated by the mutation >>> observer without a mutation observer, and then later calling it inside a >>> mutation observer happens frequently enough to annoy developers or not. On the other hand, maybe this isn't a big deal. We are definitely short on use cases for mutation events in general which is a problem. >> >> Right. Olli & Jonas, I'd really like to understand your thinking about this. >> >> Are we not understanding something about your proposal? >> >> If accommodating the above is a goal, it seems like the only option is >> to have mutation events be fully synchronous. I.e. It doesn't seem >> acceptable to encourage a widget author to expose an API that depends >> on never being called inside a mutation callback and/or prevents it >> from being used as a building block for a higher-level abstraction. > > It's definitely the case that APIs will behave differently inside the > mutation notification, and that the code example showed above would > not work from inside the notification. > > Basically I'm asking people to tread carefully inside mutation > notifications and only do the minimal amount of data gathering. Heh. We're kind of in violent agreement here. =-) > > So yes, my proposal only solves the usecase outside mutation handlers. > However this is arguably better than never solving the use case as in > your proposal. I'm sure people will end up writing buggy code, but > ideally this will be found and fixed fairly easily as the behavior is > consistent. We are at least giving people the tools needed to > implement the synchronous behavior. Ok. Thanks for clarifying. It's helpful to understand this. I'm glad there's mostly common ground on the larger issue. The point of contention is clearly whether accommodating some form of sync mutation actions is a goal or non-goal. It occurs to me that the main use case raised in favor of sync mutation actions is more or less the custom component/widget use case. This seems to border alot on XBL2. Maybe it's useful to look at it through that lens? /me grabs blindly at the air for good ideas about how to come to consensus. > > / Jonas >
Re: Mutation events replacement
Olli Pettay wrote: On 07/08/2011 01:43 AM, John J Barton wrote: Rafael Weinstein wrote: On Thu, Jul 7, 2011 at 1:58 PM, Ryosuke Niwa wrote: On Thu, Jul 7, 2011 at 12:18 PM, Jonas Sicking wrote: I don't think John J Barton's proposal to fire "before mutation notifications" is doable. I concur. Being synchronous was one of the reasons why the existing DOM mutation events don't work. We shouldn't adding yet-another synchronous event here. However, my proposal need not be synchronous in the sense that is important here: 'before' mutation listeners need not able to mutate, only cancel. So it's not yet another synchronous event. Developers would use their handler to build a new mutation event and fire it on the next turn: it' s essentially asynchronous. In short before spending more time on this, I'd like to see a comprehensive proposal, including a description of the use cases it solves and how it solves them. I strongly doubt that this approach is practical. There are lots of reasons why 'before' events may not be practical, including lack of enthusiasm on the part of the implementors. You folks are the experts, I'm just trying to contribute another point of view. Thus I want to point out that for the critical issue of preventing mutation listeners from mutating, all you have to do to Jonas' algorithm is prepend: 0. If notifyingCallbacks is set to true, throw MutationNotAllowedInBeforeMutationCallbacks. I don't understand how this could really work. Just as an example: What if the mutation listener spins event loop which ends up touching parser so that it tries to insert new content to the document. I would like to learn what you mean here. The only way I know how to suspend an event and spin a new one is via the debugger API. Is that the case you are concerned with? That mutation wouldn't be allowed. What should be done to that data which the parser can't add to the document? Discard, same as any exception, not a special case. jjb You don't have to to any thing to create a read-only DOM API because you already track all possible DOM modifications. The clean-up from the throw is similar to the cancel and not different from any other clean-up you have to do if the mutation listener fails. This is of course not a comprehensive proposal. I'm perfectly fine if you choose not to respond because you want to close off this discussion and I thank you for the replies so far. jjb
RE: Frame embedding: One problem, three possible specs?
The latest draft of the WebAppSec charter includes a secure cross-domain framing mechanism as a distinct deliverable from the CSP, it's relation is only in proposing re-use of same browsing context capability grammar as CSP. So retaining option #1 is not in conflict with dropping frame-ancestors from CSP v1. #2 and #3 (and frame-ancestors in the current CSP draft) allow expression of similar policies: "This content can only be framed/embedded by these origins." I think it makes sense to consolidate these going forward. #1 in the new WebAppSec WG draft charter is different. While there isn't a strawman yet, it seeks to allow expression of a policy like: "Anyone can frame this content, but it must allow X, Y and Z." or maybe, "This frame is non-interactive unless X, Y and Z." (where X, Y and Z might be: an unobstructed canvas, allowed to execute script, allowed to top-nav, top z-order, minimum display size, etc...) I think both approaches can co-exist and that #1 can proceed without conflict for now. If the proposal that emerges is determined to be best transported as additional semantics for X-Frame-Options or From-Origin, the WebAppSec WG is already chartered to do the necessary coordination. -Brad -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; Hill, Brad; 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; Hodges, Jeff; 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: Mutation events replacement
On Thu, Jul 7, 2011 at 3:43 PM, John J Barton wrote: In short before spending more time on this, I'd like to see a comprehensive proposal, including a description of the use cases it solves and how it solves them. I strongly doubt that this approach is practical. > > There are lots of reasons why 'before' events may not be practical, > including lack of enthusiasm on the part of the implementors. You folks are > the experts, I'm just trying to contribute another point of view. Thus I > want to point out that for the critical issue of preventing mutation > listeners from mutating, all you have to do to Jonas' algorithm is prepend: > > 0. If notifyingCallbacks is set to true, throw > MutationNotAllowedInBeforeMutationCallbacks. > > You don't have to to any thing to create a read-only DOM API because you > already track all possible DOM modifications. The clean-up from the throw > is similar to the cancel and not different from any other clean-up you have > to do if the mutation listener fails. > This is of course not a comprehensive proposal. I'm perfectly fine if you > choose not to respond because you want to close off this discussion and I > thank you for the replies so far. This is more comprehensive than anything else so far ;-) Unfortunately being able to mutate the DOM itself isn't enough. We also need to prevent a whole host of other things, such as performing synchronous XHR, navigating a document, calling alert() or showModalDialog(), likely setting document.domain, setting scroll positions etc. The list will be long and implementation dependent. This is because all these things can indirectly mutate the DOM. So more comprehensive is still needed. And unfortunately you'd likely need to do research into each browser implementation and see what invariants they depend on and which APIs can change those invariants. This is extra hard given that there are at least two non-open-source implementations out there. / Jonas
RE: [websockets] Getting WebSockets API to Last Call
On Thursday, July 07, 2011 3:55 PM, Jonas Sicking wrote: On Thu, Jul 7, 2011 at 3:00 PM, Adrian Bateman wrote: > > 12917 - "deflate-stream" should be an optional extension when establishing > > a connection > > Resolved, WontFix > > MICROSOFT PROPOSAL: We strongly disagree with the API spec overruling the > > protocol spec > > on what is optional in the protocol. The API spec should not normatively > > mention specific > > extensions. References to "deflate-stream" should be informative and only > > provided as examples. > > I agree with the WONTFIX here. I think optional parts of > specifications is a bad thing in the web space and bad for > interoperability. If we really end up needing the ability to set > optional parts we can always add that in the future. I agree with the general principle of not adding optional features. However, I think this case is different for a couple of reasons: 1) This is optional in the protocol spec. If you don't think it should be optional in the protocol that argument should be made in the IETF working group. I don't agree that the W3C API should override the discussions in the protocol working group just because some people don't like the outcome. 2) This feature is an extension point. Its sole purpose is to support optional features. Mandating one example of an extension seems arbitrary to me. As soon as there is another extension there will still be differences. We believe that there will be legitimate implementations that don't want to support deflate-stream and servers will have to support with and without to be conforming anyway. > > 13178 - binaryType should be immutable after connection is established > > Open, Assigned to Ian Hickson > > MICROSOFT PROPOSAL: We'd like to see the spec updated as outlined in this > > bug. > > I don't agree with making binaryType immutable, and I added a comment > to that effect to the bug. I did also put in another proposal in the > bug which also aims to reduce implementation complexity and improve > performance. Thanks for the feedback on this one. It would be good to get a sense from other implementers about how there feel here. Cheers, Adrian.
Re: Mutation events replacement
On 07/08/2011 01:43 AM, John J Barton wrote: Rafael Weinstein wrote: On Thu, Jul 7, 2011 at 1:58 PM, Ryosuke Niwa wrote: On Thu, Jul 7, 2011 at 12:18 PM, Jonas Sicking wrote: I don't think John J Barton's proposal to fire "before mutation notifications" is doable. I concur. Being synchronous was one of the reasons why the existing DOM mutation events don't work. We shouldn't adding yet-another synchronous event here. However, my proposal need not be synchronous in the sense that is important here: 'before' mutation listeners need not able to mutate, only cancel. So it's not yet another synchronous event. Developers would use their handler to build a new mutation event and fire it on the next turn: it' s essentially asynchronous. In short before spending more time on this, I'd like to see a comprehensive proposal, including a description of the use cases it solves and how it solves them. I strongly doubt that this approach is practical. There are lots of reasons why 'before' events may not be practical, including lack of enthusiasm on the part of the implementors. You folks are the experts, I'm just trying to contribute another point of view. Thus I want to point out that for the critical issue of preventing mutation listeners from mutating, all you have to do to Jonas' algorithm is prepend: 0. If notifyingCallbacks is set to true, throw MutationNotAllowedInBeforeMutationCallbacks. I don't understand how this could really work. Just as an example: What if the mutation listener spins event loop which ends up touching parser so that it tries to insert new content to the document. That mutation wouldn't be allowed. What should be done to that data which the parser can't add to the document? You don't have to to any thing to create a read-only DOM API because you already track all possible DOM modifications. The clean-up from the throw is similar to the cancel and not different from any other clean-up you have to do if the mutation listener fails. This is of course not a comprehensive proposal. I'm perfectly fine if you choose not to respond because you want to close off this discussion and I thank you for the replies so far. jjb
Re: [websockets] Getting WebSockets API to Last Call
On Thu, Jul 7, 2011 at 3:00 PM, Adrian Bateman wrote: > We're keen to resolve the remaining issues with the WebSockets API and have a > timetable > to get to Candidate Recommendation. From informal conversations we've had, we > believe > other browser vendors share this goal. I think the current WebSocket API is > feature > complete and meets the requirements for publishing a Last Call working draft > to > encourage wider review and feedback. There are no tracker issues for > WebSockets. Here > is my analysis of the outstanding bugs (not closed, where resolution not > Fixed). > I believe the outstanding issues could be resolved as Last Call comments and > would like > to see a CfC to publish a LCWD shortly. Yes, we'd like to see this happen very soon too as we'd like to unprefix our implementation. > 9973 - If the entry's name is "sec-websocket-protocol" 0 please don't put > normative > requirements in parenthesis > Resolved, NeedsInfo > MICROSOFT PROPOSAL: close the bug - this bug is a year old, likely out of > date now, and > from an anonymous contributor Sounds good. > 10213 - The definition of "absolute url" makes https:foo not an absolute url > Open, Assigned to Adam Barth > MICROSOFT PROPOSAL: Section 3 of the protocol spec > (http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-09#section-3) > shows the > valid syntax for a ws-URI. We believe the API should throw a SYNTAX_ERR if > the address > supplied does not match this format. I don't have an opinion on url parsing since I don't know enough about it. However throwing an exception on an invalid URI sounds good to me. > 12180 - give the name of url to download the Jetty server > Resolved, NeedsInfo - this bug is from an anonymous contributor from 4 months > ago > MICROSOFT PROPOSAL: close the bug - the API spec doesn't need to link to > server implementations Agreed. > 12510 - Specs split off from HTML5 (like WebSockets) need to have xrefs > linked, otherwise > they're ambiguous > Reopened, Assigned to Ian Hickson > MICROSOFT PROPOSAL: this is an editorial bug that should not block Last Call Agreed. > 12816 - Make second argument in constructor an object for future extensibility > Resolved, WontFix > MICROSOFT PROPOSAL: We think the second argument should be an object, not > only for future > extensibility but to allow binaryType to be set now. I'd like to see this change made too. So far there's been two counter proposals in the bug for how to deal with future extensions (which I strongly suspect we'll end up having to do in the future): 1. Wait to open the connection until returning to the event loop which delays starting the already slow network handshake. This is especially a problem in Web Workers where returning to the event loop can take a very long time. 2. Make the second argument either be a string, a array of strings, or a object. This is messy both from a user perspective and from an implementation perspective. Do any implementations prefer the current specced behavior? Otherwise I'll push for making this change in firefox. > 12917 - "deflate-stream" should be an optional extension when establishing a > connection > Resolved, WontFix > MICROSOFT PROPOSAL: We strongly disagree with the API spec overruling the > protocol spec > on what is optional in the protocol. The API spec should not normatively > mention specific > extensions. References to "deflate-stream" should be informative and only > provided as examples. I agree with the WONTFIX here. I think optional parts of specifications is a bad thing in the web space and bad for interoperability. If we really end up needing the ability to set optional parts we can always add that in the future. > 13104 - 1) ping(msg); //allow client to send server ping as per websocket > spec 2) onpong(); > //allow client to receive response of ping > Open, Assigned to Ian Hickson > MICROSOFT PROPOSAL: We don't think this is necessary. Agreed. If needed we can always add this in the future. > 13162 - The notes really do need to be cleaned up to be made explicit. > Open, Assigned to Ian Hickson > MICROSOFT PROPOSAL: This is an editorial bug and should not block Last Call Agreed. > 13178 - binaryType should be immutable after connection is established > Open, Assigned to Ian Hickson > MICROSOFT PROPOSAL: We'd like to see the spec updated as outlined in this bug. I don't agree with making binaryType immutable, and I added a comment to that effect to the bug. I did also put in another proposal in the bug which also aims to reduce implementation complexity and improve performance. > 13180 - [Editorial] Causes that lead to failing the WebSocket connection, > which results > in an error event, should be more clearly specified > Open, Assigned to Ian Hickson > MICROSOFT PROPOSAL: This is an editorial issue and should not block Last Call. Agreed. / Jonas
Re: Mutation events replacement
On Thu, Jul 7, 2011 at 3:43 PM, John J Barton wrote: > > On Thu, Jul 7, 2011 at 1:58 PM, Ryosuke Niwa wrote: >> >> >>> On Thu, Jul 7, 2011 at 12:18 PM, Jonas Sicking wrote: >>> >>> I don't think John J Barton's proposal to fire "before mutation notifications" is doable. >>> I concur. Being synchronous was one of the reasons why the existing DOM >>> mutation events don't work. We shouldn't adding yet-another synchronous >>> event here. >>> >>> >> However, my proposal need not be synchronous in the sense that is > important here: 'before' mutation listeners need not able to mutate, only > cancel. So it's not yet another synchronous event. Developers would use > their handler to build a new mutation event and fire it on the next turn: > it' s essentially asynchronous. Being able to cancel is dangerous enough for me. There are lots of reasons why 'before' events may not be practical, > including lack of enthusiasm on the part of the implementors. You folks are > the experts, I'm just trying to contribute another point of view. Thus I > want to point out that for the critical issue of preventing mutation > listeners from mutating, all you have to do to Jonas' algorithm is prepend: > > 0. If notifyingCallbacks is set to true, throw > MutationNotAllowedInBeforeMuta**tionCallbacks. Implementing this feature is excessively hard and time-consuming for many implementors as far as I know. - Ryosuke
Re: Mutation events replacement
On 7/7/11 6:28 PM, Jonas Sicking wrote: In gecko you can for example use the nsIMutationObserver notification to implement this. Maybe you can, and maybe not. Those fire at "unsafe" times and are limited in what you can do from them. Arbitrary debugging doesn't fit the bill. But yes, in general debuggers can use internal APIs with higher trust in the callee as needed. The question is whether they can work within the resulting constraints. -Boris
Re: Mutation events replacement
Rafael Weinstein wrote: On Thu, Jul 7, 2011 at 1:58 PM, Ryosuke Niwa wrote: On Thu, Jul 7, 2011 at 12:18 PM, Jonas Sicking wrote: I don't think John J Barton's proposal to fire "before mutation notifications" is doable. I concur. Being synchronous was one of the reasons why the existing DOM mutation events don't work. We shouldn't adding yet-another synchronous event here. However, my proposal need not be synchronous in the sense that is important here: 'before' mutation listeners need not able to mutate, only cancel. So it's not yet another synchronous event. Developers would use their handler to build a new mutation event and fire it on the next turn: it' s essentially asynchronous. In short before spending more time on this, I'd like to see a comprehensive proposal, including a description of the use cases it solves and how it solves them. I strongly doubt that this approach is practical. There are lots of reasons why 'before' events may not be practical, including lack of enthusiasm on the part of the implementors. You folks are the experts, I'm just trying to contribute another point of view. Thus I want to point out that for the critical issue of preventing mutation listeners from mutating, all you have to do to Jonas' algorithm is prepend: 0. If notifyingCallbacks is set to true, throw MutationNotAllowedInBeforeMutationCallbacks. You don't have to to any thing to create a read-only DOM API because you already track all possible DOM modifications. The clean-up from the throw is similar to the cancel and not different from any other clean-up you have to do if the mutation listener fails. This is of course not a comprehensive proposal. I'm perfectly fine if you choose not to respond because you want to close off this discussion and I thank you for the replies so far. jjb
Re: Mutation events replacement
On Thu, Jul 7, 2011 at 3:21 PM, John J Barton wrote: > Jonas Sicking wrote: >> >> We are definitely >> short on use cases for mutation events in general which is a problem. >> > > 1. Graphical breakpoints. The user marks some DOM element or attribute to > trigger break. The debugger inserts mutation listeners to watch for the > event that causes that element/attribute to be created/modified. Then the > debugger re-executes some code sequence and halts when the appropriate > listener is entered. Placing the listeners high in the tree and analyzing > all of the events is easier than trying to precisely add a listener since > the tree will be modified during re-execution. Debuggers can use internal APIs and doesn't need to be limited to using APIs exposed to web pages. In fact, in this case you probably want to use an internal API anyway as to ensure that the debugger steps in before any other of the mutation listeners have executed. In gecko you can for example use the nsIMutationObserver notification to implement this. > 2. Graphical tracing. Recording all or part of the DOM creation. For > visualization or analysis tools. See for example Firebug's HTML panel with > options Highlight Changes, Expand Changes, or Scroll Changes into View. See above. > 3. Client side dynamic translation. Intercept mutations and replace or > extend them. This could be for user tools like scriptish or stylish, dev > tools to inject marks or code, or for re-engineering complex sites for newer > browser features. I don't fully understand this. Can you give more concrete examples? / Jonas
RE: [indexeddb] Behavior when calling IDBCursor.continue multiple times
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
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.html > > 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: Mutation events replacement
Jonas Sicking wrote: We are definitely short on use cases for mutation events in general which is a problem. 1. Graphical breakpoints. The user marks some DOM element or attribute to trigger break. The debugger inserts mutation listeners to watch for the event that causes that element/attribute to be created/modified. Then the debugger re-executes some code sequence and halts when the appropriate listener is entered. Placing the listeners high in the tree and analyzing all of the events is easier than trying to precisely add a listener since the tree will be modified during re-execution. 2. Graphical tracing. Recording all or part of the DOM creation. For visualization or analysis tools. See for example Firebug's HTML panel with options Highlight Changes, Expand Changes, or Scroll Changes into View. 3. Client side dynamic translation. Intercept mutations and replace or extend them. This could be for user tools like scriptish or stylish, dev tools to inject marks or code, or for re-engineering complex sites for newer browser features. jjb
Re: Mutation events replacement
On Thu, Jul 7, 2011 at 2:32 PM, Rafael Weinstein wrote: > On Thu, Jul 7, 2011 at 1:58 PM, Ryosuke Niwa wrote: >> On Thu, Jul 7, 2011 at 12:18 PM, Jonas Sicking wrote: >>> >>> I don't think John J Barton's proposal to fire "before mutation >>> notifications" is doable. >> >> I concur. Being synchronous was one of the reasons why the existing DOM >> mutation events don't work. We shouldn't adding yet-another synchronous >> event here. >>> >>> In short before spending more time on this, I'd like to see a >>> comprehensive proposal, including a description of the use cases it >>> solves and how it solves them. I strongly doubt that this approach is >>> practical. >> >> Totally agreed. >>> >>> I really like Rafael's proposal to pass a list of mutations that has >>> happened to the notification callbacks. This has the advantage that >>> scripts get *all* the changes that has happened at once, making it >>> possible to make decisions based on all changes made, rather than >>> piece-wise getting the information in separate callbacks. It also has >>> the advantage that we can provide much more detailed information >>> without having to make multiple calls from C++ to JS which is good for >>> performance. For example it seems very doable to provide lists of all >>> nodes that has been removed and added while still keeping performance >>> reasonable. >> >> Enthusiastically agreed. >>> >>> I'll write up a proposal based on this idea. Others should feel free >>> to beat me to it :) >> >> Nice! Looking forward to it. >>> >>> The main concern that I have with this proposal is that it's so >>> different from mutation events that it might not satisfy the same use >>> cases. Consider a widget implementation that currently observes the >>> DOM using mutation events and makes it possible to write code like: >>> >>> myWidgetBackedElement.appendChild(someNode); >>> myWidgetBackedElement.someFunction(); >>> >>> where someFunction depends on state which is updated by the mutation >>> event handler. Such a widget implementation is simply not doable with >>> these semi-asynchronous callbacks. >> >> Right. But on the other hand, if this code were to run inside a mutation >> observer, it won't work in your proposal either. So the questions is >> whether writing a function that depends on state updated by the mutation >> observer without a mutation observer, and then later calling it inside a >> mutation observer happens frequently enough to annoy developers or not. >>> >>> On the other hand, maybe this isn't a big deal. We are definitely >>> short on use cases for mutation events in general which is a problem. > > Right. Olli & Jonas, I'd really like to understand your thinking about this. > > Are we not understanding something about your proposal? > > If accommodating the above is a goal, it seems like the only option is > to have mutation events be fully synchronous. I.e. It doesn't seem > acceptable to encourage a widget author to expose an API that depends > on never being called inside a mutation callback and/or prevents it > from being used as a building block for a higher-level abstraction. It's definitely the case that APIs will behave differently inside the mutation notification, and that the code example showed above would not work from inside the notification. Basically I'm asking people to tread carefully inside mutation notifications and only do the minimal amount of data gathering. So yes, my proposal only solves the usecase outside mutation handlers. However this is arguably better than never solving the use case as in your proposal. I'm sure people will end up writing buggy code, but ideally this will be found and fixed fairly easily as the behavior is consistent. We are at least giving people the tools needed to implement the synchronous behavior. / Jonas
[websockets] Getting WebSockets API to Last Call
We're keen to resolve the remaining issues with the WebSockets API and have a timetable to get to Candidate Recommendation. From informal conversations we've had, we believe other browser vendors share this goal. I think the current WebSocket API is feature complete and meets the requirements for publishing a Last Call working draft to encourage wider review and feedback. There are no tracker issues for WebSockets. Here is my analysis of the outstanding bugs (not closed, where resolution not Fixed). I believe the outstanding issues could be resolved as Last Call comments and would like to see a CfC to publish a LCWD shortly. 9973 - If the entry's name is "sec-websocket-protocol" 0 please don't put normative requirements in parenthesis Resolved, NeedsInfo MICROSOFT PROPOSAL: close the bug - this bug is a year old, likely out of date now, and from an anonymous contributor 10213 - The definition of "absolute url" makes https:foo not an absolute url Open, Assigned to Adam Barth MICROSOFT PROPOSAL: Section 3 of the protocol spec (http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-09#section-3) shows the valid syntax for a ws-URI. We believe the API should throw a SYNTAX_ERR if the address supplied does not match this format. 12180 - give the name of url to download the Jetty server Resolved, NeedsInfo - this bug is from an anonymous contributor from 4 months ago MICROSOFT PROPOSAL: close the bug - the API spec doesn't need to link to server implementations 12510 - Specs split off from HTML5 (like WebSockets) need to have xrefs linked, otherwise they're ambiguous Reopened, Assigned to Ian Hickson MICROSOFT PROPOSAL: this is an editorial bug that should not block Last Call 12816 - Make second argument in constructor an object for future extensibility Resolved, WontFix MICROSOFT PROPOSAL: We think the second argument should be an object, not only for future extensibility but to allow binaryType to be set now. 12917 - "deflate-stream" should be an optional extension when establishing a connection Resolved, WontFix MICROSOFT PROPOSAL: We strongly disagree with the API spec overruling the protocol spec on what is optional in the protocol. The API spec should not normatively mention specific extensions. References to "deflate-stream" should be informative and only provided as examples. 13104 - 1) ping(msg); //allow client to send server ping as per websocket spec 2) onpong(); //allow client to receive response of ping Open, Assigned to Ian Hickson MICROSOFT PROPOSAL: We don't think this is necessary. 13162 - The notes really do need to be cleaned up to be made explicit. Open, Assigned to Ian Hickson MICROSOFT PROPOSAL: This is an editorial bug and should not block Last Call 13178 - binaryType should be immutable after connection is established Open, Assigned to Ian Hickson MICROSOFT PROPOSAL: We'd like to see the spec updated as outlined in this bug. 13180 - [Editorial] Causes that lead to failing the WebSocket connection, which results in an error event, should be more clearly specified Open, Assigned to Ian Hickson MICROSOFT PROPOSAL: This is an editorial issue and should not block Last Call.
Re: Mutation events replacement
On 07/08/2011 12:29 AM, Olli Pettay wrote:
On 07/07/2011 10:18 PM, Jonas Sicking wrote:
Hi All,
I've finally caught up on all the emails in this thread. Here are my
impressions so far.
I don't think John J Barton's proposal to fire "before mutation
notifications" is doable. Trying to make all APIs that would, or
could, mutate the DOM throw or otherwise fail would be much too
complex to implement and too surprising use. The list of APIs that
we'd have to black-list would be far too long and would be heavily
dependent on implementation strategies.
We could take the approach workers take and make such scripts execute
in a wholly different context where the harmful APIs simply aren't
accessible. However such a context would, like workers, not have
access to any of the normal functions or variables that the page
normally uses. So I don't really see what you would do in such a
context? I.e. what use cases would be solved if all you can do is run
calculations, but not otherwise synchronously communicate with the
outside world. And how would you tell such a notification which nodes
are being modified since you can't pass references to the nodes as
Nodes are one of the APIs that we don't want to expose. Additionally,
how would you even register the callback that should be called when
the notification fires? Note that workers always load a wholly new
javascript file, there is no way to pass function references to it.
In short before spending more time on this, I'd like to see a
comprehensive proposal, including a description of the use cases it
solves and how it solves them. I strongly doubt that this approach is
practical.
I really like Rafael's proposal to pass a list of mutations that has
happened to the notification callbacks. This has the advantage that
scripts get *all* the changes that has happened at once, making it
possible to make decisions based on all changes made, rather than
piece-wise getting the information in separate callbacks. It also has
the advantage that we can provide much more detailed information
without having to make multiple calls from C++ to JS which is good for
performance. For example it seems very doable to provide lists of all
nodes that has been removed and added while still keeping performance
reasonable.
I'll write up a proposal based on this idea. Others should feel free
to beat me to it :)
I agree that having list of mutations is a good thing.
I'm less convinced of the part of Rafael's proposal that changes
*when* notifications are called. If I understand the proposal, the
idea is to not fire any notifications directly when the mutation
happens, but instead all notifications are as soon as control is
returned to the event loop. I.e. it's basically fully asynchronous,
except that instead of adding a task to the end of the event queue,
one is added to the beginning of it.
And I also agree with this.
I don't quite see the reason to postpone notification to happen
basically after all the other code in JS stack has run.
Especially since the asynchronous-like approach behaves strangely when
"spin the event loop" is needed.
Having a queue of notifications which are handled after outermost
mutation should be quite easy to understand. Also, that way converting
code from mutation events to mutation listeners should be easier.
Rafael, please do correct me if I'm wrong on the above.
The main concern that I have with this proposal is that it's so
different from mutation events that it might not satisfy the same use
cases. Consider a widget implementation that currently observes the
DOM using mutation events and makes it possible to write code like:
myWidgetBackedElement.appendChild(someNode);
myWidgetBackedElement.someFunction();
where someFunction depends on state which is updated by the mutation
event handler. Such a widget implementation is simply not doable with
these semi-asynchronous callbacks.
On the other hand, maybe this isn't a big deal. We are definitely
short on use cases for mutation events in general which is a problem.
Finally, I actually do think it would be possible to create an API
which allow pages to batch notifications. Something like this should
work:
document.notificationBatch(function() {
element1.appendChild(someNode);
element2.setAttribute("foo", "bar");
});
This would batch all notifications while inside the batch. However,
I'm not convinced we should add such an API, at least in version one.
And definitely not until there are proper use cases. Mutation events
sort have have the ability to batch notifications by calling
stopImmediatePropagation on events when they are fired and then
manually firing events once the batch is done. Is this something
people have done? Can anyone point to examples?
Additionally, we'd have to decide what to do if someone spins the
event loop inside a batch, for example by calling alert() or use
synchronous XHR.
/ Jonas
[Bug 13180] New: [Editorial] Causes that lead to failing the WebSocket connection, which results in an error event, should be more clearly specified
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13180 Summary: [Editorial] Causes that lead to failing the WebSocket connection, which results in an error event, should be more clearly specified Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: WebSocket API (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: adria...@microsoft.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org The reasons for failing the WebSocket connection are spread throughout the spec. It would be helpful to implementers to gather these together in a section that describes the error event. There are a limited number of cases where this occurs based on my reading: * There is a failure to establish a websocket connection * The connection is closed before it is opened * The WebSocket is disappeared before it is opened -- 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: Mutation events replacement
On Thu, Jul 7, 2011 at 1:58 PM, Ryosuke Niwa wrote: > On Thu, Jul 7, 2011 at 12:18 PM, Jonas Sicking wrote: >> >> I don't think John J Barton's proposal to fire "before mutation >> notifications" is doable. > > I concur. Being synchronous was one of the reasons why the existing DOM > mutation events don't work. We shouldn't adding yet-another synchronous > event here. >> >> In short before spending more time on this, I'd like to see a >> comprehensive proposal, including a description of the use cases it >> solves and how it solves them. I strongly doubt that this approach is >> practical. > > Totally agreed. >> >> I really like Rafael's proposal to pass a list of mutations that has >> happened to the notification callbacks. This has the advantage that >> scripts get *all* the changes that has happened at once, making it >> possible to make decisions based on all changes made, rather than >> piece-wise getting the information in separate callbacks. It also has >> the advantage that we can provide much more detailed information >> without having to make multiple calls from C++ to JS which is good for >> performance. For example it seems very doable to provide lists of all >> nodes that has been removed and added while still keeping performance >> reasonable. > > Enthusiastically agreed. >> >> I'll write up a proposal based on this idea. Others should feel free >> to beat me to it :) > > Nice! Looking forward to it. >> >> The main concern that I have with this proposal is that it's so >> different from mutation events that it might not satisfy the same use >> cases. Consider a widget implementation that currently observes the >> DOM using mutation events and makes it possible to write code like: >> >> myWidgetBackedElement.appendChild(someNode); >> myWidgetBackedElement.someFunction(); >> >> where someFunction depends on state which is updated by the mutation >> event handler. Such a widget implementation is simply not doable with >> these semi-asynchronous callbacks. > > Right. But on the other hand, if this code were to run inside a mutation > observer, it won't work in your proposal either. So the questions is > whether writing a function that depends on state updated by the mutation > observer without a mutation observer, and then later calling it inside a > mutation observer happens frequently enough to annoy developers or not. >> >> On the other hand, maybe this isn't a big deal. We are definitely >> short on use cases for mutation events in general which is a problem. Right. Olli & Jonas, I'd really like to understand your thinking about this. Are we not understanding something about your proposal? If accommodating the above is a goal, it seems like the only option is to have mutation events be fully synchronous. I.e. It doesn't seem acceptable to encourage a widget author to expose an API that depends on never being called inside a mutation callback and/or prevents it from being used as a building block for a higher-level abstraction. > > Agreed. We probably need more real-world use cases. > - Ryosuke >
Re: Mutation events replacement
On 07/07/2011 10:18 PM, Jonas Sicking wrote:
Hi All,
I've finally caught up on all the emails in this thread. Here are my
impressions so far.
I don't think John J Barton's proposal to fire "before mutation
notifications" is doable. Trying to make all APIs that would, or
could, mutate the DOM throw or otherwise fail would be much too
complex to implement and too surprising use. The list of APIs that
we'd have to black-list would be far too long and would be heavily
dependent on implementation strategies.
We could take the approach workers take and make such scripts execute
in a wholly different context where the harmful APIs simply aren't
accessible. However such a context would, like workers, not have
access to any of the normal functions or variables that the page
normally uses. So I don't really see what you would do in such a
context? I.e. what use cases would be solved if all you can do is run
calculations, but not otherwise synchronously communicate with the
outside world. And how would you tell such a notification which nodes
are being modified since you can't pass references to the nodes as
Nodes are one of the APIs that we don't want to expose. Additionally,
how would you even register the callback that should be called when
the notification fires? Note that workers always load a wholly new
javascript file, there is no way to pass function references to it.
In short before spending more time on this, I'd like to see a
comprehensive proposal, including a description of the use cases it
solves and how it solves them. I strongly doubt that this approach is
practical.
I really like Rafael's proposal to pass a list of mutations that has
happened to the notification callbacks. This has the advantage that
scripts get *all* the changes that has happened at once, making it
possible to make decisions based on all changes made, rather than
piece-wise getting the information in separate callbacks. It also has
the advantage that we can provide much more detailed information
without having to make multiple calls from C++ to JS which is good for
performance. For example it seems very doable to provide lists of all
nodes that has been removed and added while still keeping performance
reasonable.
I'll write up a proposal based on this idea. Others should feel free
to beat me to it :)
I agree that having list of mutations is a good thing.
I'm less convinced of the part of Rafael's proposal that changes
*when* notifications are called. If I understand the proposal, the
idea is to not fire any notifications directly when the mutation
happens, but instead all notifications are as soon as control is
returned to the event loop. I.e. it's basically fully asynchronous,
except that instead of adding a task to the end of the event queue,
one is added to the beginning of it.
And I also agree with this.
I don't quite see the reason to postpone notification to happen
basically after all the other code in JS stack has run.
Having a queue of notifications which are handled after outermost
mutation should be quite easy to understand. Also, that way converting
code from mutation events to mutation listeners should be easier.
Rafael, please do correct me if I'm wrong on the above.
The main concern that I have with this proposal is that it's so
different from mutation events that it might not satisfy the same use
cases. Consider a widget implementation that currently observes the
DOM using mutation events and makes it possible to write code like:
myWidgetBackedElement.appendChild(someNode);
myWidgetBackedElement.someFunction();
where someFunction depends on state which is updated by the mutation
event handler. Such a widget implementation is simply not doable with
these semi-asynchronous callbacks.
On the other hand, maybe this isn't a big deal. We are definitely
short on use cases for mutation events in general which is a problem.
Finally, I actually do think it would be possible to create an API
which allow pages to batch notifications. Something like this should
work:
document.notificationBatch(function() {
element1.appendChild(someNode);
element2.setAttribute("foo", "bar");
});
This would batch all notifications while inside the batch. However,
I'm not convinced we should add such an API, at least in version one.
And definitely not until there are proper use cases. Mutation events
sort have have the ability to batch notifications by calling
stopImmediatePropagation on events when they are fired and then
manually firing events once the batch is done. Is this something
people have done? Can anyone point to examples?
Additionally, we'd have to decide what to do if someone spins the
event loop inside a batch, for example by calling alert() or use
synchronous XHR.
/ Jonas
Re: Mutation events replacement
On Thu, Jul 7, 2011 at 1:58 PM, Ryosuke Niwa wrote: > > Right. But on the other hand, if this code were to run inside a mutation > observer, it won't work in your proposal either. So the questions is > whether writing a function that depends on state updated by the mutation > observer without a mutation observer, and then later calling it inside a > mutation observer happens frequently enough to annoy developers or not. > I meant to say *writing a function that depends on state updated by the mutation observer outside mutation observers, and later calling it inside a mutation observer* - Ryosuke
Frame embedding: One problem, three possible specs?
(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.html 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: Mutation events replacement
On Thu, Jul 7, 2011 at 12:18 PM, Jonas Sicking wrote: > > I don't think John J Barton's proposal to fire "before mutation > notifications" is doable. I concur. Being synchronous was one of the reasons why the existing DOM mutation events don't work. We shouldn't adding yet-another synchronous event here. In short before spending more time on this, I'd like to see a > comprehensive proposal, including a description of the use cases it > solves and how it solves them. I strongly doubt that this approach is > practical. > Totally agreed. I really like Rafael's proposal to pass a list of mutations that has > happened to the notification callbacks. This has the advantage that > scripts get *all* the changes that has happened at once, making it > possible to make decisions based on all changes made, rather than > piece-wise getting the information in separate callbacks. It also has > the advantage that we can provide much more detailed information > without having to make multiple calls from C++ to JS which is good for > performance. For example it seems very doable to provide lists of all > nodes that has been removed and added while still keeping performance > reasonable. > Enthusiastically agreed. I'll write up a proposal based on this idea. Others should feel free > to beat me to it :) > Nice! Looking forward to it. The main concern that I have with this proposal is that it's so > different from mutation events that it might not satisfy the same use > cases. Consider a widget implementation that currently observes the > DOM using mutation events and makes it possible to write code like: > > myWidgetBackedElement.appendChild(someNode); > myWidgetBackedElement.someFunction(); > > where someFunction depends on state which is updated by the mutation > event handler. Such a widget implementation is simply not doable with > these semi-asynchronous callbacks. > Right. But on the other hand, if this code were to run inside a mutation observer, it won't work in your proposal either. So the questions is whether writing a function that depends on state updated by the mutation observer without a mutation observer, and then later calling it inside a mutation observer happens frequently enough to annoy developers or not. On the other hand, maybe this isn't a big deal. We are definitely > short on use cases for mutation events in general which is a problem. > Agreed. We probably need more real-world use cases. - Ryosuke
Re: [indexeddb] Calling update on a cursor index with a unique value constraint
On Wed, Jul 6, 2011 at 9:41 PM, Jeremy Orlow wrote: > On Wed, Jul 6, 2011 at 10:06 AM, Israel Hilerio >> We believe an error should be thrown because of the violation of the >> unique value index constraint and the error code should be set to >> CONSTRAINT_ERR. What do you think? > > IIRC, we decided update should essentially be an alias to delete and then an > add on the parent object store--probably an atomic one. So by that logic it > does seem to me CONSTRAINT_ERR would be the right error. Hmm.. it's not exactly a delete and a add since if the add produces an error but the error handler calls .preventDefault, you don't want only the delete to be executed. I'd rather say that a .update is the same as a .put. > Btw, ObjectStore.add()'s exception section doesn't mention CONSTRAINT_ERR > though it probably should. IDBObjectStore.add never throws CONSTRAINT_ERR since that's detected asynchronously, so the spec seems fine here. However IDBObjectStoreSync.add and IDBObjectStoreSync.put should and does list it as an exception. / Jonas
Re: [indexeddb] Calling update on a cursor index with a unique value constraint
On Wed, Jul 6, 2011 at 10:06 AM, Israel Hilerio wrote: > What is the expected behavior when calling update() in a cursor index that > requires unique values. Firefox allows the update, even when it results in a > duplicate value. Chrome throws an error event with the code set to > UNKNOWN_ERR. Huh? That seems very bad if we allow duplicate data to be created and violate a unique constraint, no matter what API it happens through. Can you provide a testcase and I'll file a bug on Firefox. > We believe an error should be thrown because of the violation of the unique > value index constraint and the error code should be set to CONSTRAINT_ERR. > What do you think? We can't really throw an error since we don't synchronously know that there is a collision. However we should fire an error event with .code set to CONSTRAINT_ERR if there is a collision. Indeed it seems like the spec already demands this. IDBCursor.update says to run the "steps for storing a record into an object store". Those steps define that if a unique constraint is violated a CONSTRAINT_ERR is reported. This happens in step 7.5 and 7.6. / Jonas
Re: [WebIDL] Exceptions
On Thu, Jul 7, 2011 at 12:47 PM, Ian Hickson wrote:
> On Thu, 7 Jul 2011, Jonas Sicking wrote:
>>
>> It's a pain since it forces us to try to coordinate codes across
>> multiple specifications, working groups and standards organizations.
>
> Anything that allows us to _not_ coordinate is an epic disaster, IMHO.
>
> We absolutely should be coordinating. How else can we ensure the platform
> is a consistent platform?
>
> This is a feature, not a bug.
Ok, let me know once this has been resolved and we can remove this
from the list of arguments at that time.
>> And even if this coordinating somehow started magically working, it
>> still means that exceptions thrown by the DOM needs to be checked
>> differently than exceptions thrown by ES. So you'll end up having to do:
>
> Are there exceptions that can be legitimately thrown by JS that aren't
> programming bugs?
Don't know. Are there ones that can be thrown by the DOM that aren't
programming bugs?
>> Lastly, the syntax:
>> if (ex.name === "HierarchyRequestError") { ... }
>> is a lot easier on the eyes than:
>> if (ex.code === DOMException.HIERARCHY_REQUEST_ERR) { ... }
>> IMHO.
>
> I've no problem with adding names to all the current exceptions, if we
> want to do that. (I generally am averse to using strings for values, since
> they don't syntax check well, but in JS that game is somewhat lost in the
> above scenario anyway, so whatever.)
>
> My concern is with having newer parts of the platform use entirely
> different models (e.g. new exception interfaces) relative to older parts
> of the platform (which e.g. use codes). It leads to the kind of problem
> you describe with JS vs DOM, except that we'd have JS vs DOM vs new DOM vs
> even new DOM, etc.
This is an attempt to fix this problem. We're already in the state
where we have two different exception systems. This is an attempt to
create just one. The one used by ES. I'm definitely not suggesting
that the existing exceptions thrown by various specs should *not* have
a .name and should not inherit Exception. I think all exceptions
should be changed to follow that model.
/ Jonas
[Bug 13178] New: binaryType should be immutable after connection is established
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13178 Summary: binaryType should be immutable after connection is established Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: WebSocket API (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: adria...@microsoft.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Microsoft proposes that: 1. As proposed in 12816 [1] - Make second argument in constructor an object for future extensibility - a property bag is added to the constructor. 2. The property bag initially includes protocols and binaryType. 3. The binaryType is immutable after the connection is established. The binaryType attribute is read only. As discussed in Bug 12102 [2] -WebSocket protocol update time if there is a significant need to allow binaryType to be changed after a connection is established, then it can be enabled in the next version. Currently, it is introducing complexity and potential performance impacts into the implementation without clear scenarios. There is also a mitigation of using ArrayBuffer<->Blob conversion routines. [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=12816 [2] http://www.w3.org/Bugs/Public/show_bug.cgi?id=12102#c40 -- 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: [WebIDL] Exceptions
On Thu, 7 Jul 2011, Jonas Sicking wrote:
>
> It's a pain since it forces us to try to coordinate codes across
> multiple specifications, working groups and standards organizations.
Anything that allows us to _not_ coordinate is an epic disaster, IMHO.
We absolutely should be coordinating. How else can we ensure the platform
is a consistent platform?
This is a feature, not a bug.
> And even if this coordinating somehow started magically working, it
> still means that exceptions thrown by the DOM needs to be checked
> differently than exceptions thrown by ES. So you'll end up having to do:
Are there exceptions that can be legitimately thrown by JS that aren't
programming bugs?
> Lastly, the syntax:
> if (ex.name === "HierarchyRequestError") { ... }
> is a lot easier on the eyes than:
> if (ex.code === DOMException.HIERARCHY_REQUEST_ERR) { ... }
> IMHO.
I've no problem with adding names to all the current exceptions, if we
want to do that. (I generally am averse to using strings for values, since
they don't syntax check well, but in JS that game is somewhat lost in the
above scenario anyway, so whatever.)
My concern is with having newer parts of the platform use entirely
different models (e.g. new exception interfaces) relative to older parts
of the platform (which e.g. use codes). It leads to the kind of problem
you describe with JS vs DOM, except that we'd have JS vs DOM vs new DOM vs
even new DOM, etc.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: publish Last Call Working Draft of Web IDL; deadline July 7
Microsoft supports publishing a Last Call working draft of the Web IDL spec. We believe that the spec is feature complete and meets the requirements below. While we have a few reservations about Exceptions and share some of the concerns voiced in the separate thread on that topic, we believe that can be dealt with as Last Call comments. On Thursday, June 30, 2011 3:46 AM, Arthur Barstow wrote: > As Cameron indicated in [1], all non-enhancements bugs for Web IDL are > now resolved and as such, this is a Call for Consensus to publish a Last > Call Working Draft of Web IDL: > >http://dev.w3.org/2006/webapi/WebIDL/ > > This CfC satisfies the group's requirement to "record the group's > decision to request advancement" for this LCWD. > > Note the Process Document states the following regarding the > significance/meaning of a LCWD: > > [[ > http://www.w3.org/2005/10/Process-20051014/tr.html#last-call > > Purpose: A Working Group's Last Call announcement is a signal that: > > * the Working Group believes that it has satisfied its relevant > technical requirements (e.g., of the charter or requirements document) > in the Working Draft; > > * the Working Group believes that it has satisfied significant > dependencies with other groups; > > * other groups SHOULD review the document to confirm that these > dependencies have been satisfied. In general, a Last Call announcement > is also a signal that the Working Group is planning to advance the > technical report to later maturity levels. > ]] > > Positive response to this CfC is preferred and encouraged and silence > will be considered as agreement with the proposal. The deadline for > comments is July 7. Please send all comments to: > > public-script-co...@w3.org > > -Art Barstow > > >
Re: [FileAPI] Updates to FileAPI Editor's Draft
On Tue, Jun 21, 2011 at 10:17 AM, Arun Ranganathan wrote:
> Sorry if these have all been discussed before. I just read the File API for
> the first time and 2 random questions popped in my head.
> 1) If I'm using readAsText with a particular encoding and the data in the
> file is not actually in that encoding such that code points in the file can
> not be mapped to valid code points what happens? Is that implementation
> specific or is it specified? I can imagine at least 3 different behaviors.
>
> This should be specified better and isn't. I'm inclined to then return the
> file in the encoding it is in rather than force an encoding (in other words,
> ignore the encoding parameter if it is determined that code points can't be
> mapped to valid code points in the encoding... also note that we say to
> "Replace bytes or sequences of bytes that are not valid according to
> the charset with a single U+FFFD character [Unicode]"). Right now, the spec
> isn't specific to this scenario ("... if the user agent cannot decode blob
> using encoding, then let charset be null" before the algorithmic steps,
> which essentially forces UTF-8).
I definitely don't think we should use some type of autodetecting of
charset if people explicitly define one. That is likely to create more
confusion and bugs than it'll solve problems.
I don't fully understand what's undefined if we say that any invalid
character should be replaced by U+FFFD? I.e. why isn't that enough?
I'm not at all doubting that it isn't enough, but I'd like to
understand how it's not enough in order to fix it.
> 2) If I'm reading using readAsText a multibyte encoding (utf-8, shift-jis,
> etc..) is it implementation dependent whether or not it can return partial
> characters when returning partial results during reading? In other words,
> Let's say the next character in a file is a 3 byte code point but the
> reader has only read 2 of those 3 bytes so far. Is implementation dependent
> whether result includes those 2 bytes before reading the 3rd byte or not?
>
> Yes, partial results are currently implementation dependent; the spec. only
> says they SHOULD be returned. There was reluctance to have MUST condition
> on partial file reads. I'm open to revisiting this decision if the
> justification is a really good one.
I absolutely don't think we should return partial results. From the
page authors point of view .result should "stream" in. Once a
character has been appended to it, it should never change.
/ Jonas
Re: Mutation events replacement
Hi All,
I've finally caught up on all the emails in this thread. Here are my
impressions so far.
I don't think John J Barton's proposal to fire "before mutation
notifications" is doable. Trying to make all APIs that would, or
could, mutate the DOM throw or otherwise fail would be much too
complex to implement and too surprising use. The list of APIs that
we'd have to black-list would be far too long and would be heavily
dependent on implementation strategies.
We could take the approach workers take and make such scripts execute
in a wholly different context where the harmful APIs simply aren't
accessible. However such a context would, like workers, not have
access to any of the normal functions or variables that the page
normally uses. So I don't really see what you would do in such a
context? I.e. what use cases would be solved if all you can do is run
calculations, but not otherwise synchronously communicate with the
outside world. And how would you tell such a notification which nodes
are being modified since you can't pass references to the nodes as
Nodes are one of the APIs that we don't want to expose. Additionally,
how would you even register the callback that should be called when
the notification fires? Note that workers always load a wholly new
javascript file, there is no way to pass function references to it.
In short before spending more time on this, I'd like to see a
comprehensive proposal, including a description of the use cases it
solves and how it solves them. I strongly doubt that this approach is
practical.
I really like Rafael's proposal to pass a list of mutations that has
happened to the notification callbacks. This has the advantage that
scripts get *all* the changes that has happened at once, making it
possible to make decisions based on all changes made, rather than
piece-wise getting the information in separate callbacks. It also has
the advantage that we can provide much more detailed information
without having to make multiple calls from C++ to JS which is good for
performance. For example it seems very doable to provide lists of all
nodes that has been removed and added while still keeping performance
reasonable.
I'll write up a proposal based on this idea. Others should feel free
to beat me to it :)
I'm less convinced of the part of Rafael's proposal that changes
*when* notifications are called. If I understand the proposal, the
idea is to not fire any notifications directly when the mutation
happens, but instead all notifications are as soon as control is
returned to the event loop. I.e. it's basically fully asynchronous,
except that instead of adding a task to the end of the event queue,
one is added to the beginning of it.
Rafael, please do correct me if I'm wrong on the above.
The main concern that I have with this proposal is that it's so
different from mutation events that it might not satisfy the same use
cases. Consider a widget implementation that currently observes the
DOM using mutation events and makes it possible to write code like:
myWidgetBackedElement.appendChild(someNode);
myWidgetBackedElement.someFunction();
where someFunction depends on state which is updated by the mutation
event handler. Such a widget implementation is simply not doable with
these semi-asynchronous callbacks.
On the other hand, maybe this isn't a big deal. We are definitely
short on use cases for mutation events in general which is a problem.
Finally, I actually do think it would be possible to create an API
which allow pages to batch notifications. Something like this should
work:
document.notificationBatch(function() {
element1.appendChild(someNode);
element2.setAttribute("foo", "bar");
});
This would batch all notifications while inside the batch. However,
I'm not convinced we should add such an API, at least in version one.
And definitely not until there are proper use cases. Mutation events
sort have have the ability to batch notifications by calling
stopImmediatePropagation on events when they are fired and then
manually firing events once the batch is done. Is this something
people have done? Can anyone point to examples?
Additionally, we'd have to decide what to do if someone spins the
event loop inside a batch, for example by calling alert() or use
synchronous XHR.
/ Jonas
Re: [WebIDL] Exceptions
On Thu, Jul 7, 2011 at 2:28 PM, Jonas Sicking wrote: > It's a pain since it forces us to try to coordinate codes across > multiple specifications, working groups and standards organizations. > So far this has failed resulting in multiple specifications defining > their own exception types with overlapping codes, forcing people to > check both interface and code. I strongly suspect there's tons of > "buggy" JS code out there that doesn't do this correctly and just > checks the code. > > So while in theory using codes to distinguish could work, in practice it > hasn't. I think (?) everyone agrees codes are a bad idea for new exceptions, and we should add a .name attribute that contains the exception name and use that instead. The question is whether we should also define different interfaces for each exception, or just make everything a DOMException or whatever. I see no advantage to adding the extra interfaces, if we want authors to check .name instead of using instanceof. A separate issue is, if we use .name, what exactly it should contain. "HierarchyRequestError" would look more like ES exceptions, but some existing browsers support .name and have it contain "HIERARCHY_REQUEST_ERROR" or something similar. This is a bikeshed issue, but I'd say pave the cowpaths and format the error code LIKE_THIS instead of LikeThis for DOMExceptions and friends, even though it's inconsistent with TypeError and such.
Re: [WebIDL] Exceptions
On Wed, Jul 6, 2011 at 9:04 PM, Ian Hickson wrote:
> On Wed, 6 Jul 2011, Aryeh Gregor wrote:
>>
>> The thing I don't like about this proposal is that it encourages authors
>> to use "e instanceof IndexSizeError" or similar. This will work 98% of
>> the time and then fail in an extremely mysterious way when multiple
>> globals are involved. All you need is the exception to be thrown by
>> something in an iframe for whatever reason.
>
> I'm also skeptical of this. The platform uses DOMException almost
> everywhere, and I really don't see what's wrong with that.
It's a pain since it forces us to try to coordinate codes across
multiple specifications, working groups and standards organizations.
So far this has failed resulting in multiple specifications defining
their own exception types with overlapping codes, forcing people to
check both interface and code. I strongly suspect there's tons of
"buggy" JS code out there that doesn't do this correctly and just
checks the code.
So while in theory using codes to distinguish could work, in practice it hasn't.
And even if this coordinating somehow started magically working, it
still means that exceptions thrown by the DOM needs to be checked
differently than exceptions thrown by ES. So you'll end up having to
do:
switch (ex.code) {
case DOMException.HIERARCHY_REQUEST_ERR:
...
case DOMException.WRONG_DOCUMENT_ERR:
...
default:
switch (ex.name) {
case "TypeError":
...
}
}
Lastly, the syntax:
if (ex.name === "HierarchyRequestError") { ... }
is a lot easier on the eyes than:
if (ex.code === DOMException.HIERARCHY_REQUEST_ERR) { ... }
IMHO.
/ Jonas
Re: [WebIDL] Exceptions
On Jul 7, 2011, at 10:09 AM, Aryeh Gregor wrote: > On Wed, Jul 6, 2011 at 9:46 PM, Brendan Eich wrote: >> Gecko is buggy if it is using the dynamic scope. Please file that bug and >> cc: me. > > Gecko says the exception is an instanceof the DOMException object that > corresponds to *any* window. So e instanceof window1.DOMException and > also e instanceof window2.DOMException. IIRC, there's already a bug > filed on this, but I can't find it. Oh, I dimly recall this now. Earl adaptation to help developers confused by the cross-frame instanceof failure case? Not sure how early but I think it's pretty old. If you use Object.getPrototypeOf in a loop (hand-expand instanceof), you can probably find out which window's DOMException.prototype is on the chain. That would be interesting. /be
Re: [WebIDL] Exceptions
On Wed, Jul 6, 2011 at 9:46 PM, Brendan Eich wrote: > Gecko is buggy if it is using the dynamic scope. Please file that bug and cc: > me. Gecko says the exception is an instanceof the DOMException object that corresponds to *any* window. So e instanceof window1.DOMException and also e instanceof window2.DOMException. IIRC, there's already a bug filed on this, but I can't find it.
[Bug 13172] New: The definition for [MessageEvent] is missing.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13172 Summary: The definition for [MessageEvent] is missing. 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: 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 Specification: http://dev.w3.org/html5/websockets/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: The definition for [MessageEvent] is missing. Posted from: 109.231.193.164 User agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_8; en-us) AppleWebKit/533.21.1 (KHTML, like Gecko) Version/5.0.5 Safari/533.21.1 -- 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.
