Re: [whatwg] Canvas comments
... lots of stuff that hixie has already responded to ... * There's no fast way to edit the pixels on the canvas. putImageData and getImageData are glacial, as is fillStyle= + fillRect(). Byte arrays (well, if strings were bags of bytes, they'd work too) or a shader language, maybe? I don't know. I believe Hixie is already looking at speccing the ImageData object to require a fast native backing buffer (i could be wrong), but i'll add my two cents here. putImageData is not slow. I've done a number of timings for blitting a 200x200px square, and Opera and an incomplete putImageData impl for WebKit both blit in 2ms -- that's not slow, it's certainly far faster than you're likely to be able to provide content. If you're actually complaining about the time taken to fill the data array that's a different issue entirely -- Opera does actually provide an ImageData constructor, and getImageData return specialised objects, with a specialised array implementation, but when push comes to shove the only real difference is when the bounds checking occurs (eg. on assignment to the data array vs. during putImageData stage) but in my testing that's where most of the time is spent in putImageData. Editing the raw pixels in the canvas backing store is also not feasible as there would be too many issues with implementation details (eg. the canvas in webkit is flipped, and i very much doubt that that is the case for other engines, some engines use a premultiplied backing store, some don't). That said i would still very much like to have the ability to paint only a subregion of an ImageData object. --Oliver
Re: [whatwg] Minor addition/rewording for canvas section
On Jan 31, 2008, at 10:38 PM, Ian Hickson wrote: On Sun, 13 Jan 2008, Oliver Hunt wrote: Section 3.14.11 ... I overhauled this paragraph. It's now a separate, much more explicit, section. Did I miss anything? That looks excellent, thanks :D --Oliver -- Ian Hickson U+1047E) \._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _ \ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'-- (,_..'`-.;.'
Re: [whatwg] Compatibility problems with HTML5 Canvas spec.
On Jan 31, 2008, at 9:35 PM, Ian Hickson wrote: On Thu, 27 Sep 2007, Anne van Kesteren wrote: Cool! I suppose that leaves the issue about revisiting throwing exception for certain members? Are there any member where it does make to throw an exception? If we decide not to throw an exception something has to be decided for Infinity -Infinity and NaN for all of those. I don't have a strong opinion on it either way, although I would prefer it to be decided quickly so we have some time to propagate the changes in time for Opera 9.5. Are there any undefined cases you think should be defined? (The spec has changed significantly in recent days to cover many holes.) It's looking good, just a few more comments All the transform operations define the behaviour if given inf, but not NaN The behaviour of inf and nan arguments is undefined for arguments to the gradient constructors and shadow offsets. I think it should be explicit that negative width/height are allowed on the rect methods (which appears to be the case based on my reading) The behaviour of inf and NaN arguments is undefined for any of the path functions. I would think the a 0 dimension in the source rect for drawImage, and the like should fail silently, but i need to check what existing implementations actually do. Unfortunately I don't really know what the best behaviour would be in these cases -- i tend to prefer failing silently, but i think we should at least look at what existing implementions already do. Finally, although only tangentially related, i think we should provide the ability to selectively blit only a subregion of an ImageData object. --Oliver -- Ian Hickson U+1047E) \._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _ \ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'-- (,_..'`-.;.'
Re: [whatwg] Referer header sent with a ping?
On Fri, 01 Feb 2008 02:03:01 +0100, Darin Fisher [EMAIL PROTECTED] wrote: I suppose that X-Ping-From/To should be striped (like Referer) when one of those values is HTTPS and the ping attribute is non-HTTPS? Given that HTML5 is now on standards track lets make it Ping-From and Ping-To. Provisionally registering headers is pretty simple and when HTML5 finally becomes a W3C Recommendation we can move them to the permanent registry. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Referer header sent with a ping?
Ian Hickson wrote: This would make it easy to protect against unwanted ping-originated requests (one could configure server or set up application firewall to filter pings), and URL in a ping wouldn't have to contain copies of page's URL and href. What do people think of this idea: We make Referer always have the value PING. Referer takes a relative reference, or a URI. Not a good idea. We add two headers, X-Ping-From which has the value of the page that had the link, and X-Ping-To which has the value of the page that is being opened. You don't need any new headers. Define a content type, and send the information you want to transmit in the request body. We continue to send all cookie and authentication headers. What do people think? Would this address all the issues raised? BR, Julian
Re: [whatwg] Canvas methods and exceptions
On Mon, 14 Jan 2008, Oliver Hunt wrote: In a recent foray into the world of canvas compatibility I've noticed that a number of canvas methods are defined as throwing exceptions on invalid input which aren't really insane, for example * clear/fill/drawRect with negative width/height * drawImage with negative sx/sw * putImageData with pixel data outside of the 0-255 range Already fixed. Following the idea of doing the least surprising action, i think we should go through the Canvas spec and remove surprising exceptions. For instance a negative width for a rectangle should not terminate execution (although whether it should fail silently, or just draw the rect as though it were positioned differently is a question that would need to be answered), ditto for the other cases that i mentioned. I did this yesterday; if you see any that I missed, please let me know. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] A potential slight security enhancement to postMessage
The original message never showed up, sadly, so the threading's going to be a bit wrong here, unfortunately. Currently postMessage is great for sending authenticated messages between frames. The receiver knows exactly where each message came from. However, it doesn't provide any confidentiality guarantees. When you're posting a message to a window, you have no way of knowing who is listening on the other end, because the same-origin policy prevents you from reading the domain and URI of that window. The window may have been showing a page loaded from foo.com the last time you received a message from it, but it might be displaying content from bar.com now; if you send it a message, you don't whether the message will be received by foo.com or bar.com. I noted in IRC discussion that postMessage being sync allows a challenge-response protocol to be safely used here, and you can determine the target's identification using domain/uri on the responding message; counterresponse was that's somewhat complicated. Fair enough; I'm not sure if super-security is the main use case for this feature or not (lightweight collaboration seems more likely to me, but I don't really know), so I'm hesitant to comment too much on it. The postMessage API could be extended to provide confidentiality by adding some optional arguments: void postMessage(in DOMString message, [optional] in DOMString domain, [optional] in DOMString uri); If domain or uri are specified, the browser would only deliver the message if the recipient's location matches the specified domain and/or URI. (Being able to specify the URI allows sites to differentiate between http and https URIs.) This seems reasonable enough. For privacy, postMessage should be designed not to reveal the domain or URI of the receiving window, so if there is a mismatch, the message should be silently dropped. Silent dropping is definitely good. Providing the domain and URI for replies should be easy since these values are already parameters of the event. True -- problem is requiring people use them, since they're not forced to do so now. Jeff
Re: [whatwg] A potential slight security enhancement to postMessage
Aaron Boodman wrote:
Not necessarily. You could do something like this:
window.createMessageReceiver(http://www.google.com;)
.addEventListener(post-message, function() {
...
}, fase);
Could probably come up with a better method name, and I forget the
name of the event to use with PostMessage, but I hope you get the
idea.
Ah, yes, hadn't given it enough thought to think of that idea. Adding yet
another object type to the HTML5 system seems suboptimal, but it would address
the problem. A whitespace-separated string of URIs (or prefixes? or domains?
domains is least complicated but doesn't address protocol, and possibly not
port) seems like a reasonable way to do it.
If you tell people they have to read x property before y
property, they will just do:
// spec says we have to read this first
var foo = event.domain;
alert(event.message);
That'd be the fear, yes. It depends to an extent on how the documentation's
worded, which is the problem this is originally trying to avoid.
Jeff
Re: [whatwg] A potential slight security enhancement to postMessage
On Feb 1, 2008 8:18 PM, Jeff Walden [EMAIL PROTECTED] wrote: Currently postMessage is great for sending authenticated messages between frames. The receiver knows exactly where each message came from. However, it doesn't provide any confidentiality guarantees. When you're posting a message to a window, you have no way of knowing who is listening on the other end, because the same-origin policy prevents you from reading the domain and URI of that window. The window may have been showing a page loaded from foo.com the last time you received a message from it, but it might be displaying content from bar.com now; if you send it a message, you don't whether the message will be received by foo.com or bar.com. I noted in IRC discussion that postMessage being sync allows a challenge-response protocol to be safely used here, and you can determine the target's identification using domain/uri on the responding message; counterresponse was that's somewhat complicated. Fair enough; I'm not sure if super-security is the main use case for this feature or not (lightweight collaboration seems more likely to me, but I don't really know), so I'm hesitant to comment too much on it. You could implement confidentiality on top of the original synchronous postMessage using a wrapper that performs challenge-response. Adam and I implemented this as a 48-line JavaScript library. You can try it out here: http://crypto.stanford.edu/websec/post-message/challenge-response/. This turned out to be slightly tricky. To send a single message, the sender has to first post a message to the recipient. The recipient then responds. At this point, during the execution of this callback, the domain and uri attributes of the event are accurate and the sender can safely send the message. There are a number of gotchas, which we think we've handled correctly, but it's hard to be sure. In the end, it would be much simpler and less error-prone to write this as a single line of code: frames[0].postMessage(message, theory.stanford.edu); Collin Jackson
