Re: [whatwg] Request: window.postMessage should be async
(Apologies if the threading on this gets messed up. I was not subscribed to the list when the original message was sent.) I want to paint Eric's scenario more strongly, because it seems like people think if it would rarely blow up then it doesn't matter. If you want to handle _any_ request sent by a synchronous postMessage, and you aren't a cowboy programmer, you _must_ either call no functions, or use a setTimeout() continuation. You CANNOT know how deep your caller's stack is, so you CANNOT safely do anything that could add to the stack depth. It doesn't matter if the stack will not _commonly_ be too deep, or if it isn't too deep for the callers that you know about right now -- it might be too deep at some point (after someone else changes the caller code, for example), and your sync handler will blow up. And the very sorts of things you'd want postMessage for are frequently cases where others will write mashups and use your code in ways you hadn't planned. For this reason, I think talking about the common case misses the point -- a sync API is completely useless to anyone trying to write _any_ serious code defensively, large app or small, because it cannot be made safe except by using setTimeout to make it async, at which point synchronicity has bought you nothing. On the contrary, it has added great risk, because any coder who fails to understand the threat posed here and fails to transform all postMessage handlers into async ones risks his code blowing up. I prefer not to have APIs that force you to take action if you don't want to shoot yourself in the head. If you're still not convinced that coders would care, remember that stack depths vary by interpreter, too. I believe in pocket IE you have a ridiculously small stack depth [12?]. On this kind of platform, the recursion limits get hit in the common case rather than the uncommon, even in today's code without postMessage(). While other mobile devices may be a little more forgiving, smaller recursion limits are always going to be more likely on embedded devices, and embedded devices are just going to get more popular. And as Eric mentioned, even on desktop browsers, apps of any reasonable size (like gmail) already jump through hoops TODAY to avoid getting near any stack limits. This isn't some vague theoretical concern. It's very real and already impacts web apps. So if we're trying to write APIs to enable even more powerful, more robust web applications, sync postMessage completely fails to accomplish that. Below I have some less important replies to various points in Jeff's post. Jeff Walden wrote: Eric Seidel wrote: 1. JS content authors will want an async API. Sometimes, for the large applications; small apps won't care. Besides the comments I wrote above that amount to all the time, for all large apps, and most small ones too, you will want async for safety: I admit to spending more time in the C++ space than the JS space, but it seems like in most cases where you'd actually want to call postMessage, you don't really know how long the target may take to act on your request, and you don't necessarily want to block. The async use case seems more common to me. (Incidentally, I also find the name bizarre. If it's a sync API, why not callFunction or at the very least sendMessage, which [in Windows land] doesn't imply asynchronicity the way postMessage does [in both the Windows and common-english-usage senses of post].) As you note, the workaround of immediately packaging up a setTimeout continuation isn't difficult. I tend to think worrying about the N-1 case is designing a bit too much for the special cases, personally. Special cases aren't special enough to break the rules.[0] Again, ignoring my this isn't a special case comments: Given the number of websites relying on this feature right now (0?), how do you know what the special cases are? I'm skeptical that async usage is so exceptional as you seem to think. Besides my own intuition above, the JS developers at Google I've spoken to have all been surprised postMessage is currently specified to be synchronous -- they were all expecting async. setTimeout may not be terribly difficult, but if it's the common case, it also forces the JS engine to jump through hoops that it doesn't need to for no benefit, forces programmers to contort their app in ways that don't express their intent as well, and is less obvious to someone newly approaching the API. Further, nothing says browser implementations must or will continue to enforce hard limits on recursion. Nothing says they won't, either. And when the status quo is that they do, I will believe this restriction will disappear when I see it. Even if, say, SpiderMonkey stops enforcing a recursion limit, so what? If I want my app to actually run everywhere, I need to assume the limit is present until _every_ UA gets rid of it. Surely you agree the chances of that happening are small. See my comments at top
Re: [whatwg] Request: window.postMessage should be async
Peter, On Sat, Apr 5, 2008 at 12:38 AM, Peter Kasting [EMAIL PROTECTED] wrote: Or, if you like, take the position that the argument should stay optional, and if someone for some reason doesn't have to care about security (?!), they can avoid passing it. Although I'm not sure this is a particularly great idea :) If the caller doesn't care who receives the message, it makes sense to omit the targetOrigin parameter. For example, if Google Maps were to implement it's map gadget using postMessage, it would be happy to send messages to and receive messages from any web page. Are you sure? I'm reading the docs in section 4.1.4, and it seems to say that this is only true for changes within the unit of related browsing contexts. If it is possible to get a reference to a Window outside this group, then your statement is untrue. But I'm not sure whether that's possible. It is not possible to obtain a JavaScript pointer to a window outside your unit of related browsing contexts. In most browsers, it is possible to script windows outside your unit of related browsing contexts via window.open(javascript:..., foo), but (1) this method can't pass pointers and (2) HTML 5 does not promise that this will succeed: ...and the user agent determines that the two browsing contexts are related enough that it is ok if they reach each other ... http://www.whatwg.org/specs/web-apps/current-work/#the-rules Adam
[whatwg] Hyperlinks with |title| attribute
Should (or may) user agents display the content of the |title| attribute of an |a| element in the GUI window caption (if the window manager used supports such), when the user followed the link and the retrieved resource is in a format that does not support specifying a title by itself (e.g. many image formats)? What about resources that could have a title but do not (e.g. a non- conformant HTML document without |title| element)? The alternatives are to display nothing or the name of the resource (file name), the final part of the path.
[whatwg] Listing element
The |listing| element is currently not defined in HTML5, but its parsing is said to be the same as for |pre|. Will |listing| be included some day or will it be left out, because |code| nested in | pre| provides the same semantics already?
Re: [whatwg] Listing element
On Sat, 05 Apr 2008 16:37:42 +0200, Christoph Päper [EMAIL PROTECTED] wrote: The |listing| element is currently not defined in HTML5, but its parsing is said to be the same as for |pre|. Will |listing| be included some day or will it be left out, because |code| nested in |pre| provides the same semantics already? It will not be conforming for authors to use it. The parsing section simply has mention of some elements authors will not be allowed to use, such as plaintext and listing, because user agents need to handle them for Web compatibility. There is a note to that effect in the specification. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Request: window.postMessage should be async
Peter Kasting wrote: It doesn't matter if the stack will not _commonly_ be too deep, or if it isn't too deep for the callers that you know about right now -- it might be too deep at some point (after someone else changes the caller code, for example), and your sync handler will blow up. So put it in the contract for the API you're designing on top of postMessage that you shouldn't call the method without some generous number of frames available. (Doesn't assuming you'll need to consume lots of stack frames work against your argument that postMessage receivers will usually do computation out-of-band anyway?) I don't see why this problem requires a technical solution rather than a social one. (I should have mentioned this in the first message, thanks for prompting me to bring it up now.) And the very sorts of things you'd want postMessage for are frequently cases where others will write mashups and use your code in ways you hadn't planned. No, but *they* plan how they're going to use it, and they can adjust to not call with near-full stacks. For this reason, I think talking about the common case misses the point -- a sync API is completely useless to anyone trying to write _any_ serious code defensively, large app or small, because it cannot be made safe except by using setTimeout to make it async, at which point synchronicity has bought you nothing. safe is a misnomer. There's nothing security-related about this, except in the case that you write your code and create some inconsistency that a stack overflow leaves around which causes vulnerabilities (but really, you should have been careful about that already, e.g. what if the browser naturally runs out of memory at that point and stops your script? a malicious page could make this happen, with some effort). All that happens is an exception, and you can catch and deal with it in the rare case that it happens. I prefer not to have APIs that force you to take action if you don't want to shoot yourself in the head. Not catching an exception isn't shooting yourself in the head, it's just doing nothing; I think this is hyperbole. If you're still not convinced that coders would care, remember that stack depths vary by interpreter, too. I believe in pocket IE you have a ridiculously small stack depth [12?]. This surprises me, but realistically, no device is going to be able to afford to have such a low stack depth going forward anyway. Color me skeptical that mobile devices will have such small recursion limits in the foreseeable future. Moore makes many problems go away fairly quickly; I don't think we should penalize tomorrow for a limitation of today. Also, just because stack overflow is more common on mobile devices doesn't make stack overflow not a special case. Given the number of websites relying on this feature right now (0?), how do you know what the special cases are? Not the special case, a special case: stack overflow. I don't think a decent-sized percentage of web developers worry about stack overflow significantly more often than they worry about it from thinkos that accidentally cause infinite recursion. Jeff
Re: [whatwg] Hyperlinks with |title| attribute
On Sat, 5 Apr 2008, Christoph P�per wrote: Should (or may) user agents display the content of the |title| attribute of an |a| element in the GUI window caption (if the window manager used supports such), when the user followed the link and the retrieved resource is in a format that does not support specifying a title by itself (e.g. many image formats)? What about resources that could have a title but do not (e.g. a non-conformant HTML document without |title| element)? The alternatives are to display nothing or the name of the resource (file name), the final part of the path. I do not believe this is in scope for the specification. I don't see an interoperability issue here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Listing element
On Sat, 5 Apr 2008, Christoph P�per wrote: The |listing| element is currently not defined in HTML5, but its parsing is said to be the same as for |pre|. Will |listing| be included some day or will it be left out, because |code| nested in |pre| provides the same semantics already? I have no plans for adding listing to the language at this time. It is supported merely for legacy reasons. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Request: window.postMessage should be async
On Sat, Apr 5, 2008 at 2:19 PM, Jeff Walden [EMAIL PROTECTED][EMAIL PROTECTED] wrote: Peter Kasting wrote: It doesn't matter if the stack will not _commonly_ be too deep, or if it isn't too deep for the callers that you know about right now -- it might be too deep at some point (after someone else changes the caller code, for example), and your sync handler will blow up. So put it in the contract for the API you're designing on top of postMessage that you shouldn't call the method without some generous number of frames available. (Doesn't assuming you'll need to consume lots of stack frames work against your argument that postMessage receivers will usually do computation out-of-band anyway?) I don't see why this problem requires a technical solution rather than a social one. (I should have mentioned this in the first message, thanks for prompting me to bring it up now.) So, your solution is, all developers writing postMessage-based APIs have to publish a contract, which is not enforced by any tooling but is merely part of some documentation alongside their API, that says how many stack frames they need? That seems like there are all kinds of risks of forgetting to do it, users ignoring it, etc. Why not just do the right thing naturally under the hood? Technical solutions that prevent misuse are always better than social ones, as you yourself originally argued on the security front. Here's another interesting case: what if my postMessage handler is a middleman that needs to itself postMessage to another target (a third party, or back to the original source)? Now I can't guarantee I have sufficient stack depth even if I care and know what my callee is expecting. And the very sorts of things you'd want postMessage for are frequently cases where others will write mashups and use your code in ways you hadn't planned. No, but *they* plan how they're going to use it, and they can adjust to not call with near-full stacks. Again, you're imposing extra effort on a potentially large number of callers, whose authors are at various skill levels, for what appears to me to be little gain. When Yahoo publishes some convenient postMessage()-based functionality, why should I have to understand anything about the requirements it imposes on me? Why can't I treat it as a black box? The same argument goes for running time-- if I don't know how long the callsite might take to execute, the only way I can guarantee responsiveness with a sync API is to do something like use Google Gears to get a WorkerPool object so I can effectively thread my JS, and then make my synchronous call in an async way while simultaneoulsy continuing my other processing. An async API, on the other hand, is significantly less risky because I'm guaranteed that I can't block for arbitrary periods of time no matter what the far side does. In most situations I can think of that use postMessage, it would also fit much more naturally into the code I'd be writing. All that happens is an exception, and you can catch and deal with it in the rare case that it happens. Potentially rare in frequency, assuming you're not running on pocket IE, but not in terms of call site structure when one side or the other is opaque -- callers would _always_ need to catch this exception and do something. If you're still not convinced that coders would care, remember that stack depths vary by interpreter, too. I believe in pocket IE you have a ridiculously small stack depth [12?]. This surprises me, but realistically, no device is going to be able to afford to have such a low stack depth going forward anyway. So, the real world is not a problem because you assume manufacturers are going to change it? What past evidence makes you think this will be true? I agree that probably someday we will be in a world where this is a case, but that day may be many years away. I'm not prepared to ignore that market until it happens to fit my conception of what it ought to be. I don't think we should penalize tomorrow for a limitation of today. What penalty are you imposing on tomorrow by making the API async? It's an easier, more natural API that is safer, more robust, and easier to implement. That doesn't sound like a penalty to me. The general theme I sense in your argument is that for some reason, you're really sold on a sync API, and you're willing to impose whatever costs it takes on both callers and callees in order to push that through. But I don't see a win here. Make the API async and no one has to do any of this work, and web apps are immediately simpler and more robust. I don't think a decent-sized percentage of web developers worry about stack overflow significantly more often than they worry about it from thinkos that accidentally cause infinite recursion. And I'm arguing that we should build an API that doesn't _force_ them to think about it more often than they do now, either. Especially when this
