[whatwg] Communicating between different-origin frames
Following some discussion of [1], it was pointed out to me that it is possible to make two pages on separate subdomains communicate without either setting their document.domain by proxing the communication through pages that have set their document.domain. There is a demo of this at [2]. I'm not sure if this is already well-known nor whether it is harmless or not. [1] http://my.opera.com/hallvors/blog/2010/07/13/ebay-versus-security-policy-consistency [2] http://sloth.whyi.org/~jl/cross-domain.html
[whatwg] Canvas coordinate space units
I'm confused by the term coordinate space units as applied to the canvas spec. It does not seem to be defined. It is used in the definition of the translate() method, for example, and seems to imply that coordinate space units are affected by scale() operations. It is used in the definition of the lineWidth attribute as well. Chrome, Firefox and Opera all scaled lineWidth and Phillip Taylor's test suite expects this behavior as well. But then in the definition of shadowOffsetX and Y, the spec reads: Their values are in coordinate space units. They are not affected by the current transformation matrix. The description of isPointInPath() uses similar language: when treated as coordinates in the canvas coordinate space unaffected by the current transformation, So which is it? Are coordinate space units affected by scaling or not? Are lineWidths supposed to be scaled? (Implementations do so consistently) Are shadow offset supposed to be scaled? (Chrome does, Firefox and Opera do not) I think a clearer definition of coordinate spaces would be helpful. Maybe device space for the underlying pixmap, canvas space for the coordinates defined by the width and height attributes of the canvas, and user space for the space defined by the current transformation matrix? David
Re: [whatwg] Communicating between different-origin frames
This is well-known http://www.collinjackson.com/research/papers/fp801-jackson.pdf but not a good idea (see Section 4.4): http://www.adambarth.com/papers/2009/barth-weinberger-song.pdf Adam On Wed, Jul 14, 2010 at 2:39 AM, James Graham jgra...@opera.com wrote: Following some discussion of [1], it was pointed out to me that it is possible to make two pages on separate subdomains communicate without either setting their document.domain by proxing the communication through pages that have set their document.domain. There is a demo of this at [2]. I'm not sure if this is already well-known nor whether it is harmless or not. [1] http://my.opera.com/hallvors/blog/2010/07/13/ebay-versus-security-policy-consistency [2] http://sloth.whyi.org/~jl/cross-domain.html
Re: [whatwg] Canvas coordinate space units
On Wed, Jul 14, 2010 at 3:03 PM, David Flanagan da...@davidflanagan.com wrote: I'm confused by the term coordinate space units as applied to the canvas spec. It does not seem to be defined. It seems clear to me. The 2D context represents a Cartesian plane, and the units for everything are units within that plane. One coordinate space unit might correspond to any number of pixels, depending: The intrinsic dimensions of the canvas element equal the size of the coordinate space, with the numbers interpreted in CSS pixels. However, the element can be sized arbitrarily by a style sheet. During rendering, the image is scaled to fit this layout size. The size of the coordinate space does not necessarily represent the size of the actual bitmap that the user agent will use internally or during rendering. On high-definition displays, for instance, the user agent may internally use a bitmap with two device pixels per unit in the coordinate space, so that the rendering remains at high quality throughout. It is used in the definition of the translate() method, for example, and seems to imply that coordinate space units are affected by scale() operations. The transformation matrix is referred to in a particular well-defined way by some methods. For instance, the rectangle methods say: The current transformation matrix must be applied to the following four coordinates, which form the path that must then be closed to get the specified rectangle: (x, y), (x+w, y), (x+w, y+h), (x, y+h). This only affects operations where it says so explicitly. Nothing that I see says it affects the coordinate space units themselves (if that even makes sense). It is used in the definition of the lineWidth attribute as well. Chrome, Firefox and Opera all scaled lineWidth and Phillip Taylor's test suite expects this behavior as well. I can't find where it says lineWidth should be scaled . . . But then in the definition of shadowOffsetX and Y, the spec reads: Their values are in coordinate space units. They are not affected by the current transformation matrix. The description of isPointInPath() uses similar language: when treated as coordinates in the canvas coordinate space unaffected by the current transformation, So which is it? Are coordinate space units affected by scaling or not? As far as I can tell, no. When the transformation matrix is used, it says so explicitly. The language you point to for shadowOffset and isPointInPath is just a reminder. I think. Are lineWidths supposed to be scaled? (Implementations do so consistently) I don't think they're supposed to be from reading the spec, although I don't know why not. Maybe I'm missing something, or maybe this needs to be clarified. Are shadow offset supposed to be scaled? (Chrome does, Firefox and Opera do not) Doesn't it say explicitly that they shouldn't be? I think a clearer definition of coordinate spaces would be helpful. Maybe device space for the underlying pixmap, canvas space for the coordinates defined by the width and height attributes of the canvas, and user space for the space defined by the current transformation matrix? It might be a good idea to separate out the units for stuff affected by transformations vs. not, yeah. I don't know why anything shouldn't be transformed by the current transformation matrix, though.
[whatwg] postMessage's target origin argument can be a full URL in some implementations
Hi, the way I read the spec, the target origin argument for window.postMessage should be a protocol, host name and optionally port number - in other words window.postMessage( 'foo', 'http://www.example.com' ) or window.postMessage( 'foo', 'http://www.example.com:81' ) However, it has come to my attention that both WebKit and Gecko's implementation of postMessage() allows a full URL with path: window.postMessage( 'foo', 'http://www.example.com/path/goes/here/' ) Isn't this a violation of the spec? My personal opinion is that protocol+host+port is better, simply because authors might assume the path is significant (i.e. think that 'http://www.geocities.com/foo' and 'http://www.geocities.com/bar' would be different origins). Allowing paths that are simply ignored might muddle the origin concept - not a major problem, but a small potential point of confusion. Opera follows the spec (as I read it) and throws an exception if a URL with a path is used, but I've recently come across two different scripts breaking in Opera because of this issue. I think it's very important to get this clarified and hopefully fixed in WebKit and Gecko before usage is too common and we have to modify the spec to allow it :-(. (We're already discussing fixes with the two broken sites). Any comments from Mozilla and WebKit developers on the list? P.S.: we reported some bugs for you, in case you agree with our reading and want to fix it :-) https://bugs.webkit.org/show_bug.cgi?id=42170 https://bugzilla.mozilla.org/show_bug.cgi?id=578380 -- Hallvord R. M. Steen
Re: [whatwg] postMessage's target origin argument can be a full URL in some implementations
On Wed, Jul 14, 2010 at 3:40 PM, Hallvord R M Steen hallv...@gmail.com wrote: Hi, the way I read the spec, the target origin argument for window.postMessage should be a protocol, host name and optionally port number - in other words window.postMessage( 'foo', 'http://www.example.com' ) or window.postMessage( 'foo', 'http://www.example.com:81' ) However, it has come to my attention that both WebKit and Gecko's implementation of postMessage() allows a full URL with path: window.postMessage( 'foo', 'http://www.example.com/path/goes/here/' ) Isn't this a violation of the spec? My personal opinion is that protocol+host+port is better, simply because authors might assume the path is significant (i.e. think that 'http://www.geocities.com/foo' and 'http://www.geocities.com/bar' would be different origins). Allowing paths that are simply ignored might muddle the origin concept - not a major problem, but a small potential point of confusion. Opera follows the spec (as I read it) and throws an exception if a URL with a path is used, but I've recently come across two different scripts breaking in Opera because of this issue. I think it's very important to get this clarified and hopefully fixed in WebKit and Gecko before usage is too common and we have to modify the spec to allow it :-(. (We're already discussing fixes with the two broken sites). Any comments from Mozilla and WebKit developers on the list? P.S.: we reported some bugs for you, in case you agree with our reading and want to fix it :-) https://bugs.webkit.org/show_bug.cgi?id=42170 https://bugzilla.mozilla.org/show_bug.cgi?id=578380 My understanding is that this was a requirement from the spec. An unfortunate one at that. However when I found out it was too late to get the spec changed as multiple implementations had already shipped. / Jonas
Re: [whatwg] postMessage's target origin argument can be a full URL in some implementations
My understanding is that this was a requirement from the spec. An unfortunate one at that. Could you elaborate on why you think it is unfortunate? However when I found out it was too late to get the spec changed as multiple implementations had already shipped. Does that mean you intend to fix it to align with the spec? Hallvord -- Hallvord R. M. Steen
Re: [whatwg] postMessage's target origin argument can be a full URL in some implementations
On Wed, Jul 14, 2010 at 3:48 PM, Hallvord R M Steen hallv...@gmail.com wrote: My understanding is that this was a requirement from the spec. An unfortunate one at that. Could you elaborate on why you think it is unfortunate? I think it's unfortunate that if someone does: postMessage(..., http://foo.com/bar/baz.html;); that message can silently go to http://foo.com/somethingElse.html The problem here is the 'silently'. If we instead made the above throw an exception then it would be more obvious for authors how this worked. However when I found out it was too late to get the spec changed as multiple implementations had already shipped. Does that mean you intend to fix it to align with the spec? I didn't realize that the spec now required that there was no path. Yes, I think we should update to match the spec. There is of course the risk that it'll break the web, but I think we should at least try. Would love it if someone attached a patch. I can promise same-day review if I'm not in travel. / Jonas
Re: [whatwg] postMessage's target origin argument can be a full URL in some implementations
On 7/14/10 6:40 PM, Hallvord R M Steen wrote: My personal opinion is that protocol+host+port is better, simply because authors might assume the path is significant (i.e. think that 'http://www.geocities.com/foo' and 'http://www.geocities.com/bar' would be different origins). Allowing paths that are simply ignored might muddle the origin concept - not a major problem, but a small potential point of confusion. I've actually used urls with a path for the origin; specifically when I wanted to pass in the origin of this page. In particular, I passed in location.href. I'm fine with removing the ability to pass in a path _if_ we create a simple way for scripts to get origins from pages which can then be passed for this argument. The alternative is that scripts will be parsing location.href themselves to extract the thing to pass as the origin string, which is just asking for security fail in my experience. -Boris
Re: [whatwg] Canvas coordinate space units
Aryeh Gregor wrote: On Wed, Jul 14, 2010 at 3:03 PM, David Flanagan da...@davidflanagan.com wrote: I'm confused by the term coordinate space units as applied to the canvas spec. It does not seem to be defined. It seems clear to me. Even if clear, it is still undefined. And the words coordinate space are so generic as to be meaningless here. canvas units or something would make more sense. The 2D context represents a Cartesian plane, and the units for everything are units within that plane. One coordinate space unit might correspond to any number of pixels, depending: The intrinsic dimensions of the canvas element equal the size of the coordinate space, with the numbers interpreted in CSS pixels. However, the element can be sized arbitrarily by a style sheet. During rendering, the image is scaled to fit this layout size. The size of the coordinate space does not necessarily represent the size of the actual bitmap that the user agent will use internally or during rendering. On high-definition displays, for instance, the user agent may internally use a bitmap with two device pixels per unit in the coordinate space, so that the rendering remains at high quality throughout. As an aside, do you think any implementations actually do that? It seems to me that it would cause real problems with drawImage(): images would look bad compared to drawn graphics... It is used in the definition of the translate() method, for example, and seems to imply that coordinate space units are affected by scale() operations. The transformation matrix is referred to in a particular well-defined way by some methods. For instance, the rectangle methods say: The current transformation matrix must be applied to the following four coordinates, which form the path that must then be closed to get the specified rectangle: (x, y), (x+w, y), (x+w, y+h), (x, y+h). This only affects operations where it says so explicitly. Nothing that I see says it affects the coordinate space units themselves (if that even makes sense). Okay; that makes sense. Points passed to path definition methods are transformed according to the CTM. I tend to think of transformations as affecting the entire coordinate space. But the spec is written with only one coordinate space defined, and points are transformed to this space as they are added to the path. It is used in the definition of the lineWidth attribute as well. Chrome, Firefox and Opera all scaled lineWidth and Phillip Taylor's test suite expects this behavior as well. I can't find where it says lineWidth should be scaled . . . It doesn't. But all implementations do it, as you pretty much be expected (otherwise drawings wouldn't scale right). The spec does not actually define what it means to stroke a line. If it did, it would probably have to say something like this: 1) Transform all the points in the path using the inverse of the CTM to convert them from the canvas coordinate space to the current user coordinate space (or some such language). 2) Define rectangles around each straight line segment of the path, where each rectangle is lineWidth pixels wide, and connect these rectangles with caps, miters and so on. (this is the part that would be a pain to spec, I think) So now the path has been transformed into a set of polygons. 3) Transform those polygons back to the canvas coordinate space using the CTM and fill them. I'm not trying to suggest that the spec needs to be modified to explicitly define how to stroke lines. But without an explanation of the process, the handling of lineWidth is difficult to explain. Certainly just saying that lineWidth is measured in coordinate space units is not sufficient. To me, it seems to imply that line width should never scale, and I don't think that is intended. David But then in the definition of shadowOffsetX and Y, the spec reads: Their values are in coordinate space units. They are not affected by the current transformation matrix. The description of isPointInPath() uses similar language: when treated as coordinates in the canvas coordinate space unaffected by the current transformation, So which is it? Are coordinate space units affected by scaling or not? As far as I can tell, no. When the transformation matrix is used, it says so explicitly. The language you point to for shadowOffset and isPointInPath is just a reminder. I think. Are lineWidths supposed to be scaled? (Implementations do so consistently) I don't think they're supposed to be from reading the spec, although I don't know why not. Maybe I'm missing something, or maybe this needs to be clarified. Are shadow offset supposed to be scaled? (Chrome does, Firefox and Opera do not) Doesn't it say explicitly that they shouldn't be? I think a clearer definition of coordinate spaces would be helpful. Maybe device space for the underlying pixmap, canvas space for the coordinates defined by the
Re: [whatwg] Canvas coordinate space units
On Jul 14, 2010, at 5:29 PM, David Flanagan wrote: Aryeh Gregor wrote: On Wed, Jul 14, 2010 at 3:03 PM, David Flanagan da...@davidflanagan.com wrote: I'm confused by the term coordinate space units as applied to the canvas spec. It does not seem to be defined. It seems clear to me. Even if clear, it is still undefined. And the words coordinate space are so generic as to be meaningless here. canvas units or something would make more sense. The 2D context represents a Cartesian plane, and the units for everything are units within that plane. One coordinate space unit might correspond to any number of pixels, depending snip As an aside, do you think any implementations actually do that? It seems to me that it would cause real problems with drawImage(): images would look bad compared to drawn graphics... WebKit supports device != css coordinates in its canvas implementation -- if you use QuartzDebug on Mac to change the resolution multiplier it causes a higher resolution backing buffer to be used. --Oliver
Re: [whatwg] postMessage's target origin argument can be a full URL in some implementations
On Wed, Jul 14, 2010 at 5:18 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 7/14/10 6:40 PM, Hallvord R M Steen wrote: My personal opinion is that protocol+host+port is better, simply because authors might assume the path is significant (i.e. think that 'http://www.geocities.com/foo' and 'http://www.geocities.com/bar' would be different origins). Allowing paths that are simply ignored might muddle the origin concept - not a major problem, but a small potential point of confusion. I've actually used urls with a path for the origin; specifically when I wanted to pass in the origin of this page. In particular, I passed in location.href. I'm fine with removing the ability to pass in a path _if_ we create a simple way for scripts to get origins from pages which can then be passed for this argument. The alternative is that scripts will be parsing location.href themselves to extract the thing to pass as the origin string, which is just asking for security fail in my experience. Personally, I think we should stop screwing with postMessage and let it be a stable enough API that folks can rely upon it. Adam
Re: [whatwg] Canvas coordinate space units
On 7/14/10 8:29 PM, David Flanagan wrote: As an aside, do you think any implementations actually do that? It seems to me that it would cause real problems with drawImage(): images would look bad compared to drawn graphics... They do that anyway on a high-dpi display that uses multiple device pixels per CSS pixel, no? Except for scalable images, of course. The canonical example here is printing: printing a bitmap image which is desined at screen resolution will produce worse output than printing a scalable one. That's just life. -Boris
Re: [whatwg] postMessage's target origin argument can be a full URL in some implementations
On 7/14/10 9:45 PM, Adam Barth wrote: Personally, I think we should stop screwing with postMessage and let it be a stable enough API that folks can rely upon it. Screwing with the spec, or with implementations? The spec, as currently written, is not compatible with the majority of shipped implementations -Boris
[whatwg] Canvas isPointInPath() coordinate space
Here's another coordinate-space related question. I assume that the intended purpose of isPointInPath() is hit testing. You get a click event on a canvas element, extract the mouse coordinates from the event object, subtract the canvas position from them, and pass them to isPointInPath() to figure out what part of your drawing the user has clicked on. My question has to do with this paragraph from the spec: The intrinsic dimensions of the canvas element equal the size of the coordinate space, with the numbers interpreted in CSS pixels. However, the element can be sized arbitrarily by a style sheet. During rendering, the image is scaled to fit this layout size. and this one: The isPointInPath(x, y) method must return true if the point given by the x and y coordinates passed to the method, when treated as coordinates in the canvas coordinate space unaffected by the current transformation... So suppose I'm using this canvas tag: canvas width=100 height=100 style=width:200px; height:200px/canvas If I understand the first quoted paragraph above correctly, this canvas will have 2 on-screen CSS pixels per coordinate space unit. So here's my question: if I want to do hit-testing as described above, do I need to take the mouse coordinates from the event, subtract the offset of the canvas, and then divide by 2? As the spec is written, I think I do have to do that division manually. Is that what is intended? What if the user has zoomed in? Is it even possible to use isPointInPath() correctly in that case? David
