Re: Mutation events replacement
On 04/07/11 21:43, Olli Pettay wrote:
On 07/04/2011 09:01 PM, Dave Raggett wrote:
On 04/07/11 17:57, Olli Pettay wrote:
Mutation listener could easily
implement old/new value handling itself, especially if it knows which
attributes it is interested in.
How exactly would the listener know the previous state?
In the easiest case when the script cares about only one specific
attribute:
element.addAttributeChangeListener(
{
prevVal: element.getAttribute(foo),
handleMutation: function(node, changeTarget) {
if (node == changeTarget) {
// do something with this.prevVal
...
this.prevVal = element.getAttribute(foo);
}
}
});
How does that scale to the case where you set the observer on the
document or on a div element acting as a contained for content editable
content? If I am not mistaken you would have to keep a copy of the
document, or of that div element respectively, and keep it in sync with
all of the mutations, which sounds like a major performance hit, and
something you don't need to incur with the current DOM mutation events.
--
Dave Raggettd...@w3.org http://www.w3.org/People/Raggett
Re: [eventsource] Is Server-Sent Events ready for LC? ; deadline July 1
On Tue, 05 Jul 2011 21:16:55 +0200, Daniel Veditz dved...@mozilla.com wrote: The fix for the spec would be to drop the line Once the end of the file is reached, the user agent must dispatch the event one final time, as defined below. For clarity something explicit could be added If the end of the file is reached while collecting data and before encountering a blank line the incomplete event must not be dispatched. The ABNF in http://dev.w3.org/html5/eventsource/#parsing-an-event-stream would also need updating. -- Anne van Kesteren http://annevankesteren.nl/
[Bug 13155] New: The security considerations section needs to be updated to take CORS into account.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13155 Summary: The security considerations section needs to be updated to take CORS into account. Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#tex t/event-stream OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Server-Sent Events (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, ann...@opera.com, public-webapps@w3.org Specification: http://www.whatwg.org/specs/web-apps/current-work/complete/comms.html Multipage: http://www.whatwg.org/C#text/event-stream Complete: http://www.whatwg.org/c#text/event-stream Comment: The security considerations section needs to be updated to take CORS into account. Posted from: 213.236.208.22 by ann...@opera.com User agent: Opera/9.80 (Macintosh; Intel Mac OS X 10.6.8; U; en) Presto/2.9.168 Version/11.50 -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 13156] New: The charset parameter is now an optional parameter (even though it can only be set to UTF-8). That should probably be stated here.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13156 Summary: The charset parameter is now an optional parameter (even though it can only be set to UTF-8). That should probably be stated here. Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#tex t/event-stream OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Server-Sent Events (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, ann...@opera.com, public-webapps@w3.org Specification: http://www.whatwg.org/specs/web-apps/current-work/complete/comms.html Multipage: http://www.whatwg.org/C#text/event-stream Complete: http://www.whatwg.org/c#text/event-stream Comment: The charset parameter is now an optional parameter (even though it can only be set to UTF-8). That should probably be stated here. Posted from: 213.236.208.22 by ann...@opera.com User agent: Opera/9.80 (Macintosh; Intel Mac OS X 10.6.8; U; en) Presto/2.9.168 Version/11.50 -- 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 Wed, 06 Jul 2011 07:14:38 +0200, James Robinson jam...@google.com wrote: No browser updates the rendering after invoking every single task, but I'm pretty sure that no modern browser updates the rendering at any other time. Opera does, but we may have to change that. (Our script execution is non-blocking, but we may have to make it blocking for repainting as per HTML for better compatibility.) -- Anne van Kesteren http://annevankesteren.nl/
Re: Mutation events replacement
On 07/06/2011 08:14 AM, James Robinson wrote: On Tue, Jul 5, 2011 at 5:51 PM, Ojan Vafai o...@chromium.org mailto:o...@chromium.org wrote: On Tue, Jul 5, 2011 at 5:36 PM, Ryosuke Niwa rn...@webkit.org mailto:rn...@webkit.org wrote: On Tue, Jul 5, 2011 at 5:27 PM, Rafael Weinstein rafa...@google.com mailto:rafa...@google.com wrote: It seems like these are rarified enough cases that visual artifacts are acceptable collateral damage if you do this. [Put another way, if you care enough about the visual polish of your app that you will put energy into avoiding flickr, you probably aren't using alert and showModalDialog anyway]. Also, it's up to the app when to do it, so it's entirely in its control (and thus avoid visual artifacts). Given that we don't provide an API to control paint in general, I'm not convinced that we should add such a requirement in the DOM mutation event spec. Many of the use-cases for mutation events (e.g. model-driven views) are poorly met if we don't give some assurances here. Note that this is a problem with both proposals. Work done in (at least some) mutation observers is delayed. If a sync paint occurs before it, it's work won't be reflected on the screen. Right. Maybe we can add a note saying that the user agents are recommended not to paint before all mutation observers are called. I don't think we should make this a requirement. There may be a middle ground that isn't so hard to for browser vendors implement interoperably. Can we require no repaint except in the presence of a specific list synchronous API calls? I'm sure that's too simplistic, but I'm hoping someone with more experience can chime in with something that might actually be a plausible requirement. HTML specifies to a limited extent when painting can happen with regard to what it defines as tasks: http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#processing-model-2 See step 5 - update the rendering is equivalent to painting. Ignoring step (2) which relates to the storage mutex, this description is accurate. No browser updates the rendering after invoking every single task, but I'm pretty sure that no modern browser updates the rendering at any other time. Note that a few APIs such as showModalDialog() invoke this algorithm: http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#spin-the-event-loop which effectively starts up a second event loop within the processing of a task, meaning that the browser can paint while the task that resulted in the showModalDialog() call is still running. Authors who are using showModalDialog() are being extremely user-hostile so I don't think we need to accomodate them. Sync XHR is one case when at least some browsers do repainting. And yes, sync XHR is probably as user-hostile as showModalDialog(), but unfortunately it is used quite often. One question I have with regards to the proposed processing model is whether to define this in terms of entering script or in terms of 'tasks' in the HTML sense. For example, asynchronous DOM events are typically set up by queueing a single task to fire the event, but there might be multiple event listeners registered for that one event that would all be fired as part of the same task. If we were to define things in terms of tasks, then I think Rafael's proposal is similar to extending step 4 provide a stable state of the event loop algorithm in order to notify observers before proceeding to step 5. This would mean that if multiple click handlers were registered on an element and the user clicked on it, all of the event handlers would run, then the mutation observers would run, then the browser would be free to paint if it chose to. An alternative approach would be to hook on calling in to script (http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#calling-scripts) and run the observers after each script invocation. This means that if multiple handlers were registered for an event then the first handler would be invoked, then observers notified, then the second handler invoked, etc. It would still have the property that the observers would always run before the browser painted so long as no script spun the event loop. I hope this helps. This has been a long thread and I haven't had a chance to fully digest all of it, but I'm really happy that people are taking a serious look at this problem. - James - Ryosuke
Re: Publishing From-Origin Proposal as FPWD
On Tue, 05 Jul 2011 17:50:57 +0200, Hill, Brad bh...@paypal-inc.com wrote: I feel that the goals of this draft are either inconsistent with the basic architecture of the web, cannot be meaningfully accomplished by the proposed mechanism, or both, and I haven't seen any discussion of these concerns yet. It would be helpful if you could articulate what exactly of http://www.w3.org/TR/webarch/ argues against having this feature. As for users disabling this feature in their user agent, that would of course be a problem and mean the feature would not work. How likely this is to happen is somewhat unclear to me. Sites wishing to prevent bandwidth theft can already do so via Referer header checking, which has the annoying side effect that sometimes not even direct linking towards such a resource works. And as for clickjacking, because of the design of the header as it stands now it can replace the non-standard X-Frame-Options. This does indeed not give fine-grained control, but you do not need that for all cases. -- Anne van Kesteren http://annevankesteren.nl/
[WebIDL] Exceptions
So with Web IDL going to Last Call does this mean that the exception model outlined in http://www.w3.org/Bugs/Public/show_bug.cgi?id=10623#c8 is the way forward? I.e. we introduce new exception interfaces in DOM Core for all the different exception types and update all other specifications that use DOM Core to dispatch those exceptions instead (and they are somewhat backwards compatible because they inherit from DOMException and therefore still have the code member). I guess there is no particular rush on this; I am mainly wondering whether other editors are aware of this change and agree with it. -- Anne van Kesteren http://annevankesteren.nl/
Re: [eventsource] Is Server-Sent Events ready for LC? ; deadline July 1
Thanks Anne and Dan. I added your comments to bug 13071. All - in addition to 13071, on July 6, Anne submitted 13155 and 13156 against this spec. Unless I hear otherwise, I assume the group wants to block LC until all of these bugs are addressed. As always, patches/fixes for open bugs are welcome (preferably as comments in the bugs). -AB On 7/6/11 4:52 AM, ext Anne van Kesteren wrote: On Tue, 05 Jul 2011 21:16:55 +0200, Daniel Veditz dved...@mozilla.com wrote: The fix for the spec would be to drop the line Once the end of the file is reached, the user agent must dispatch the event one final time, as defined below. For clarity something explicit could be added If the end of the file is reached while collecting data and before encountering a blank line the incomplete event must not be dispatched. The ABNF in http://dev.w3.org/html5/eventsource/#parsing-an-event-stream would also need updating.
[Bug 13158] New: i dont understand this
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13158 Summary: i dont understand this Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#mes sage-channels OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Web Messaging (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Specification: http://www.whatwg.org/specs/web-apps/current-work/complete/web-messaging.html Multipage: http://www.whatwg.org/C#message-channels Complete: http://www.whatwg.org/c#message-channels Comment: i dont understand this Posted from: 80.58.205.44 User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0 -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 13158] i dont understand this
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13158 Ross Nicoll j...@jrn.me.uk changed: What|Removed |Added Status|NEW |RESOLVED CC||j...@jrn.me.uk Resolution||INVALID -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: Mutation events replacement
On 7/6/11 4:27 AM, Dave Raggett wrote: How does that scale to the case where you set the observer on the document or on a div element acting as a contained for content editable content? If I am not mistaken you would have to keep a copy of the document, or of that div element respectively, and keep it in sync with all of the mutations, which sounds like a major performance hit, and something you don't need to incur with the current DOM mutation events. Oh, you _do_ incur a major performance hit with current mutation events if you watch attribute mutations, precisely due to the need to save the pre-mutation values. You just push the performance hit off on the browser core. And before you say that it can do this more efficiently, that's only true if you're interested in the previous value of _all_ attributes. I realize your particular use case is. But lots of others are not. Unfortunately, the browser has no way to tell which attributes on which elements the mutation event really cares about, so all mutation event consumers take the same performance hit. Which leads to the common recommendation to not use attribute modification mutation events at all, because, for example, they make your jQuery animations dog-slow. Again, I realize this is not a problem for you because of your particular use case of mirroring the entire DOM. But let's not pretend there's no performance hit now or that the performance hit with a different setup would always be more than what we have now. -Boris
Re: Publishing From-Origin Proposal as FPWD
Thanks Björn and Brad for your comments. I agree early comments from a broad set of stakeholders is important and I encourage everyone to please send all technical feedback on this spec to: public-webapps@w3.org -Art Barstow On 7/5/11 11:14 PM, ext Hill, Brad wrote: To the procedural points: I am not a member of the Web Applications WG. I do not have standing to block or make a formal objection to this moving forward as a FPWD. Responsibility to measure consensus and the decision to move forward within that WG rests with Art. The opinion of the proposed Web Applications Security WG (currently in the process of being chartered and of which I am a proposed co-chair) was solicited as to whether the work should move to that forum or be a joint deliverable with the Content Security Policy. Additionally, one of the goals of the draft was to address concerns around clickjacking, an item under the proposed charter scope of the WebAppSec WG. Wearing that (still phantom) hat, I can say is that there isn't consensus to move this proposed mechanism as a cross-domain framing security solution to FPWD, alone or as part of the CSP, in the WebAppSec WG, at this time. Until AC approval, we can't move anything to FPWD at this time. :) My other concerns with the proposal are put forward only as an interested member of the community. I expect there will be ample opportunity to discuss them. If Art feels that moving forward to FPWD is the best next step to foster that and other discussions, I'm more than happy to participate there to the extent the WG welcomes my feedback and finds it useful. Thanks, Brad Hill -Original Message- From: public-web-security-requ...@w3.org [mailto:public-web-security-requ...@w3.org] On Behalf Of Bjoern Hoehrmann Sent: Tuesday, July 05, 2011 4:38 PM To: Marcos Caceres Cc: WebApps WG; public-web-secur...@w3.org Subject: Re: Publishing From-Origin Proposal as FPWD * Marcos Caceres wrote: On Tue, Jul 5, 2011 at 5:50 PM, Hill, Bradbh...@paypal-inc.com wrote: I feel that the goals of this draft are either inconsistent with the basic architecture of the web, cannot be meaningfully accomplished by the proposed mechanism, or both, and I haven't seen any discussion of these concerns yet. I note that the Web Applications Working Group's Charter, if Brad Hill is a member, does require the rest of the Working Group to duly consider his points before moving on without consensus. If not, then the group is not required to wait with publication, but not discussing the points in a timely manner, without an argument how publication is urgent in some way, does not inspire confidence that the arguments will be heard and duly handled. Publication will enable wider discussion - particularly wrt the issues you have raised. Not publishing it is tantamount to saying I OBJECT TO PROGRESS!. If you are correct, more people will see it and the proposal will be shot down. Otherwise, other opinions will flourish that may sway your position (or a new perspective will emerge all together). In any case, calling for a spec not to be published, no matter how bad it is, is not the right way to do this. Publishing a spec is just a formality which can lead to discussion. The more invested people are into something, the less likely they are to cut their losses; by doing things, you frame the discussion in favour of doing more. You get people to think more about how something can be fixed rather than thinking about whether to abandon the work, or use a very different approach. If you just propose an idea to me, we can talk about it more freely than if you had already invested a lot of effort on implementing the idea and asked me to review the idea after the fact. (~ Die normative Kraft des Faktischen) Realizing something is a bad idea early is therefore very important and not objecting to progress. Not wasting time on bad ideas is certainly progress, even if only indirectly as you'd work on other things instead. As such it is quite important to react timely to design critique with care and detail. Psychologically, if you press ahead, you communicate that you care more about moving on than discussing details, which is likely to turn away the people more interested in details and quality; and the same is of course true for draft of genuinely bad quality. Which is just to say this is actually an important matter; sometimes it is best to go ahead and put your ideas into practise whatever others may be saying, other times it turns out that you should have listened more. That is why we allow people to block actions, not necessarily progress, but only up to the point where arguments have been duly considered. And here we have yet to do that. Until that happens, short of someone making the case for urgency, I would agree the group should not publish and talk about this instead. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am
Re: Mutation events replacement
On 7/6/2011 5:38 AM, Boris Zbarsky wrote: On 7/6/11 4:27 AM, Dave Raggett wrote: How does that scale to the case where you set the observer on the document or on a div element acting as a contained for content editable content? If I am not mistaken you would have to keep a copy of the document, or of that div element respectively, and keep it in sync with all of the mutations, which sounds like a major performance hit, and something you don't need to incur with the current DOM mutation events. Oh, you _do_ incur a major performance hit with current mutation events if you watch attribute mutations, precisely due to the need to save the pre-mutation values. You just push the performance hit off on the browser core. And before you say that it can do this more efficiently, that's only true if you're interested in the previous value of _all_ attributes. I realize your particular use case is. But lots of others are not. Unfortunately, the browser has no way to tell which attributes on which elements the mutation event really cares about, so all mutation event consumers take the same performance hit. Which leads to the common recommendation to not use attribute modification mutation events at all, because, for example, they make your jQuery animations dog-slow. Again, I realize this is not a problem for you because of your particular use case of mirroring the entire DOM. But let's not pretend there's no performance hit now or that the performance hit with a different setup would always be more than what we have now. This is another advantage of onModelChanging or 'before' events. All of the previous values are available for listeners and the task of selecting which ones to process is left to the listener. jjb
Re: Mutation events replacement
On 7/6/11 10:23 AM, John J. Barton wrote: This is another advantage of onModelChanging or 'before' events. All of the previous values are available for listeners and the task of selecting which ones to process is left to the listener. Yes, I realize this is useful. This is why Gecko internally has an AttributeWillChange notification Again, the problem is preventing malicious onModelChanging listeners from screwing everyone else over. -Boris
Re: Mutation events replacement
On Wed, Jul 6, 2011 at 1:27 AM, Dave Raggett d...@w3.org wrote:
On 04/07/11 21:43, Olli Pettay wrote:
In the easiest case when the script cares about only one specific
attribute:
element.**addAttributeChangeListener(
{
prevVal: element.getAttribute(foo),
handleMutation: function(node, changeTarget) {
if (node == changeTarget) {
// do something with this.prevVal
...
this.prevVal = element.getAttribute(foo);
}
}
});
How does that scale to the case where you set the observer on the document
or on a div element acting as a contained for content editable content? If
I am not mistaken you would have to keep a copy of the document, or of that
div element respectively, and keep it in sync with all of the mutations,
which sounds like a major performance hit, and something you don't need to
incur with the current DOM mutation events.
We should probably include the old value optionally.
- Ryosuke
Re: Mutation events replacement
On Wed, Jul 6, 2011 at 7:43 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 7/6/11 10:23 AM, John J. Barton wrote: This is another advantage of onModelChanging or 'before' events. All of the previous values are available for listeners and the task of selecting which ones to process is left to the listener. Yes, I realize this is useful. This is why Gecko internally has an AttributeWillChange notification Again, the problem is preventing malicious onModelChanging listeners from screwing everyone else over. I think Boris and I are on the same page here. Adding 'before' events defeats the whole purpose. If we can safely implement 'before' events, then there's a little need to replace DOM mutation events in the first place. - Ryosuke
Re: [webstorage] Plan to move the spec to Last Call Working Draft
Thanks Scott for volunteering to create a fix for 13020. Ideally, the Editor would address all of the open bugs and WebApps' version of Web Storage would be as close as possible to the WHATWG's version. However, given the conflicting constraints of moving this spec to LC now and the low priority of this spec for Ian, it appears we need to proceed otherwise. Scott - please create a fix we can review and base it on the latest ED [ED]. It may be helpful if your fix included PLH's fix for 12111 [1211-fix] and to put your version of the spec in the publish directory [PUB] e.g. create LC-webstorage-2011July.html. -Thanks, ArtB [ED] http://dev.w3.org/cvsweb/html5/webstorage/ [PUB] http://dev.w3.org/cvsweb/html5/webstorage/publish/ [1211-fix] http://www.w3.org/2011/06/Web%20Storage.html On 6/30/11 3:20 PM, ext Scott Wilson wrote: On 30 Jun 2011, at 14:55, Arthur Barstow wrote: Given the lack of support for stopping work on Web Storage [1], I'd let to get consensus on the plan to move it to Last Call Working Draft. Currently there are two open bugs: 1. Bug 12111: spec for Storage object getItem(key) method does not match implementation behavior. PLH created a version of the spec that addresses this bug [12111-fix]. 2. Bug 13020: No user agent will implement the storage mutex so this passage does not reflect reality. There are different opinions on the priority of Web Storage ... * Web Storage is a low priority and the Editor will get to it when he gets to it * Web Storage is a high priority because the lack of a LCWD will block at least the Widget Interface spec from progressing on the Rec track There are various options on what to do next, including: 1. Fix 12111 and 13020 and move Web Storage to LCWD +1 2. Leave Web Storage as is and eventually implementations will match the spec 3. Do #1 in one version of the spec and keep #2 as a separate version of the spec (e.g. L1 and L2). Comments on these options are welcome. If you prefer #1, please indicate if you are willing to create a fix/patch for bug 13020. Yes. -AB [1] http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1110.html [12111] http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111 [12111-fix] http://www.w3.org/2011/06/Web%20Storage.html [13020] http://www.w3.org/Bugs/Public/show_bug.cgi?id=13020
[indexeddb] Calling update on a cursor index with a unique value constraint
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. 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? Israel
RE: [indexeddb] IDBRequest.transaction property set to null
On Tuesday, June 28, 2011 11:21 AM, Israel Hilerio wrote: On Monday, June 27, 2011 11:59 PM, Jeremy Orlow wrote: On Thu, Jun 23, 2011 at 2:21 PM, Israel Hilerio isra...@microsoft.com wrote: In the definition of IDBRequest.transaction it stipulates that This property can be null for certain requests, such as for request returned from IDBFactory.open and IDBDatabase.setVersion. Based on this we understand that the following handlers will set the transaction property to null: * setVersion onsuccess handler * setVersion onerror handler * setVersion onblock handler * open onsuccess handler * open onerror handler Are there any other times when this property should be set to null or is this the complete list? We couldn't think of any other times when this applied but wanted to check. I believe this is correct. Also, in the setVersion case, if we're setting the result property to its active transaction, why are we setting the transaction property to null instead of the same active transaction? I know Jonas and I talked about this, but I don't remember the reasoning for sure. One thing I can think of off the top of my head is that it's weird that it'd start off null and then be set later. Also, it would be duplicate data given that .result is also set to the transaction. Is there any strong reason to set it? J The main reason was to keep a consistent calling pattern inside our event handlers: * event.target.transaction.oncomplete The only exception to this pattern are the open and setVersion APIs. In the case of the setVersion handler we have to use: * event.target.result.oncomplete It would be nice to use only one pattern all the time. Israel What do you think about the idea of having a consistent/common access pattern for accessing the transaction inside most of our event handlers (i.e. inside setVersion but not open). This will always guaranteed a good (not null) transaction handler developers can always count on. Israel
[Bug 13162] New: The notes really do need to be cleaned up to be made explicit. Like WTH does this actually say? The fail the WebSocket connection algorithm invokes the close the WebSocket connect
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13162 Summary: The notes really do need to be cleaned up to be made explicit. Like WTH does this actually say? The fail the WebSocket connection algorithm invokes the close the WebSocket connection algorithm, which then establishes that the WebSocket connection is clo 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 notes really do need to be cleaned up to be made explicit. Like WTH does this actually say? The fail the WebSocket connection algorithm invokes the close the WebSocket connection algorithm, which then establishes that the WebSocket connection is closed, which fires the close event as described I think it should read: The [WebSocket Failure Algorithm] invokes the [WebSocket Close Algorithm], which then establishes that the WebSocket connection is closed, which then fires the close event. 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.
Re: Mutation events replacement
On Wed, Jul 6, 2011 at 2:47 AM, Olli Pettay olli.pet...@helsinki.fi wrote: On 07/06/2011 08:14 AM, James Robinson wrote: On Tue, Jul 5, 2011 at 5:51 PM, Ojan Vafai o...@chromium.org mailto:o...@chromium.org wrote: On Tue, Jul 5, 2011 at 5:36 PM, Ryosuke Niwa rn...@webkit.org mailto:rn...@webkit.org wrote: On Tue, Jul 5, 2011 at 5:27 PM, Rafael Weinstein rafa...@google.com mailto:rafa...@google.com wrote: It seems like these are rarified enough cases that visual artifacts are acceptable collateral damage if you do this. [Put another way, if you care enough about the visual polish of your app that you will put energy into avoiding flickr, you probably aren't using alert and showModalDialog anyway]. Also, it's up to the app when to do it, so it's entirely in its control (and thus avoid visual artifacts). Given that we don't provide an API to control paint in general, I'm not convinced that we should add such a requirement in the DOM mutation event spec. Many of the use-cases for mutation events (e.g. model-driven views) are poorly met if we don't give some assurances here. Note that this is a problem with both proposals. Work done in (at least some) mutation observers is delayed. If a sync paint occurs before it, it's work won't be reflected on the screen. Right. Maybe we can add a note saying that the user agents are recommended not to paint before all mutation observers are called. I don't think we should make this a requirement. There may be a middle ground that isn't so hard to for browser vendors implement interoperably. Can we require no repaint except in the presence of a specific list synchronous API calls? I'm sure that's too simplistic, but I'm hoping someone with more experience can chime in with something that might actually be a plausible requirement. HTML specifies to a limited extent when painting can happen with regard to what it defines as tasks: http://www.whatwg.org/specs/**web-apps/current-work/** multipage/webappapis.html#**processing-model-2http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#processing-model-2 See step 5 - update the rendering is equivalent to painting. Ignoring step (2) which relates to the storage mutex, this description is accurate. No browser updates the rendering after invoking every single task, but I'm pretty sure that no modern browser updates the rendering at any other time. Note that a few APIs such as showModalDialog() invoke this algorithm: http://www.whatwg.org/specs/**web-apps/current-work/** multipage/webappapis.html#**spin-the-event-loophttp://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#spin-the-event-loop which effectively starts up a second event loop within the processing of a task, meaning that the browser can paint while the task that resulted in the showModalDialog() call is still running. Authors who are using showModalDialog() are being extremely user-hostile so I don't think we need to accomodate them. Sync XHR is one case when at least some browsers do repainting. And yes, sync XHR is probably as user-hostile as showModalDialog(), but unfortunately it is used quite often. What browser(s) do this? That sounds like a bug in those implementation(s), and not something we should worry about standards-wise. - James One question I have with regards to the proposed processing model is whether to define this in terms of entering script or in terms of 'tasks' in the HTML sense. For example, asynchronous DOM events are typically set up by queueing a single task to fire the event, but there might be multiple event listeners registered for that one event that would all be fired as part of the same task. If we were to define things in terms of tasks, then I think Rafael's proposal is similar to extending step 4 provide a stable state of the event loop algorithm in order to notify observers before proceeding to step 5. This would mean that if multiple click handlers were registered on an element and the user clicked on it, all of the event handlers would run, then the mutation observers would run, then the browser would be free to paint if it chose to. An alternative approach would be to hook on calling in to script (http://www.whatwg.org/specs/**web-apps/current-work/** multipage/webappapis.html#**calling-scriptshttp://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#calling-scripts ) and run the observers after each script invocation. This means that if multiple handlers were registered for an event then the first handler would be invoked, then observers notified, then the second handler invoked, etc. It would still have
Re: Mutation events replacement
On 07/06/2011 09:12 PM, James Robinson wrote: On Wed, Jul 6, 2011 at 2:47 AM, Olli Pettay olli.pet...@helsinki.fi mailto:olli.pet...@helsinki.fi wrote: On 07/06/2011 08:14 AM, James Robinson wrote: On Tue, Jul 5, 2011 at 5:51 PM, Ojan Vafai o...@chromium.org mailto:o...@chromium.org mailto:o...@chromium.org mailto:o...@chromium.org wrote: On Tue, Jul 5, 2011 at 5:36 PM, Ryosuke Niwa rn...@webkit.org mailto:rn...@webkit.org mailto:rn...@webkit.org mailto:rn...@webkit.org wrote: On Tue, Jul 5, 2011 at 5:27 PM, Rafael Weinstein rafa...@google.com mailto:rafa...@google.com mailto:rafa...@google.com mailto:rafa...@google.com wrote: It seems like these are rarified enough cases that visual artifacts are acceptable collateral damage if you do this. [Put another way, if you care enough about the visual polish of your app that you will put energy into avoiding flickr, you probably aren't using alert and showModalDialog anyway]. Also, it's up to the app when to do it, so it's entirely in its control (and thus avoid visual artifacts). Given that we don't provide an API to control paint in general, I'm not convinced that we should add such a requirement in the DOM mutation event spec. Many of the use-cases for mutation events (e.g. model-driven views) are poorly met if we don't give some assurances here. Note that this is a problem with both proposals. Work done in (at least some) mutation observers is delayed. If a sync paint occurs before it, it's work won't be reflected on the screen. Right. Maybe we can add a note saying that the user agents are recommended not to paint before all mutation observers are called. I don't think we should make this a requirement. There may be a middle ground that isn't so hard to for browser vendors implement interoperably. Can we require no repaint except in the presence of a specific list synchronous API calls? I'm sure that's too simplistic, but I'm hoping someone with more experience can chime in with something that might actually be a plausible requirement. HTML specifies to a limited extent when painting can happen with regard to what it defines as tasks: http://www.whatwg.org/specs/__web-apps/current-work/__multipage/webappapis.html#__processing-model-2 http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#processing-model-2 See step 5 - update the rendering is equivalent to painting. Ignoring step (2) which relates to the storage mutex, this description is accurate. No browser updates the rendering after invoking every single task, but I'm pretty sure that no modern browser updates the rendering at any other time. Note that a few APIs such as showModalDialog() invoke this algorithm: http://www.whatwg.org/specs/__web-apps/current-work/__multipage/webappapis.html#__spin-the-event-loop http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#spin-the-event-loop which effectively starts up a second event loop within the processing of a task, meaning that the browser can paint while the task that resulted in the showModalDialog() call is still running. Authors who are using showModalDialog() are being extremely user-hostile so I don't think we need to accomodate them. Sync XHR is one case when at least some browsers do repainting. And yes, sync XHR is probably as user-hostile as showModalDialog(), but unfortunately it is used quite often. What browser(s) do this? That sounds like a bug in those implementation(s), How so? I don't know any spec which disallows this. Gecko may repaint while handling sync XHR - similar to alert or other modal dialogs. and not something we should worry about standards-wise. - James
Re: [WebIDL] Exceptions
On Wed, Jul 6, 2011 at 4:06 AM, Anne van Kesteren ann...@opera.com wrote: So with Web IDL going to Last Call does this mean that the exception model outlined in http://www.w3.org/Bugs/Public/show_bug.cgi?id=10623#c8 is the way forward? I.e. we introduce new exception interfaces in DOM Core for all the different exception types and update all other specifications that use DOM Core to dispatch those exceptions instead (and they are somewhat backwards compatible because they inherit from DOMException and therefore still have the code member). I guess there is no particular rush on this; I am mainly wondering whether other editors are aware of this change and agree with it. I absolutely think this is the way forward. I hope to get IndexedDB updated before it goes to last call. / Jonas
[Bug 12179] We should spec the order in which version change events fire
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12179 Eliot Graff eliot...@microsoft.com changed: What|Removed |Added Status|NEW |RESOLVED CC||eliot...@microsoft.com Resolution||FIXED --- Comment #1 from Eliot Graff eliot...@microsoft.com 2011-07-06 18:36:15 UTC --- Added the following sentence to IDBDatabase.setVersion(): Within a given page, events fire in the order that the IDBDatabase objects were 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: [eventsource] Is Server-Sent Events ready for LC? ; deadline July 1
On 7/6/11 1:55 PM, ext Ian Hickson wrote: On Tue, 5 Jul 2011, Arthur Barstow wrote: Any comments re the priority of this bug, in particular if it must be addressed before publishing a new LCWD? Can we please stop letting the LCWD/CR/PR process nonsense drive the prioritisation of the bug fixing process? This is getting ridiculous. (I will respond to the TR publication process issue separately with a different Subject:) Regarding the SSE spec, at least one WG member said moving the SSE spec to LC is important. As such, it seems appropriate (and not nonsense nor ridiculous) to then effectively ask the group (the To: on my e-mail included public-webapps too) is moving this spec to LC important enough for you to submit fixes for the open bugs?. I think we have other capable people in WebApps that can fix bugs and thus lighten your load. Do you oppose others submitting fixes to your spec bugs? -AB
Where to discuss TR process issues? [Was: Re: [eventsource] Is Server-Sent Events ready for LC? ; deadline July 1
Hi Hixie, On 7/6/11 1:55 PM, ext Ian Hickson wrote: On Tue, 5 Jul 2011, Arthur Barstow wrote: Any comments re the priority of this bug, in particular if it must be addressed before publishing a new LCWD? Can we please stop letting the LCWD/CR/PR process nonsense drive the prioritisation of the bug fixing process? This is getting ridiculous. I think we all realize you have issues with the W3C's TR process. I actually agree with some of your view points [at least as I understand them ;-)] and I think they should be discussed with a different set of people then WebApps. For instance, the so-called Advisory Board [AdvBrd] manages the evolution of the W3C Process Document, yet I suspect very few of them are subscribed to public-webapps. So, rather than continuing to complain about this process on public-webapps, I would appreciate it if you would please move TR process type discussions to another Public list. IJ, PLH - what Public list is appropriate for discussions about the TR process? -AB [AdvBrd] http://www.w3.org/2002/ab/
Re: Mutation events replacement
On Wed, Jul 6, 2011 at 1:14 AM, James Robinson jam...@google.com wrote: No browser updates the rendering after invoking every single task, but I'm pretty sure that no modern browser updates the rendering at any other time. Testcase: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1063 I can confirm that in IE9, Firefox 6.0a2, and Chrome 14 dev, Hi! is never visible. In Opera 11.50, Hi! becomes visible immediately, and is replaced five seconds later by Bye!. But I'm not surprised that this would cause compat issues for Opera, even though it increases responsiveness.
Re: [WebIDL] Exceptions
On Wed, Jul 6, 2011 at 7:06 AM, Anne van Kesteren ann...@opera.com wrote: So with Web IDL going to Last Call does this mean that the exception model outlined in http://www.w3.org/Bugs/Public/show_bug.cgi?id=10623#c8 is the way forward? I.e. we introduce new exception interfaces in DOM Core for all the different exception types and update all other specifications that use DOM Core to dispatch those exceptions instead (and they are somewhat backwards compatible because they inherit from DOMException and therefore still have the code member). I guess there is no particular rush on this; I am mainly wondering whether other editors are aware of this change and agree with it. 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. Moreover, I don't even think behavior in that case is defined. If I call foo.appendChild(bar) and it throws, is the exception from the window where the method was called, or the one foo is associated with, or the one bar is associated with? Browsers other than Gecko seem to agree it's the one foo is associated with (http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1064), and Gecko is just buggy, but is this specced anywhere? I don't see it in DOM Core. I don't see why we need the extra classes. What's the advantage over just adding the .name attribute, or something equivalent, and not adding new classes? Just consistency with ES, or something else too?
Re: [eventsource] Is Server-Sent Events ready for LC? ; deadline July 1
On Wed, 6 Jul 2011, Arthur Barstow wrote: Do you oppose others submitting fixes to your spec bugs? If someone is interested in submitting fixes, they are welcome to contact me, so that I can work with them to work out how we can get something set up. There are a number of people who have done this (e.g. Aryeh's atob()/btoa() spec text, Ian Fette's adoption of the WebSockets protocol, Adam Barth's work on file type identification). Exactly how it should be done, and whether it's worth it to do it at all, depends on what kinds of edits we're talking about. Merely checking things in to dev.w3.org will cause CVS conflicts when I next run the post-processing scripts. I don't recommend it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Where to discuss TR process issues? [Was: Re: [eventsource] Is Server-Sent Events ready for LC? ; deadline July 1
On Wed, 6 Jul 2011, Arthur Barstow wrote: So, rather than continuing to complain about this process on public-webapps, I would appreciate it if you would please move TR process type discussions to another Public list. I'm not asking to have a discussion about it at all; I'm asking that you stop trying to prioritise my work based on it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Where to discuss TR process issues? [Was: Re: [eventsource] Is Server-Sent Events ready for LC? ; deadline July 1
On 6 Jul 2011, at 2:41 PM, Arthur Barstow wrote: Hi Hixie, On 7/6/11 1:55 PM, ext Ian Hickson wrote: On Tue, 5 Jul 2011, Arthur Barstow wrote: Any comments re the priority of this bug, in particular if it must be addressed before publishing a new LCWD? Can we please stop letting the LCWD/CR/PR process nonsense drive the prioritisation of the bug fixing process? This is getting ridiculous. I think we all realize you have issues with the W3C's TR process. I actually agree with some of your view points [at least as I understand them ;-)] and I think they should be discussed with a different set of people then WebApps. For instance, the so-called Advisory Board [AdvBrd] manages the evolution of the W3C Process Document, yet I suspect very few of them are subscribed to public-webapps. So, rather than continuing to complain about this process on public-webapps, I would appreciate it if you would please move TR process type discussions to another Public list. IJ, PLH - what Public list is appropriate for discussions about the TR process? There is no list with a public archive. One thing to do is use process-issues and cc www-archive if you wish. Ian -AB [AdvBrd] http://www.w3.org/2002/ab/ -- Ian Jacobs (i...@w3.org)http://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447
[Bug 11406] [IndexedDB] IDBDatabase.transaction needs to specify exception for invalid mode parameter
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11406 Eliot Graff eliot...@microsoft.com changed: What|Removed |Added Status|NEW |RESOLVED CC||eliot...@microsoft.com Resolution||FIXED --- Comment #3 from Eliot Graff eliot...@microsoft.com 2011-07-06 22:26:33 UTC --- Added the following to IDBDatabase.transaction IDBDatabaseSync.transaction: NON_TRANSIENT_ERRThe value for the mode parameter is invalid. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [WebIDL] Exceptions
On Wed, Jul 6, 2011 at 2:23 PM, Aryeh Gregor simetrical+...@gmail.com wrote: On Wed, Jul 6, 2011 at 7:06 AM, Anne van Kesteren ann...@opera.com wrote: So with Web IDL going to Last Call does this mean that the exception model outlined in http://www.w3.org/Bugs/Public/show_bug.cgi?id=10623#c8 is the way forward? I.e. we introduce new exception interfaces in DOM Core for all the different exception types and update all other specifications that use DOM Core to dispatch those exceptions instead (and they are somewhat backwards compatible because they inherit from DOMException and therefore still have the code member). I guess there is no particular rush on this; I am mainly wondering whether other editors are aware of this change and agree with it. 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. Moreover, I don't even think behavior in that case is defined. If I call foo.appendChild(bar) and it throws, is the exception from the window where the method was called, or the one foo is associated with, or the one bar is associated with? Browsers other than Gecko seem to agree it's the one foo is associated with (http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1064), and Gecko is just buggy, but is this specced anywhere? I don't see it in DOM Core. I don't see why we need the extra classes. What's the advantage over just adding the .name attribute, or something equivalent, and not adding new classes? Just consistency with ES, or something else too? This is indeed a good point. The main reason for me was consistency with ES. But I'm not sure why ES was designed the way it is. Generally it seems like multiple globals wasn't kept in mind a lot when ES was designed, though obviously this is a problem for ES on the web. Would love to hear from ES people that surely has spent more time thinking about exceptions than me. / Jonas
Re: Mutation events replacement
On Wed, Jul 6, 2011 at 1:58 PM, Aryeh Gregor simetrical+...@gmail.comwrote: On Wed, Jul 6, 2011 at 1:14 AM, James Robinson jam...@google.com wrote: No browser updates the rendering after invoking every single task, but I'm pretty sure that no modern browser updates the rendering at any other time. Testcase: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1063 I can confirm that in IE9, Firefox 6.0a2, and Chrome 14 dev, Hi! is never visible. In Opera 11.50, Hi! becomes visible immediately, and is replaced five seconds later by Bye!. But I'm not surprised that this would cause compat issues for Opera, even though it increases responsiveness. That's just insanity from Opera. I imagine that they will converge to what other browsers and the spec say, propose modifications to the spec to make their behavior conformant (highly unlikely), or remain intentionally non-conformant in which case we can safely ignore the behavior. - James
RE: [XHR2] Blobs, names and FormData
Just catching up with this thread. We ran into the same problem last week while investigating FormData and XHR. Since FormData is designed to allow XHR to interact with existing form end-points that usually required a navigation, we've found that few of them have been tested with empty filenames. On Wednesday, June 29, 2011 9:35 AM, Alfonso Martínez de Lizarrondo wrote: All I want is a way for the web page to state that when a Blob is used in a FormData object it should be send to the server with a proposed filename. No sniffing. No guessing. It's up to the script to suggest a correct filename (if it wants), or use whatever is the default filename used by the browser (Blob23g22g3024j23g209gj3g and the like, extensionless) My first simple approach was: formdata.append(elementName, blob, picture.png); Jonas has suggested instead blobbuilder.getFile(picture.png) I don't mind one way or another, or something else you think it's better. I was about to send a similar proposal. We'd prefer to add an optional argument to append that specifies the filename. This is the smallest change to implementations and doesn't require developers to understand the BlobBuilder in order to use FormData. Having to create another reference to a Blob and probably deal with managing a File and Blob both pointing to the same data seems unnecessarily involved when all we want is to get the filename into the FormData object. On Thursday, June 30, 2011 12:28 AM, Julian Reschke wrote: On 2011-06-29 18:34, Alfonso Martínez de Lizarrondo wrote: ... No. All I want is a way for the web page to state that when a Blob is used in a FormData object it should be send to the server with a proposed filename. No sniffing. No guessing. It's up to the script to suggest a correct filename (if it wants), or use whatever is the default filename used by the browser (Blob23g22g3024j23g209gj3g and the like, extensionless) ... In which case there should also be a way to send the actual media type, no? Yes, the blob has a content type so the correct type can also be sent.
Re: [WebIDL] Exceptions
On Jul 6, 2011, at 5:05 PM, Jonas Sicking wrote:
On Wed, Jul 6, 2011 at 2:23 PM, Aryeh Gregor simetrical+...@gmail.com wrote:
On Wed, Jul 6, 2011 at 7:06 AM, Anne van Kesteren ann...@opera.com wrote:
So with Web IDL going to Last Call does this mean that the exception model
outlined in http://www.w3.org/Bugs/Public/show_bug.cgi?id=10623#c8 is the
way forward? I.e. we introduce new exception interfaces in DOM Core for all
the different exception types and update all other specifications that use
DOM Core to dispatch those exceptions instead (and they are somewhat
backwards compatible because they inherit from DOMException and therefore
still have the code member).
I guess there is no particular rush on this; I am mainly wondering whether
other editors are aware of this change and agree with it.
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.
Moreover, I don't even think behavior in that case is defined. If I
call foo.appendChild(bar) and it throws, is the exception from the
window where the method was called, or the one foo is associated with,
or the one bar is associated with? Browsers other than Gecko seem to
agree it's the one foo is associated with
(http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1064),
and Gecko is just buggy, but is this specced anywhere? I don't see it
in DOM Core.
I don't see why we need the extra classes. What's the advantage over
just adding the .name attribute, or something equivalent, and not
adding new classes? Just consistency with ES, or something else too?
This is indeed a good point. The main reason for me was consistency
with ES. But I'm not sure why ES was designed the way it is. Generally
it seems like multiple globals wasn't kept in mind a lot when ES was
designed, though obviously this is a problem for ES on the web.
Would love to hear from ES people that surely has spent more time
thinking about exceptions than me.
/ Jonas
From an Object-oriented design perspective I always discourage use of
instanceof tests. The problem mentioned here by a Aryeh is a good example why,
you may have semantically equivalent objects that are instances of different
classes in different hierarchies. This is particularly true for dynamic
languages such as ES. Given that DOM Core is explicitly an environment that
provides multiple global objects (and hence multiple semantically equivalent
objects) it seems particularly unwise for it to depend upon or even recommend
using such tests.
ECMAScript itself does not have a very rich set of exception classes and its
hierarchy is essentially flat. If you ignore instanceof testing then all the
specialized exception constructors (TypeError, RangeError, ReferenceError,
etc.) really provide is the ability to say:
throw RangeError(my message);
instead of
var excpt = Error(my message);
excpt.name = RangeError;
throw excpt;
In other words, a more concise way to set the name property of a new exception
that is about to be thrown. Given that the various DOMErrors are thrown by the
DOM implementation, I don't think that ease of throwing is a relevant issues.
As a further point of reference I've designed several exception hierarchies for
a couple of languages and used them in many others. My experience is that
while some developers love to put time into designing elaborate hierarchies of
exceptions, in practice hierarchical exception structures are seldom exploited
by actual application code. A few flat exceptions are more useful then a
complex hierarchy that nobody ever remembers.
In the case of the the DOM I think a single exception type where different
kinds of exceptions are discriminated by their name property would be much
better then a bunch of frame dependent exception constructors.
I'd much prefer to see code that looks like:
try {doSomeDOMStuff() }
catch (e) {
switch (e.name) {
case NoNotificationAllowedError: ...; break;
case HierarchyRequestError: ...; break;
default: throw e
}
}
rather than:
try {doSomeDOMStuff() }
catch (e) {
if (e instanceof NoNotificationAllowError) {...}
else if (e instanceof HierarchyRequestError) {...}
else throw e;
}
The latter invites cross-frame multiple global issues. The former is totally
immune to them.
Re: [WebIDL] Exceptions
On Jul 6, 2011, at 5:05 PM, Jonas Sicking wrote: On Wed, Jul 6, 2011 at 2:23 PM, Aryeh Gregor simetrical+...@gmail.com wrote: On Wed, Jul 6, 2011 at 7:06 AM, Anne van Kesteren ann...@opera.com wrote: So with Web IDL going to Last Call does this mean that the exception model outlined in http://www.w3.org/Bugs/Public/show_bug.cgi?id=10623#c8 is the way forward? I.e. we introduce new exception interfaces in DOM Core for all the different exception types and update all other specifications that use DOM Core to dispatch those exceptions instead (and they are somewhat backwards compatible because they inherit from DOMException and therefore still have the code member). I guess there is no particular rush on this; I am mainly wondering whether other editors are aware of this change and agree with it. 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. You have to remember that exceptions came to JS in ES3, the Third Edition of ECMA-262, and they followed Java's model but without static nominal types. This resulted in the cross-window/frame confusion problem, but ES3 people did not take on specifying multiple globals, and they weren't active multi-window/frame JS hackers, so they missed this. (Termination-style exception handling doesn't scale anyway, but that's another complaint for another time.) Moreover, I don't even think behavior in that case is defined. If I call foo.appendChild(bar) and it throws, is the exception from the window where the method was called, or the one foo is associated with, or the one bar is associated with? Browsers other than Gecko seem to agree it's the one foo is associated with (http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1064), and Gecko is just buggy, but is this specced anywhere? I don't see it in DOM Core. Gecko is buggy if it is using the dynamic scope. Please file that bug and cc: me. I don't see why we need the extra classes. What's the advantage over just adding the .name attribute, or something equivalent, and not adding new classes? Just consistency with ES, or something else too? This is indeed a good point. The main reason for me was consistency with ES. But I'm not sure why ES was designed the way it is. Generally it seems like multiple globals wasn't kept in mind a lot when ES was designed, though obviously this is a problem for ES on the web. See above. Would love to hear from ES people that surely has spent more time thinking about exceptions than me. There's nothing deep here. You smell something bad in the design that mixes instanceof and multiple globals, so I agree the best course is to avoid perpetuating it by imitation. /be
[FileAPI] FileReader.readAsXXX when pased null
http://dev.w3.org/2006/webapi/FileAPI/#reading-a-file What is the expected behaviour for FileReader.readAsXXX(null)? Currently I think both IE10 and Chrome fail silently and there are no events fired whereas Firefox appears to throw an internal NS_ERROR_INVALID_POINTER exception. 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? Adrian.
Re: [WebIDL] Exceptions
On 7/6/2011 6:06 PM, Allen Wirfs-Brock wrote:
I'd much prefer to see code that looks like:
try {doSomeDOMStuff() }
catch (e) {
switch (e.name) {
case NoNotificationAllowedError: ...; break;
case HierarchyRequestError: ...; break;
default: throw e
}
}
Any work with DOM API (at least in Firefox) makes even this case
impractical. You'll be luck if the exception has *any* meaningful content.
jjb
Re: [WebIDL] Exceptions
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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [indexeddb] IDBRequest.transaction property set to null
I'd be OK with it. Jonas, what do you think? J On Wed, Jul 6, 2011 at 10:27 AM, Israel Hilerio isra...@microsoft.comwrote: On Tuesday, June 28, 2011 11:21 AM, Israel Hilerio wrote: On Monday, June 27, 2011 11:59 PM, Jeremy Orlow wrote: On Thu, Jun 23, 2011 at 2:21 PM, Israel Hilerio isra...@microsoft.com wrote: In the definition of IDBRequest.transaction it stipulates that This property can be null for certain requests, such as for request returned from IDBFactory.open and IDBDatabase.setVersion. Based on this we understand that the following handlers will set the transaction property to null: * setVersion onsuccess handler * setVersion onerror handler * setVersion onblock handler * open onsuccess handler * open onerror handler Are there any other times when this property should be set to null or is this the complete list? We couldn't think of any other times when this applied but wanted to check. I believe this is correct. Also, in the setVersion case, if we're setting the result property to its active transaction, why are we setting the transaction property to null instead of the same active transaction? I know Jonas and I talked about this, but I don't remember the reasoning for sure. One thing I can think of off the top of my head is that it's weird that it'd start off null and then be set later. Also, it would be duplicate data given that .result is also set to the transaction. Is there any strong reason to set it? J The main reason was to keep a consistent calling pattern inside our event handlers: * event.target.transaction.oncomplete The only exception to this pattern are the open and setVersion APIs. In the case of the setVersion handler we have to use: * event.target.result.oncomplete It would be nice to use only one pattern all the time. Israel What do you think about the idea of having a consistent/common access pattern for accessing the transaction inside most of our event handlers (i.e. inside setVersion but not open). This will always guaranteed a good (not null) transaction handler developers can always count on. Israel
Re: [FileAPI] FileReader.readAsXXX when pased null
On 7/6/11 7:54 PM, Adrian Bateman wrote: http://dev.w3.org/2006/webapi/FileAPI/#reading-a-file What is the expected behaviour for FileReader.readAsXXX(null)? Currently I think both IE10 and Chrome fail silently and there are no events fired whereas Firefox appears to throw an internal NS_ERROR_INVALID_POINTER exception. 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? 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!). -- A*
Re: [indexeddb] Calling update on a cursor index with a unique value constraint
On Wed, Jul 6, 2011 at 10:06 AM, Israel Hilerio isra...@microsoft.comwrote: 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. Most (if not all?) of the times Chrome throws an UNKNOWN_ERR, it's because the functionality simply hasn't been implemented yet. 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. Btw, ObjectStore.add()'s exception section doesn't mention CONSTRAINT_ERR though it probably should. J
Re: [FileAPI] Updates to FileAPI Editor's Draft
On 6/30/11 6:01 PM, Gregg Tavares (wrk) wrote: On Tue, Jun 21, 2011 at 10:17 AM, Arun Ranganathan a...@mozilla.com mailto:a...@mozilla.com 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 thecharsetwith a single U+FFFD character [Unicode http://dev.w3.org/2006/webapi/FileAPI/#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). Can we list your three behaviors here, just so we get them on record? Which behavior do you think is ideal? More importantly, is substituting U+FFFD and defaulting to UTF-8 good enough for your scenario above? The 3 off the top of my head were 1) Throw an exception. (content not valid for encoding) 2) Remap bad codes to some other value (sounds like that's the one above) 3) Remove the bad character I see you've listed a 4th, Ignore the encoding on error, assume utf-8. That one seems problematic because of partial reads. If you are decoding as shift-jis, have returned a partial read, and then later hit a bad code point, the stuff you've seen previously will all need to change by switching to no encoding. I'd chose #2 which it sounds like is already the case according the spec. This is the case in the spec. currently, but: Regardless of what solution is chosen is there a way for me to know something was lost? I don't think so, actually. And I'm not entirely sure how we can allow for such a way, unless we throw an error or something. 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'm assuming by MUST condition you mean a UA doesn't have to support partial reads at all, not that how partial reads work shouldn't be specified. Here's an example. Assume we stick with unknown characters get mapped to U+FFFD. Assume my stream is utf8 and in hex the bytes are. E3 83 91 E3 83 91 That's 2 code points of 0x30D1. Now assume the reader has only read the first 5 bytes. Should the partial results be (a) filereader.result.length == 1 where the content is 0x30D1 or should the partial result be (b) filereader.result.length == 2 where the content is 0x30D1, 0xFFFD because at that point the E3 83 at the end of the partial result is not a valid codepoint I think the spec should specify that if the UA supports partial reads it should follow example (a) OK. I think the spec. needs more bolstering here. Thanks for your example. This makes it clearer. -- A*
Re: [FileAPI] FileReader.readAsXXX when pased null
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. -- Cameron McCormack ≝ http://mcc.id.au/
