Re: [Bindings] extended attribute for callback function interfaces?
Cameron McCormack wrote: Jonas Sicking: Why do we need the FunctionOnly/PropertyOnly feature? In gecko we don't have that functionality and it hasn't caused any problems that I can think of. I took David’s feedback to mean that sometimes you want to state that a single-function interface can’t be implemented by a function (and added PropertyOnly for that). Ah, after rereading Davids feedback that does make sense to me. What we do in gecko is that we have a property that indicates 'this interface can be implemented as a function'. See for example: http://mxr.mozilla.org/mozilla-central/source/dom/public/idl/events/nsIDOMEventListener.idl (search for 'function'). I don't really care if it's an opt-in or opt-out though. And actually, simply having the [Callback] flag might be enough since as soon as you have said that something is a callback-interface it's going to be really hard to add any thing to the interface. / Jonas
Re: [XHR] security issue with spec's same-origin and the Document pointer
On Sun, 23 Nov 2008 22:32:02 +0100, Anne van Kesteren [EMAIL PROTECTED] wrote: var xhrConstructor = iframe.contentWindow.XMLHttpRequest; iframe.src='http://attackee.example.com/'; . . var xhr = new xhrConstructor(); When the constructor is invoked here, the associated document of its associated window object is not safe to do same-origin comparisons against. I've tested this in the main 4 engines, and they all protect against this exploit but as far as I can see someone implementing the spec as it's written would end up vulnerable. Why would the SECURITY_ERR exception not be thrown during the open() method invocation as the specification requires? Because when you call new xhrConstructor() the document pointer is initialized *but at that point the document of the associated window originates from attackee.example.com*. Once you navigate the original Document is either destroyed or stays around. However, it does not suddenly change into the Document of another domain. The point is that there *is* no document pointer until you call the constructur - per the spec. And once that script calls the constructor and the document pointer is created, the associated window has a different document in it from a different origin. Hence the document pointer will reference a document from a different origin than the script itself has, and same-origin comparisons will pass when they should fail and vice versa. If you still don't get it please read carefully because I don't know how to explain it clearer than that :-p. Besides, I'm on vacation and will try not to read E-mail ;) -- Hallvord R. M. Steen Core JavaScript tester, Opera Software http://www.opera.com/ Opera - simply the best Internet experience
Re: [XHR] security issue with spec's same-origin and the Document pointer
On Mon, 24 Nov 2008, Hallvord R. M. Steen wrote: The point is that there *is* no document pointer until you call the constructur - per the spec. And once that script calls the constructor and the document pointer is created, the associated window has a different document in it from a different origin. Hence the document pointer will reference a document from a different origin than the script itself has, and same-origin comparisons will pass when they should fail and vice versa. Valid point; the XHR spec should use the script document context as the Document instead. Warning though, this part of the HTML5 spec is definitely unstable. http://www.whatwg.org/specs/web-apps/current-work/#script-document-context -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Widget testing
Hi Kai! On Fri, Nov 7, 2008 at 1:16 PM, Kai Hendry [EMAIL PROTECTED] wrote: Hey guys, I have an action to tell you what I've been upto WRT widgets http://www.w3.org/2008/11/04-mwts-minutes.html#action02 I've started working one day a week on widget testing. My own git repo is here: http://git.webvm.net/?p=wgtqa and it will move to a W3C CVS soon. I've come across a couple of issues which I've mailed Marcos already about. Though I'll paste them in here just in case: Subject: http://dev.w3.org/2006/waf/widgets/#the-license Having a optional URI or href whatever for the license would be good. Seems to be some inconsistency between src, uri, url, href btw that you can easily pick up in the relaxng scheme. I'm not comfortable with adding an optional URI. It implies that a license could change on the web without the user knowing about it. That really concerns me. http://dev.w3.org/2006/waf/widgets/#the-author xml:lang is not needed and it's not in your relaxng schema besides. Yep. The schema will only be updated once we finish spec'ing. I don't want to waste David's time updating the schema when the spec is still changing. I might remove the schema all together till we get to last call. It causes too much confusion at this point because it is maintained independently of the spec. Subject: http://dev.w3.org/2006/waf/widgets/#the-widget0 Bit confused by its:dir on widget, name, description, author etc. Can you describe the confusion? What should I put into the spec to make things more clear? The RelaxNG compact schema uses the bdo element and so does HTML5 so can't we just rock with that? http://git.webvm.net/?p=wgtqa;a=blob;f=widget.rnc As above. I've also written a little widget validation tool, which uses my updated (probably wrong) schema (widget.rnc). Try foo.wgt out like so: curl -F [EMAIL PROTECTED] http://wgt.webvm.net/ Great! If you have any comments or you'd like to help us out over at http://www.w3.org/2005/MWI/Tests/ then please get in touch. I'm also on IRC as 'hendry'. Enjoy the weekend, Thanks for your help Kai! -- Marcos Caceres http://datadriven.com.au
Re: Widget testing
On 24 Nov 2008, at 22:46, Marcos Caceres wrote: Subject: http://dev.w3.org/2006/waf/widgets/#the-license Having a optional URI or href whatever for the license would be good. Seems to be some inconsistency between src, uri, url, href btw that you can easily pick up in the relaxng scheme. I'm not comfortable with adding an optional URI. It implies that a license could change on the web without the user knowing about it. That really concerns me. It's not that uncommon to use URIs to identify (well-known) licenses, see, e.g., http://www.w3.org/Submission/2008/SUBM-ccREL-20080501/ http://www.ietf.org/rfc/rfc4946.txt I'd suggest that it's a good idea to enable this pattern for widgets; the issue that you point out (licenses changing after the fact) is one that's being dealt with on a social level. -- Thomas Roessler, W3C [EMAIL PROTECTED]
Re: Widget testing
On Mon, Nov 24, 2008 at 10:04 PM, Thomas Roessler [EMAIL PROTECTED] wrote: On 24 Nov 2008, at 22:46, Marcos Caceres wrote: Subject: http://dev.w3.org/2006/waf/widgets/#the-license Having a optional URI or href whatever for the license would be good. Seems to be some inconsistency between src, uri, url, href btw that you can easily pick up in the relaxng scheme. I'm not comfortable with adding an optional URI. It implies that a license could change on the web without the user knowing about it. That really concerns me. It's not that uncommon to use URIs to identify (well-known) licenses, see, e.g., http://www.w3.org/Submission/2008/SUBM-ccREL-20080501/ http://www.ietf.org/rfc/rfc4946.txt I'd suggest that it's a good idea to enable this pattern for widgets; the issue that you point out (licenses changing after the fact) is one that's being dealt with on a social level. Grumble, grumble... alright, I'll add it... but I still don't like it :) -- Marcos Caceres http://datadriven.com.au
Could we add setCapture to DOM Events?
Web Apps WG, Would it be possible to add setCapture() (as supported in IE; see below) to DOM3 Events? It seems more appropriate to have it there than in HTML5. Note that I don't think we'd need releaseCapture(); we should just say that capture is canceled when the mouse is released if it was captured. This gets around the problem of unbalanced set/release. On Thu, 14 Aug 2008, Greg Houston wrote: On Thu, Aug 14, 2008 at 6:14 PM, Ian Hickson [EMAIL PROTECTED] wrote: On Thu, 14 Aug 2008, Greg Houston wrote: 1. You have a fluid layout where the columns are resizable via javascript by dragging the borders. The content of one of the columns is an iframe. You begin dragging the border between it and the column to the left, but as soon as the cursor goes over the iframe, the dragging functionality stops because you have now entered the context of the iframe. Thus it becomes impossible or at the very least very difficult to resize the column containing it. This seems like a bug. It seems like we would want to address this directly rather than requiring authors to disable iframes when doing drags (especially since that wouldn't help with things like plugins or whatever). Wouldn't the better solution be to provide some sort of mechanism to say that while the mouse button is down, all the mouse move events should go to the element that got the mousedown event? That would probably work, though I don't know if limiting it to the specific element itself might cause any issues. For instance, something lacking in the HTML5 drag and drop specification is the ability to define a handle for the element that is being dragged. With the drag and drop in javascript libraries you can define a handle (a different element) that drags the draggable element. If the handle property/attribute is null then the element itself is it's own handle. Perhaps there is a mousemove event in the current context (the parent document let's say) that is checking to see if the user tries to drag an object over it. We don't want to break the ability to create this sort of collision detection. It might be safer to say that while the mouse button is down, all the mouse move events should be processed in the same context the mousedown event occurred in. So if the mousedown occurs in the parent, mouse move events should be processed in the parent until a mouseup occurs. Likewise, if a mousedown occurs in the child iframe, mouse move events should be processed in the child iframe until a mouseup occurs. Yet there should also probably be some way to disable this or a way for one context to release mouse ownership to another context. I did a search for drag and drop between iframes, and there is at least one application out there that can fake this: http://intersoftpt.wordpress.com/2007/03/16/drag-and-drop-across-iframes/ Also, from a forum post on drag and drop between iframes: I have *heard* of people doing this by using the parent window to store and mediate state between the 2 child iframe windows. So when a drag was in progress, and the mouse coord reached the edge of the iframe window, you would notify the other iframe to start listening for mouseover events and create the illusion of a seamless drag. In these cases you would probably want a way to change context during mousedown, though the change should probably be controlled from the context the mousedown occurred in. That context gets to decide if it relinquishes control of the mouse move events before the mouseup or not. By default it should not. On Fri, 15 Aug 2008, Cameron McCormack wrote: The old SVG 1.2 Full draft had a pair of methods (which are implemented in Batik), startMouseCapture()/ stopMouseCapture(), that could be used to do this kind of thing. On Fri, 15 Aug 2008, Ojan Vafai wrote: setCapture/releaseCapture is how IE supports this. Seems to work well with iframes. It even deals with event coordinates in the expected way (e.g. clientX, clientY are relative to the document that the captured element is in instead of the document of the iframe). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
