Re: Mouse Lock
I'm sorry that I didn't follow the earlier thread. What is the
security model for mouse lock? (Please feel free to point me to a
message in the archive if this has already been discussed.)
Thanks,
Adam
On Thu, Jun 16, 2011 at 3:21 PM, Vincent Scheib wrote:
> [Building on the "Mouse Capture for Canvas"
> thread: http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/thread.html#msg437 ]
> I'm working on an implementation of mouse lock in Chrome, and would
> appreciate collaboration on refinement of the spec proposal. Hopefully
> webapps is willing to pick up this spec work? I'm up for helping write the
> draft.
> Some updates from Sirisian's Comment 12 on the w3 bug
> (http://www.w3.org/Bugs/Public/show_bug.cgi?id=9557#c12):
> - We shouldn't need events for success/failure to obtain lock, those can be
> callbacks similar to geolocation API:
> (http://dev.w3.org/geo/api/spec-source.html#geolocation_interface).
>
> My short summary is then:
> - 2 new methods on an element to enter and exit mouse lock. Two callbacks on
> the entering call provide notification of success or failure.
> - Mousemove event gains .deltaX .deltaY members, always valid, not just
> during mouse lock.
> - Elements have an event to detect when mouseLock is lost.
> Example
> x = document.getElementById("x");
> x.addEventListener("mousemove", mouseMove);
> x.addEventListener("mouseLockLost", mouseLockLost);
> x.lockMouse(
> function() { console.log("Locked."); },
> function() { console.log("Lock rejected."); } );
> function mouseMove(e) { console.log(e.deltaX + ", " + e.deltaY); }
> function mouseLockLost(e) { console.log("Lost lock."); }
>
Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null
On Mon, Jun 13, 2011 at 9:40 AM, Adam Barth wrote: > On Mon, Jun 13, 2011 at 1:31 AM, Jonas Sicking wrote: >> On Mon, Jun 13, 2011 at 12:15 AM, Adam Barth wrote: >>> On Sun, Jun 12, 2011 at 11:19 PM, Jonas Sicking wrote: On Sun, Jun 12, 2011 at 8:35 PM, Cameron McCormack wrote: > Adam Barth: >> > WebKit is looser in this regard. We probably should change the >> > default for new IDL, but it's a delicate task and I've been busy. :( > > What about for old IDL? Do you feel that you can make this change > without breaking sites? One of the “advantages” of specifying the > looser approach is that it’s further down the “race to the bottom” hill, > so if we are going to tend towards it eventually we may as well jump > there now. I can't remember getting a single bug filed on Geckos current behavior. There probably have been some which I've missed, but it's not a big enough problem that it's ever been discussed at mozilla as far as I can remember. >>> >>> Unfortunately, there's a bunch of WebKit-dominate content out there >>> that folks are afraid to break. We discussed this topic on some bug >>> (which I might be able to dig up). The consensus was that the value >>> in tightening this for old APIs wasn't worth the compat risk (e.g., in >>> mobile and in Mac applications such as Dashboard and Mail.app). >>> >>> For new APIs, of course, we can do the tighter things (which I agree >>> is more aesthetic). It mostly requires someone to go into the code >>> generator and make it the default (and then to special-case all the >>> existing APIs). I'd like to do that, but it's a big job that needs to >>> be done carefully and I've got other higher priority things to do, so >>> it hasn't happened yet. >> >> If there is agreement that new APIs should throw for omitted >> non-optional parameters, then it seems clear that WebIDL should use >> that behavior. >> >> That leaves the work for safari (and possibly other webkit devs) to go >> through and mark parameters as [optional] in their IDL. Possibly also >> filing bugs for cases where you want the relevant spec to actually >> make the argument optional. I realize that this is a large amount of >> work, but this is exactly what we have asked in particular of >> microsoft in the past which has been in a similar situation of large >> divergence from the DOM specs, and large bodies of existing content >> which potentially can depend on IE specific behavior. > > Think folks are agreed that's the path we should follow. My only > concern is that we don't have anyone signed up to do the work on the > WebKit side. Just to update this thread, Mark Pilgrim has stepped forward to get the ball rolling on this work, so WebKit is making progress on this front. Thanks, Adam >> FWIW, I'd be happy to do the same to align Gecko behavior with specs >> when needed. For example I thought we were going to end up having to >> do that to make coerce to "null" by default for DOMString >> arguments. It appears that in that case the WebIDL behavior changed to >> align with Gecko, which I think is unfortunate, and so it doesn't look >> like this change will have to happen (I used to argue otherwise in the >> past, but I've come around to the idea that aligning with JS behavior >> is more important, even when I'm not a fan of JS behavior).
[Bug 8241] Named properties on window
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8241 Cameron McCormack changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #7 from Cameron McCormack 2011-06-19 03:06:58 UTC --- Now that we are going back to defining named property behaviour in terms of ECMAScript internal methods ([[DefineOwnProperty]], [[GetOwnProperty]], etc.) we can use them to implement [ReplaceableNamedProperties] rather than something in the prototype. I've done that: http://dev.w3.org/cvsweb/2006/webapi/WebIDL/Overview.xml.diff?r1=1.303;r2=1.304;f=h -- 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.
how to implement the c# HttpListener with the CORS protocol
Hello, I have written a c# application that uses the HttpListener class. This class is embedded in the IIS server, but is also available for use by c# developers. This class allows the developer to create an application that can receive Http requests and send back Http responses. Recently, I have seen the need for this application to accept certain cross-domain resource sharing connections if they are from a designated server. I've read that IE8 automatically handles the protocol to send a CORS request (i.e. supplies the header, Origin: for example). This occurs when the caller uses the XMLHttpRequest javascript object. I have not verified this. The article also states that although the javascript does not need to change, the server code must change. If this is true, then I want my server to send the header, Access-Control-Allow-Origin: back to the originator. The problem is that the HttpListener object has a method, getContext where it can receive a request. Can I assume that the header has been set in this request? If so, I can return Access-Control-Allow-Origin back. At this point, does the requestor need to send me a new request to contain the actual request...how does it work? Thank you for any help you can give. If you have an example, that would be great! Sincerely, PDecker
Mouse Lock
[Building on the "Mouse Capture for Canvas" thread:
http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/thread.html#msg437
]
I'm working on an implementation of mouse lock in Chrome, and would
appreciate collaboration on refinement of the spec proposal. Hopefully
webapps is willing to pick up this spec work? I'm up for helping write the
draft.
Some updates from Sirisian's Comment 12 on the w3 bug (
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9557#c12):
- We shouldn't need events for success/failure to obtain lock, those can be
callbacks similar to geolocation API: (
http://dev.w3.org/geo/api/spec-source.html#geolocation_interface).
My short summary is then:
- 2 new methods on an element to enter and exit mouse lock. Two callbacks on
the entering call provide notification of success or failure.
- Mousemove event gains .deltaX .deltaY members, always valid, not just
during mouse lock.
- Elements have an event to detect when mouseLock is lost.
Example
x = document.getElementById("x");
x.addEventListener("mousemove", mouseMove);
x.addEventListener("mouseLockLost", mouseLockLost);
x.lockMouse(
function() { console.log("Locked."); },
function() { console.log("Lock rejected."); } );
function mouseMove(e) { console.log(e.deltaX + ", " + e.deltaY); }
function mouseLockLost(e) { console.log("Lost lock."); }
