Re: [XHR2] FormData for form
On Tue, 14 Sep 2010 20:19:27 +0200, Jonas Sicking jo...@sicking.cc wrote: On Tue, Sep 14, 2010 at 11:04 AM, Anne van Kesteren ann...@opera.com wrote: So in terms of HTML5 the above would invoke Constructing the form data set (defined in HTML5) for the HTMLFormElement passed as parameter and let that data set be the data hold by FormData. Is that what you plan to implement? Yes. So I looked into this today and it seems that what HTML defines is not entirely what is needed. The controls associated with the form and extracting the form data set are separate steps rather than one algorithm that can be used for FormData. I filed a bug on HTML and updated the XMLHttpRequest specification as far as I could (not very): http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#dom-formdata-form -- Anne van Kesteren http://annevankesteren.nl/
Re: FormData questions
Just to follow up on this one more time with regards to the current state of the specification. On Sat, 13 Feb 2010 02:32:18 +0100, Jonas Sicking jo...@sicking.cc wrote: First of all, I assume that it is intended that a FromData object can be submitted several times. I.e. that the following code is ok: fd = new FormData; fd.append(name1, foo); xhr1 = new XMLHttpRequest; xhr1.open(...); xhr1.send(fd); fd.append(name2, bar); xhr2 = new XMLHttpRequest; xhr2.open(...); xhr2.send(fd); where the first XHR will send 1 name/value pair, and the second XHR will send 2. I do think this should be allowed, but I wanted to make sure others agreed. Yes, the object does not suddenly become immutable. Second, what encoding should be used when submitting a FromData object? A few options are: * Always use UTF-8 It is now clear that it should always be UTF-8. Lastly, there is a bug in the spec where it says that the mimetype should be multipart/form-data. It needs to be multipart/form-data; boundary= plus the boundary used while encoding. Hmm yeah. XMLHttpRequest is using the multipart/form-data encoding algorithm from HTML. I guess that should return the boundary used somehow so I can use that. I filed a bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12006 This also brings up the question what to do if a Content-Type header has already been set. Should a boundary mime parameter be added, or is the server side simply out of luck and won't get to know what the boundary is? Per the current specification it is simply out of luck. Consistent with how we handle this for other type of objects passed to send(). -- Anne van Kesteren http://annevankesteren.nl/
Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases
On Mon, Feb 7, 2011 at 8:09 PM, Jeremy Orlow jor...@chromium.org wrote: We're currently implementing the onblocked/setVersion semantics and ran into an interesting problem: if you don't call .close() on a database and simply expect it to be collected, then you ever being able to run a setVersion transaction is at the mercy of the garbage collecter doing a collection. Otherwise implementations will assume the database is still open...right? If so, this seems bad. But I can't think of any way to get around it. Thoughts? Hmm.. never thought about this problem. But yes, I suspect this issue comes up in our implementation. The only solution I can think of is to require (or recommend) that implementations run the garbage collector in a context after firing the versionchange event if the database still isn't closed. This should be a rare occurrence simply because setVersion should be rare. / Jonas
Re: [IndexedDB] Reason for aborting transactions
On Mon, Feb 7, 2011 at 8:05 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Feb 7, 2011 at 7:36 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Jan 28, 2011 at 4:33 PM, Jeremy Orlow jor...@chromium.org wrote: We do that as well. What's the best way to do it API wise? Do we need to add an IDBTransactionError object with error codes and such? I don't actually know. I can't think of a precedence. Usually you use different error codes for different errors, but here we want to distinguish a particular type of error (aborts) into several sub categories. I don't see how that's any different than what we're doing with the onerror error codes though? Hmm.. true. To make this more complicated, I actually think we're going to end up having to change a lot of error handling when things are all said and done. Error handling right now is sort of a mess since DOM exceptions are vastly different from JavaScript exceptions. Also DOM exceptions have a messy situation of error codes overlapping making it very easy to confuse a IDBDatabaseException with a DOMException with an overlapping error code. For details, see http://lists.w3.org/Archives/Public/public-script-coord/2010OctDec/0112.html So my gut feeling is that we'll have to revamp exceptions quite a bit before we unprefix our implementation. This is very unfortunate, but shouldn't be as big deal of a deal as many other changes as most of the time people don't have error handling code. Or at least not error handling code that differentiates the various errors. Unfortunately we can't make any changes to the spec here until WebIDL prescribes what the new exceptions should look like :( So to loop back to your original question, I think that the best way to expose the different types of aborts is by adding a .reason (or better named) property which returns a string or enum which describes the reason for the abort. Could we just add .abortCode, .abortReason, and constants for each code to IDBTransaction? Why both? How are they different. I'd just go with the former to align with error codes. And maybe revisit in the future? Yes. I think we need to wait for webidl to solidify a bit here before we do anything. / Jonas
Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases
The only solution I can think of is to require (or recommend) that implementations run the garbage collector in a context after firing the versionchange event if the database still isn't closed. This should be a rare occurrence simply because setVersion should be rare. That would be a hack in the implementation and a hack in the spec.
Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases
On Tue, Feb 8, 2011 at 2:45 AM, João Eiras joao.ei...@gmail.com wrote: The only solution I can think of is to require (or recommend) that implementations run the garbage collector in a context after firing the versionchange event if the database still isn't closed. This should be a rare occurrence simply because setVersion should be rare. That would be a hack in the implementation and a hack in the spec. Why? And what are you suggesting instead? The above email is very hard to act on. / Jonas
Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases
On Tue, Feb 8, 2011 at 10:52 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Feb 8, 2011 at 2:45 AM, João Eiras joao.ei...@gmail.com wrote: The only solution I can think of is to require (or recommend) that implementations run the garbage collector in a context after firing the versionchange event if the database still isn't closed. This should be a rare occurrence simply because setVersion should be rare. That would be a hack in the implementation and a hack in the spec. Why? And what are you suggesting instead? Don't have a solution, but expecting certain GC behavior on a specification is far from sane.
Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases
On Tue, Feb 8, 2011 at 3:20 AM, João Eiras joao.ei...@gmail.com wrote: On Tue, Feb 8, 2011 at 10:52 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Feb 8, 2011 at 2:45 AM, João Eiras joao.ei...@gmail.com wrote: The only solution I can think of is to require (or recommend) that implementations run the garbage collector in a context after firing the versionchange event if the database still isn't closed. This should be a rare occurrence simply because setVersion should be rare. That would be a hack in the implementation and a hack in the spec. Why? And what are you suggesting instead? Don't have a solution, but expecting certain GC behavior on a specification is far from sane. No one is suggesting that. I'll also point out that even if the implementation doesn't GC the object immediately things will still work fine. You'll just receive the success event later, and possibly also a blocked event while waiting. As I'm sure you already know. / Jonas
Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases
On Tue, Feb 8, 2011 at 3:26 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Feb 8, 2011 at 3:20 AM, João Eiras joao.ei...@gmail.com wrote: On Tue, Feb 8, 2011 at 10:52 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Feb 8, 2011 at 2:45 AM, João Eiras joao.ei...@gmail.com wrote: The only solution I can think of is to require (or recommend) that implementations run the garbage collector in a context after firing the versionchange event if the database still isn't closed. This should be a rare occurrence simply because setVersion should be rare. That would be a hack in the implementation and a hack in the spec. Why? And what are you suggesting instead? Don't have a solution, but expecting certain GC behavior on a specification is far from sane. No one is suggesting that. I'll also point out that even if the implementation doesn't GC the object immediately things will still work fine. You'll just receive the success event later, and possibly also a blocked event while waiting. As I'm sure you already know. Unless by certain GC behavior mean free objects that are no longer used. If that is indeed what you meant then we'll have to agree to disagree what is far from sane. / Jonas
Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases
Unless by certain GC behavior mean I referred to # The only solution I can think of is to require (or recommend) that implementations run the garbage collector The GC is transparent and a spec cannot expect that it runs at specific times or demand it.
Re: [IndexedDB] Reason for aborting transactions
Why not just expand our list of error codes to have multiple ABORT_ variants for each situation, and then always fire the abort event with a slightly different errorCode? That seems far simpler IMO. -Ben On Tue, Feb 8, 2011 at 2:21 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Feb 7, 2011 at 8:05 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Feb 7, 2011 at 7:36 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Jan 28, 2011 at 4:33 PM, Jeremy Orlow jor...@chromium.org wrote: We do that as well. What's the best way to do it API wise? Do we need to add an IDBTransactionError object with error codes and such? I don't actually know. I can't think of a precedence. Usually you use different error codes for different errors, but here we want to distinguish a particular type of error (aborts) into several sub categories. I don't see how that's any different than what we're doing with the onerror error codes though? Hmm.. true. To make this more complicated, I actually think we're going to end up having to change a lot of error handling when things are all said and done. Error handling right now is sort of a mess since DOM exceptions are vastly different from JavaScript exceptions. Also DOM exceptions have a messy situation of error codes overlapping making it very easy to confuse a IDBDatabaseException with a DOMException with an overlapping error code. For details, see http://lists.w3.org/Archives/Public/public-script-coord/2010OctDec/0112.html So my gut feeling is that we'll have to revamp exceptions quite a bit before we unprefix our implementation. This is very unfortunate, but shouldn't be as big deal of a deal as many other changes as most of the time people don't have error handling code. Or at least not error handling code that differentiates the various errors. Unfortunately we can't make any changes to the spec here until WebIDL prescribes what the new exceptions should look like :( So to loop back to your original question, I think that the best way to expose the different types of aborts is by adding a .reason (or better named) property which returns a string or enum which describes the reason for the abort. Could we just add .abortCode, .abortReason, and constants for each code to IDBTransaction? Why both? How are they different. I'd just go with the former to align with error codes. And maybe revisit in the future? Yes. I think we need to wait for webidl to solidify a bit here before we do anything. / Jonas
Re: [IndexedDB] Reason for aborting transactions
On Tue, Feb 8, 2011 at 2:21 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Feb 7, 2011 at 8:05 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Feb 7, 2011 at 7:36 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Jan 28, 2011 at 4:33 PM, Jeremy Orlow jor...@chromium.org wrote: We do that as well. What's the best way to do it API wise? Do we need to add an IDBTransactionError object with error codes and such? I don't actually know. I can't think of a precedence. Usually you use different error codes for different errors, but here we want to distinguish a particular type of error (aborts) into several sub categories. I don't see how that's any different than what we're doing with the onerror error codes though? Hmm.. true. To make this more complicated, I actually think we're going to end up having to change a lot of error handling when things are all said and done. Error handling right now is sort of a mess since DOM exceptions are vastly different from JavaScript exceptions. Also DOM exceptions have a messy situation of error codes overlapping making it very easy to confuse a IDBDatabaseException with a DOMException with an overlapping error code. For details, see http://lists.w3.org/Archives/Public/public-script-coord/2010OctDec/0112.html So my gut feeling is that we'll have to revamp exceptions quite a bit before we unprefix our implementation. This is very unfortunate, but shouldn't be as big deal of a deal as many other changes as most of the time people don't have error handling code. Or at least not error handling code that differentiates the various errors. Unfortunately we can't make any changes to the spec here until WebIDL prescribes what the new exceptions should look like :( So to loop back to your original question, I think that the best way to expose the different types of aborts is by adding a .reason (or better named) property which returns a string or enum which describes the reason for the abort. Could we just add .abortCode, .abortReason, and constants for each code to IDBTransaction? Why both? How are they different. I'd just go with the former to align with error codes. Sorry, I meant .abortMessage instead of .abortReason. This would be much like normal error messages where we have a code that's standardized and easy for scripts to understand and then the message portion which is easy for humans to understand but more ad-hoc. And maybe revisit in the future? Yes. I think we need to wait for webidl to solidify a bit here before we do anything. I think we should put something in our spec in the mean time, but once WebIDL solidifies then we can revisit and try to match what's decided there. On Tue, Feb 8, 2011 at 8:07 AM, ben turner bent.mozi...@gmail.com wrote: Why not just expand our list of error codes to have multiple ABORT_ variants for each situation, and then always fire the abort event with a slightly different errorCode? That seems far simpler IMO. If that is OK spec wise, I'm fine with it. To be honest, hanging ABORT_BLAHs off IDBDatabaseException seems a bit odd though. J
Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases
On Tue, Feb 8, 2011 at 3:36 AM, João Eiras joao.ei...@gmail.com wrote: Unless by certain GC behavior mean I referred to # The only solution I can think of is to require (or recommend) that implementations run the garbage collector The GC is transparent and a spec cannot expect that it runs at specific times or demand it. Yeah, Jonas. We can't reasonably expect any behavior from the garbage collectors. I can't think of any other precedent for this. And as collectors become more complicated, doing a gc that catches _every_ piece of garbage is becoming harder or even impossible (not aware of any GC's where it is impossible in specific cases, but it wouldn't surprise me). The v8 guys simply won't let us do this. :-) And saying that at the worst case your setVersion transaction will stall possibly forever just doesn't seem like a good solution either. What if we made the default for onsetversion to be calling close? I.e. instead of the close behavior being opt-out, it'd be opt-in? I know we made a conscious decision originally of it being opt-in, but I don't see how that'll work. J
Fullscreen API
Hi, folks- (BCC public-webapps, public-html. Apologies for the cross-post) Various people in various groups (as well as the community at large) have been emphasizing the need for fullscreen functionality. In the SVG WG, we had discussed the ability to make the root element fullscreen (this was a request a few years ago), but I like the idea of making individual elements (including grouping elements) fullscreen instead. The Mozilla FullScreen API [1] looks like a good start on this, and WebKit has picked up on this as well. It's been suggested to bring this to the WebApps WG, but there is no clear scope for this in the WebApps WG charter, and I'd be concerned about rechartering. the HTML WG was also suggested, but I as I understand it, they are trying to limit any new features for HTML5. Since a fullscreen mode is presentational, it arguably belongs in the CSS WG, but there isn't much work there done in APIs (other than CSS OM). So, my suggestion is that we work on it in the FX TF; we can add it explicitly to the SVG (and perhaps CSS) WG charters, which are up for review again soon. Since this is a public list, the WebApps and HTML WG participants could review and comment on it there. To some degree, it doesn't matter where it is done, as long as the right stakeholders are involved, and both the SVG and CSS WGs have participation by all the major browser vendors, among others. Thoughts? Is the FX TF willing to take this on? [1] https://wiki.mozilla.org/Gecko:FullScreenAPI Regards- -Doug Schepers W3C Team Contact, SVG, WebApps, and Web Events WGs
Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases
On Tue, Feb 8, 2011 at 9:26 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Feb 8, 2011 at 3:36 AM, João Eiras joao.ei...@gmail.com wrote: Unless by certain GC behavior mean I referred to # The only solution I can think of is to require (or recommend) that implementations run the garbage collector The GC is transparent and a spec cannot expect that it runs at specific times or demand it. Yeah, Jonas. We can't reasonably expect any behavior from the garbage collectors. I can't think of any other precedent for this. And as collectors become more complicated, doing a gc that catches _every_ piece of garbage is becoming harder or even impossible (not aware of any GC's where it is impossible in specific cases, but it wouldn't surprise me). The v8 guys simply won't let us do this. :-) And saying that at the worst case your setVersion transaction will stall possibly forever just doesn't seem like a good solution either. Huh? It seems like a very strange GC implementation that not only doesn't allow you to do a full search for garbage, even asynchronously, but then can't even guarantee that a given object will eventually be freed. I'm all for not relying on GC behavior, but not even relying on it to collect garbage? That seems a bit extreme to me. It's also not a GC strategy I've ever heard of, so yes, it would surprise me if there are GC strategies out there that doesn't free up objects sooner or later. How is that different from a GC strategy that is simply leaking? What if we made the default for onsetversion to be calling close? I.e. instead of the close behavior being opt-out, it'd be opt-in? I know we made a conscious decision originally of it being opt-in, but I don't see how that'll work. This flips the model completely on its head since you're now forced to implement a more advanced version upgrade strategies or suffer your pages breaking. The worst case scenario isn't even that bad IMHO. Say that you have a GC strategy which truly never frees the unreferenced DB object. That is no worse than the page simply holding a reference DB object and making the version upgrade wait for the user to close old tabs. Something that is bound to happen anyway if authors take the simple path of not listening to blocked or versionchange events. / Jonas
Re: Widgets - WARP, Widgets Updates and Digital Signatures
Nathan wrote: Marcos Caceres wrote: On 9/16/10 6:10 PM, Nathan wrote: Marcos Caceres wrote: As above. I thought that was what we (Web Apps WG - Widgets) have been doing for the last 5 years? Maybe I've missed part of the specifications - are you telling me that I can package up an HTML,CSS,JS based application as per the widgets specification, include a WARP, Digital Signature, set the view-mode to windowed and that this will run as is, in the main browser context of the main browser vendors (Firefox, Safari, Opera, Chrome, IE etc)? Ah! ok. I get it now. No, that won't work right now (actually, that's how we run them in our development environment for testing purposes :) ). But that is trivial and no one has really asked for that. Good to know, and you can consider me as asking for it! I'm still a bit lost as to what the use case is? following up, see Web Apps -- requirements for installation and management from TimBL: http://lists.w3.org/Archives/Public/www-tag/2011Feb/0078.html Best, Nathan
Re: [IndexedDB] Reason for aborting transactions
On Tue, Feb 8, 2011 at 9:16 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Feb 8, 2011 at 2:21 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Feb 7, 2011 at 8:05 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Feb 7, 2011 at 7:36 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Jan 28, 2011 at 4:33 PM, Jeremy Orlow jor...@chromium.org wrote: We do that as well. What's the best way to do it API wise? Do we need to add an IDBTransactionError object with error codes and such? I don't actually know. I can't think of a precedence. Usually you use different error codes for different errors, but here we want to distinguish a particular type of error (aborts) into several sub categories. I don't see how that's any different than what we're doing with the onerror error codes though? Hmm.. true. To make this more complicated, I actually think we're going to end up having to change a lot of error handling when things are all said and done. Error handling right now is sort of a mess since DOM exceptions are vastly different from JavaScript exceptions. Also DOM exceptions have a messy situation of error codes overlapping making it very easy to confuse a IDBDatabaseException with a DOMException with an overlapping error code. For details, see http://lists.w3.org/Archives/Public/public-script-coord/2010OctDec/0112.html So my gut feeling is that we'll have to revamp exceptions quite a bit before we unprefix our implementation. This is very unfortunate, but shouldn't be as big deal of a deal as many other changes as most of the time people don't have error handling code. Or at least not error handling code that differentiates the various errors. Unfortunately we can't make any changes to the spec here until WebIDL prescribes what the new exceptions should look like :( So to loop back to your original question, I think that the best way to expose the different types of aborts is by adding a .reason (or better named) property which returns a string or enum which describes the reason for the abort. Could we just add .abortCode, .abortReason, and constants for each code to IDBTransaction? Why both? How are they different. I'd just go with the former to align with error codes. Sorry, I meant .abortMessage instead of .abortReason. This would be much like normal error messages where we have a code that's standardized and easy for scripts to understand and then the message portion which is easy for humans to understand but more ad-hoc. And maybe revisit in the future? Yes. I think we need to wait for webidl to solidify a bit here before we do anything. I think we should put something in our spec in the mean time, but once WebIDL solidifies then we can revisit and try to match what's decided there. On Tue, Feb 8, 2011 at 8:07 AM, ben turner bent.mozi...@gmail.com wrote: Why not just expand our list of error codes to have multiple ABORT_ variants for each situation, and then always fire the abort event with a slightly different errorCode? That seems far simpler IMO. If that is OK spec wise, I'm fine with it. To be honest, hanging ABORT_BLAHs off IDBDatabaseException seems a bit odd though. I think at this point I've sort of lost track of what the proposal is. Is it simply making abort events look like error events, but obviously with .type set to abort. And give them codes which live side-by-side with the error codes? If so, that would be ok with me. / Jonas
Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases
On Tue, Feb 8, 2011 at 10:36 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Feb 8, 2011 at 9:26 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Feb 8, 2011 at 3:36 AM, João Eiras joao.ei...@gmail.com wrote: Unless by certain GC behavior mean I referred to # The only solution I can think of is to require (or recommend) that implementations run the garbage collector The GC is transparent and a spec cannot expect that it runs at specific times or demand it. Yeah, Jonas. We can't reasonably expect any behavior from the garbage collectors. I can't think of any other precedent for this. And as collectors become more complicated, doing a gc that catches _every_ piece of garbage is becoming harder or even impossible (not aware of any GC's where it is impossible in specific cases, but it wouldn't surprise me). The v8 guys simply won't let us do this. :-) And saying that at the worst case your setVersion transaction will stall possibly forever just doesn't seem like a good solution either. Huh? It seems like a very strange GC implementation that not only doesn't allow you to do a full search for garbage, even asynchronously, but then can't even guarantee that a given object will eventually be freed. I'm all for not relying on GC behavior, but not even relying on it to collect garbage? That seems a bit extreme to me. It's also not a GC strategy I've ever heard of, so yes, it would surprise me if there are GC strategies out there that doesn't free up objects sooner or later. How is that different from a GC strategy that is simply leaking? I meant that it wouldn't be able to collect on demand like that. Or that it would at least be prohibitively expensive. What if we made the default for onsetversion to be calling close? I.e. instead of the close behavior being opt-out, it'd be opt-in? I know we made a conscious decision originally of it being opt-in, but I don't see how that'll work. This flips the model completely on its head since you're now forced to implement a more advanced version upgrade strategies or suffer your pages breaking. The worst case scenario isn't even that bad IMHO. Say that you have a GC strategy which truly never frees the unreferenced DB object. That is no worse than the page simply holding a reference DB object and making the version upgrade wait for the user to close old tabs. Something that is bound to happen anyway if authors take the simple path of not listening to blocked or versionchange events. You're assuming implementations have one heap per tab. We could cheat and kill things when the document goes away, I suppose. Still not very excited about that tho. (Especially since even those semantics can be a bit tricky, at least in WebKit.) I'd like to hear other peoples' thoughts on this. J
Re: Widgets - WARP, Widgets Updates and Digital Signatures
Hi Tim, In [1], it sounds to me like you are after W3C Widgets [2]; we have almost finished standardizing them so no need to wait. You can play with them today in Opera [3] and a bunch of other great runtimes [4]. Kind regards, Marcos [1] http://lists.w3.org/Archives/Public/www-tag/2011Feb/0078.html [2] http://dev.w3.org/2006/waf/widgets/ [3] http://www.opera.com/download/ [4] http://www.w3.org/2008/webapps/wiki/WidgetImplementation On 2/8/11 6:37 PM, Nathan wrote: Nathan wrote: Marcos Caceres wrote: On 9/16/10 6:10 PM, Nathan wrote: Marcos Caceres wrote: As above. I thought that was what we (Web Apps WG - Widgets) have been doing for the last 5 years? Maybe I've missed part of the specifications - are you telling me that I can package up an HTML,CSS,JS based application as per the widgets specification, include a WARP, Digital Signature, set the view-mode to windowed and that this will run as is, in the main browser context of the main browser vendors (Firefox, Safari, Opera, Chrome, IE etc)? Ah! ok. I get it now. No, that won't work right now (actually, that's how we run them in our development environment for testing purposes :) ). But that is trivial and no one has really asked for that. Good to know, and you can consider me as asking for it! I'm still a bit lost as to what the use case is? following up, see Web Apps -- requirements for installation and management from TimBL: http://lists.w3.org/Archives/Public/www-tag/2011Feb/0078.html Best, Nathan -- Marcos Caceres Opera Software
Re: Fullscreen API
On Tue, Feb 8, 2011 at 6:14 PM, Doug Schepers schep...@w3.org wrote: Hi, folks- (BCC public-webapps, public-html. Apologies for the cross-post) Various people in various groups (as well as the community at large) have been emphasizing the need for fullscreen functionality. In the SVG WG, we had discussed the ability to make the root element fullscreen (this was a request a few years ago), but I like the idea of making individual elements (including grouping elements) fullscreen instead. The Mozilla FullScreen API [1] looks like a good start on this, and WebKit has picked up on this as well. (...) [1] https://wiki.mozilla.org/Gecko:FullScreenAPI Without a reference spec and looking at the Mozilla spec, I have many comments. Detecting fullscreen is something that belong 100% to media queries. Opera for instance, applies the projection media when the web page is rendered fullscreen. So, the CSS stuff in the Mozilla spec should be replaced with proper media queries, and the fullscreenchange event replaced with media query events. There is also some work already done with the @viewport CSS rule proposed by Rune Lillesveen from Opera [1] which was based on Webkit's meta+viewport element support, which in tandem with its meta+apple-mobile-web-app-capable allows pages to go fullscreen. I would suggest keeping everything in CSS, therefore dropping the dependencies on overloading meta. [2] Regarding the web page requesting full screen access, I regard it as dangerous, disruptive and unnecessary. If element ought to be rendered fullscreen, they can be styled with position:fixed;top:0;left:0;width:100%;height:100%;z-index:1000. Then if the UA user wishes, he/she can toggle the browser to go fullscreen (F11 in any browser), else content just fits the viewport. Toggling fullscreen for inlines like images, video, canvas would work the same, although the user agent can provide the user more accessibility, like double clicking video to go fullscreen, as it already happens in any desktop media player. If this is acceptable, the same level of functionality is preserved, the user is not annoyed, no new APIs are needed to be specified, and the spoofing issues are minimized to irrelevance. So, to summarize, this is mostly work for CSS media queries, and its DOM bindings. [1] http://people.opera.com/rune/TR/css-viewport/ [2] http://developer.apple.com/library/safari/#documentation/AppleApplications/Reference/SafariHTMLRef/Articles/MetaTags.html
Mouse Capture for Canvas
The main idea is here in bugzilla: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9557#c4 I'll post it here though since Doug said this might get more people to see it. The idea would be to allow the browser to capture, as in lock the mouse to a certain DOM region such as a canvas tag. Thinking back on this I realized a few things were missing from the initial idea so I'll explain the whole concept in more detail. The MouseEvent would need two new members: deltaX deltaY Which in the mousemove event would be set to the change in the mouse position. So if you move your mouse left 5 pixels deltaX would be set to -5 and if you moved the mouse up 5 pixels deltaY would be set to -5. To keep this as simple as possible a developer would create a canvas tag on their web page then add a mousecapture, mousemove, mouseup, and mousedown event to it. The new mousecapture event would be fired when a user clicked on the element. Unless anyone can think of a reason I don't see why any other tag should be able to use that event. mousecapture would run before click: http://www.w3.org/TR/2010/WD-DOM-Level-3-Events-20100907/#events-mouseevent-event-order In the mousecapture event a user-agent can do whatever it wants to help the user. It could make a small yellow bar like in chrome or firefox and say This website is requesting to capture your mouse. [Allow] [Deny]. If denied the event would never be called. If allowed the event wouldn't be called until the user clicked a second time. The user-agent could handle this how they wanted. A user-agent would also define a key to release mouse capture. (Probably Esc, but there's no need to define it in the standard except as a suggestion). Implementers would be encouraged to display something over the page that says Press key to release mouse capture. With the mousecapture is a mouserelease event which when registered on the same canvas tag responds when the user presses the release key. The event actually does the unregistering. The mouserelease would need to be callable to allow a web page to release control when it wanted, but the mousecapture can't be callable since that would allow someone to capture a mouse without a click. A situation that needs to be handled is alt-tabbing or general loss of focus from a tab or the browser. During these situations the simplest thing to do is to call the mouserelease event. The user would need to click to regain mouse capture. That sums up everything. Obviously it could be implemented differently, but I think I outlined what's needed.
Re: [IndexedDB] Reason for aborting transactions
I think that's what Ben was suggesting. Yes. We already have ABORT_ERR, no reason we can't subdivide that since it's being overloaded. In fact I think it makes perfect sense. Add the following to IDBTransaction: I'm really not a fan of making IDBTransaction more complicated. We already have a generic tell me when something goes wrong, and why mechanism via errorCode and onError/onAbort. Why add another one? If the name is confusing we could rename it to exceptionCode perhaps? readonly attribute abortMessage; We dropped errorMessage already, let's not add abortMessage. And just set the message/code right before firing an abort event. And what happens when someone calls .abortCode before the transaction has finished? Or if the transaction succeeded? Or if the transaction failed for some other reason? I think we'd probably want the same behavior as calling .errorCode, so again I think we should just roll the specific abort reasons into error codes and stick with our existing mechanism. -Ben
Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases
I'm actually fine with keeping the setVersion from proceeding until the old database is collected. First, this is probably a bug in the web page, and the page should be fixed. Second, the new database that is waiting for setVersion to proceed will get an onblocked event, so the page should know that something is wrong. I really don't think this is that big of a deal, and certainly not worth changing the opt-in vs. opt-out behavior that we've settled on. -Ben
Re: [widgets] Questions regarding to Test Suite for the XML Digital Signatures For Widgets Specification
Hi Andrey, I'll try to look into this this week. We've also updated the test suite to address the issues you outlined in your previous email. I've also updated the spec so the that vendors can define their own transform (instead of forcing 1.1). On 2/2/11 7:34 AM, Andrey Nazarov wrote: Thank you, I have one more question: Test 19dsa.wgt. The deal is when I look on the certificate that is used for this test I see that it contains information about DSA Public Key, but the Signature Algorithm for this certificate is pointed as SHA1withRSA. Is it correct? I am not familiar with DSA algorithm.But in other places where I look into certificate with DSA Public Key, I saw that certificate is signed with DSA and the SHA-1 hash algorithm (for instance here: http://www.ietf.org/rfc/rfc2459.txt) Also as I understand the signature value after DSA algorithm using shall contain two big integer, written in the (ASN.1) form, but in this test I see only some byte array without any ASN.1 tags. May be the signature value is packed somehow? Haw can I unpack it? Regards, Andrey On 1/31/2011 9:52 PM, Arthur Barstow wrote: Andrey - on January 26, Marcos proposed changing the c14n algorithm in [1] and [2] and notified the group in [3] that he updated the Editor's Draft [ED] to reflect his proposal. He included rationale in [1]. -- Marcos Caceres Opera Software
Re: [IndexedDB] Reason for aborting transactions
On Tue, Feb 8, 2011 at 11:37 AM, ben turner bent.mozi...@gmail.com wrote: I think that's what Ben was suggesting. Yes. We already have ABORT_ERR, no reason we can't subdivide that since it's being overloaded. In fact I think it makes perfect sense. That part of the spec seems completely broken (there are no steps to abort a transaction in the spec and it's not clear how ABORT_ERR would be plugged in). Either way, ABORT_ERR should probably be removed. Add the following to IDBTransaction: I'm really not a fan of making IDBTransaction more complicated. We already have a generic tell me when something goes wrong, and why mechanism via errorCode errorCode is something on the IDBRequest object these days, right? Clearly we can't use that when we're in an abort handler to figure out why we were aborted. I'm pretty sure we need to add a code (no matter what we name it and where the code enums live) to IDBtransaction. and onError/onAbort. Why add another one? If the name is confusing we could rename it to exceptionCode perhaps? readonly attribute abortMessage; We dropped errorMessage already, let's not add abortMessage. We did? When and why? I think the text based messages can be very useful for debugging. And they're there for exceptions. And just set the message/code right before firing an abort event. And what happens when someone calls .abortCode before the transaction has finished? Or if the transaction succeeded? What happens when you try to access the error code on IDBRequest today? (Serious question, I don't remember.) Or if the transaction failed for some other reason? If it fails for any reason, it'll result in an abort. I think we'd probably want the same behavior as calling .errorCode, so again I think we should just roll the specific abort reasons into error codes and stick with our existing mechanism. The existing mechanism doesn't fix the use case of being in an abort event handler and wanting to know why you aborted. J
Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases
2011/2/8 Jeremy Orlow jor...@chromium.org: On Tue, Feb 8, 2011 at 10:36 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Feb 8, 2011 at 9:26 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Feb 8, 2011 at 3:36 AM, João Eiras joao.ei...@gmail.com wrote: Unless by certain GC behavior mean I referred to # The only solution I can think of is to require (or recommend) that implementations run the garbage collector The GC is transparent and a spec cannot expect that it runs at specific times or demand it. Yeah, Jonas. We can't reasonably expect any behavior from the garbage collectors. I can't think of any other precedent for this. And as collectors become more complicated, doing a gc that catches _every_ piece of garbage is becoming harder or even impossible (not aware of any GC's where it is impossible in specific cases, but it wouldn't surprise me). The v8 guys simply won't let us do this. :-) And saying that at the worst case your setVersion transaction will stall possibly forever just doesn't seem like a good solution either. Huh? It seems like a very strange GC implementation that not only doesn't allow you to do a full search for garbage, even asynchronously, but then can't even guarantee that a given object will eventually be freed. I'm all for not relying on GC behavior, but not even relying on it to collect garbage? That seems a bit extreme to me. It's also not a GC strategy I've ever heard of, so yes, it would surprise me if there are GC strategies out there that doesn't free up objects sooner or later. How is that different from a GC strategy that is simply leaking? I meant that it wouldn't be able to collect on demand like that. Or that it would at least be prohibitively expensive. That I can understand, which is why I said or recommend. I suspect that in firefox it will get harder to do a synchronous GC, but a asynchronous one seems like it will remain possible. But even if you don't do anything, we'll always end up running GC at *some* point. What if we made the default for onsetversion to be calling close? I.e. instead of the close behavior being opt-out, it'd be opt-in? I know we made a conscious decision originally of it being opt-in, but I don't see how that'll work. This flips the model completely on its head since you're now forced to implement a more advanced version upgrade strategies or suffer your pages breaking. The worst case scenario isn't even that bad IMHO. Say that you have a GC strategy which truly never frees the unreferenced DB object. That is no worse than the page simply holding a reference DB object and making the version upgrade wait for the user to close old tabs. Something that is bound to happen anyway if authors take the simple path of not listening to blocked or versionchange events. You're assuming implementations have one heap per tab. Not at all. I'm just assuming GC will run in all heaps at some point. We could cheat and kill things when the document goes away, I suppose. Still not very excited about that tho. (Especially since even those semantics can be a bit tricky, at least in WebKit.) Wait, you're worried that you won't even run GC once the user leaves the page? I thought that in that case chrome just killed the process. Surely that will close any open databases? / Jonas
Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases
On 2/8/2011 11:51 AM, ben turner wrote: I'm actually fine with keeping the setVersion from proceeding until the old database is collected. First, this is probably a bug in the web page, and the page should be fixed. Second, the new database that is waiting for setVersion to proceed will get an onblocked event, so the page should know that something is wrong. I really don't think this is that big of a deal, and certainly not worth changing the opt-in vs. opt-out behavior that we've settled on. Agreed. Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: Mouse Capture for Canvas
IE has a setCapture DOM API. We've implemented it in Gecko: https://developer.mozilla.org/en/DOM/element.setCapture Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: Fullscreen API
On Tue, Feb 8, 2011 at 7:49 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Wed, Feb 9, 2011 at 7:53 AM, João Eiras joao.ei...@gmail.com wrote: Detecting fullscreen is something that belong 100% to media queries. Opera for instance, applies the projection media when the web page is rendered fullscreen. So, the CSS stuff in the Mozilla spec should be replaced with proper media queries, and the fullscreenchange event replaced with media query events. The :full-screen-document pseudo-class could be replaced with a media query, and that's probably a good idea. Thanks! The :full-screen pseudo-class cannot since it applies to the full-screen element, and media query state is per-document. That works just as fine if a class is used. Regarding the web page requesting full screen access, I regard it as dangerous, disruptive and unnecessary. If element ought to be rendered fullscreen, they can be styled with position:fixed;top:0;left:0;width:100%;height:100%;z-index:1000. Then if the UA user wishes, he/she can toggle the browser to go fullscreen (F11 in any browser), else content just fits the viewport. Like it or not (and I don't!), Web developers are used to having in-page fullscreen UI because Flash provides it, and users are used to finding it there. It's also generally more discoverable than F11 or whatever the browser UI is. So there does need to be a way for the page to request full-screen. Whether F11, double clicking, a context menu option, zooming or a gesture, are discoverable or not, it's a user agent UI issue, although a requestFullscreen() call could hint the UA that the webpage *suggests* going fullscreen, but then there is the spoofing/social engineering issue.
Re: Widgets - WARP, Widgets Updates and Digital Signatures
On 8 Feb 2011, at 18:48, Marcos Caceres wrote: Hi Tim, In [1], it sounds to me like you are after W3C Widgets [2]; we have almost finished standardizing them so no need to wait. You might also find this post useful: http://scottbw.wordpress.com/2011/02/08/web-apps-a-snapshot-of-the-standards-landscape/ You can play with them today in Opera [3] and a bunch of other great runtimes [4]. Kind regards, Marcos [1] http://lists.w3.org/Archives/Public/www-tag/2011Feb/0078.html [2] http://dev.w3.org/2006/waf/widgets/ [3] http://www.opera.com/download/ [4] http://www.w3.org/2008/webapps/wiki/WidgetImplementation On 2/8/11 6:37 PM, Nathan wrote: Nathan wrote: Marcos Caceres wrote: On 9/16/10 6:10 PM, Nathan wrote: Marcos Caceres wrote: As above. I thought that was what we (Web Apps WG - Widgets) have been doing for the last 5 years? Maybe I've missed part of the specifications - are you telling me that I can package up an HTML,CSS,JS based application as per the widgets specification, include a WARP, Digital Signature, set the view-mode to windowed and that this will run as is, in the main browser context of the main browser vendors (Firefox, Safari, Opera, Chrome, IE etc)? Ah! ok. I get it now. No, that won't work right now (actually, that's how we run them in our development environment for testing purposes :) ). But that is trivial and no one has really asked for that. Good to know, and you can consider me as asking for it! I'm still a bit lost as to what the use case is? following up, see Web Apps -- requirements for installation and management from TimBL: http://lists.w3.org/Archives/Public/www-tag/2011Feb/0078.html Best, Nathan -- Marcos Caceres Opera Software smime.p7s Description: S/MIME cryptographic signature
[Bug 12016] New: After page unload, all IDBDatabases attached to the document should have .close() called on them
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12016 Summary: After page unload, all IDBDatabases attached to the document should have .close() called on them Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: dave.n...@w3.org ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org After page unload, all IDBDatabases attached to the document should have .close() called on them. See [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases for more backstory. -- 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.
Re: Fullscreen API
On Wed, Feb 9, 2011 at 9:12 AM, João Eiras joao.ei...@gmail.com wrote: On Tue, Feb 8, 2011 at 7:49 PM, Robert O'Callahan rob...@ocallahan.org wrote: The :full-screen-document pseudo-class could be replaced with a media query, and that's probably a good idea. Thanks! The :full-screen pseudo-class cannot since it applies to the full-screen element, and media query state is per-document. That works just as fine if a class is used. You mean have the author set a class on the element? That requires more author coding; removing the class would be tricky. Also, you can't handle the case where an IFRAME (possibly cross-origin) wants to go full-screen ... you'd need to set class values all the way up the document hierarchy. Whether F11, double clicking, a context menu option, zooming or a gesture, are discoverable or not, it's a user agent UI issue, I don't know of anything as discoverable as a button in the Web page next to the rest of the video controls (for example). although a requestFullscreen() call could hint the UA that the webpage *suggests* going fullscreen, but then there is the spoofing/social engineering issue. That's pretty much what the proposed spec says. It addresses (or permits addressing) the spoofing issues reasonably well IMHO. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: Fullscreen API
On Tue, Feb 8, 2011 at 3:12 PM, João Eiras joao.ei...@gmail.com wrote: Regarding the web page requesting full screen access, I regard it as dangerous, disruptive and unnecessary. It's only dangerous or disruptive if implemented carelessly. It's simply false to claim it's unnecessary. - Video players must be able to go fullscreen when the video is double-clicked; that's a fundamental UI. - I shouldn't have to manually fullscreen a game every time I load it. - Browser fullscreening doesn't allow you to determine which element is being brought fullscreen, if there's more than one candidate. - There are many other interesting use cases which browser controls don't address at all; for example, native image viewers often show thumbnails and only go fullscreen when an image is selected. -- Glenn Maynard
Re: Mouse Capture for Canvas
This API doesn't handle all of the desired use cases. In particular, to implement Quake-style mouse look (needed for e.g. http://code.google.com/p/quake2-gwt-port/) it needs to work when the mouse button is up, not just down. -Ken On Tue, Feb 8, 2011 at 12:11 PM, Robert O'Callahan rob...@ocallahan.org wrote: IE has a setCapture DOM API. We've implemented it in Gecko: https://developer.mozilla.org/en/DOM/element.setCapture Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases
On Tue, Feb 8, 2011 at 3:31 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Feb 8, 2011 at 4:01 PM, Jeremy Orlow jor...@chromium.org wrote: I talked it over with Darin (Fisher), and he largely agreed with you guys. I'll file a bug saying that after unload, all IDBDatabases attached to that document should be closed. What happens if a database is open in a page in the back-forward cache? That's incompatible with onunload having side-effects. I know the BF-cache is off-spec, but it's extremely useful and will hopefully find its way into the standard some day, so it'd be nice to keep it in mind. As long as the behavior as far as developers can tell matches the spec, you can do just about whatever you'd like behind the scenes. I suppose the browser would discard whole pages from the BF-cache on demand if required by a setVersion call. That sounds like it'd more or less work. J
Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases
On Tue, Feb 8, 2011 at 3:31 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Feb 8, 2011 at 4:01 PM, Jeremy Orlow jor...@chromium.org wrote: I talked it over with Darin (Fisher), and he largely agreed with you guys. I'll file a bug saying that after unload, all IDBDatabases attached to that document should be closed. What happens if a database is open in a page in the back-forward cache? That's incompatible with onunload having side-effects. I know the BF-cache is off-spec, but it's extremely useful and will hopefully find its way into the standard some day, so it'd be nice to keep it in mind. I suppose the browser would discard whole pages from the BF-cache on demand if required by a setVersion call. That's exactly what we do in Firefox. Implementations have to be able to throw things out of the BF cache on command anyway (since you generally want to limit the number of pages living in BF cache, and so loading a new page often causes other pages to be thrown out), so it's just a matter of calling into the same code here. / Jonas
Re: Mouse Capture for Canvas
On Tue, Feb 8, 2011 at 5:49 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Wed, Feb 9, 2011 at 11:37 AM, Kenneth Russell k...@google.com wrote: This API doesn't handle all of the desired use cases. In particular, to implement Quake-style mouse look (needed for e.g. http://code.google.com/p/quake2-gwt-port/) it needs to work when the mouse button is up, not just down. How would you satisfy that use-case without enabling abusive behavior by Web sites? Per the proposal posted earlier and at http://www.w3.org/Bugs/Public/show_bug.cgi?id=9557 : 1. Only enable mouse capture in response to a user gesture (clicking on the element). 2. Possibly require confirmation from the user to enter mouse capture mode. 3. Present clear UI to indicate how to exit mouse capture mode. -Ken (I think that case would work with our API if the game was full-screen, which I expect it normally would be.) Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: Mouse Capture for Canvas
(Not sure how to reply to a mailing list with yahoo mail so this might not work or it might) On Tue, Feb 8, 2011 at 5:49 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Wed, Feb 9, 2011 at 11:37 AM, Kenneth Russell k...@google.com wrote: This API doesn't handle all of the desired use cases. In particular, to implement Quake-style mouse look (needed for e.g. http://code.google.com/p/quake2-gwt-port/) it needs to work when the mouse button is up, not just down. How would you satisfy that use-case without enabling abusive behavior by Web sites? (I think that case would work with our API if the game was full-screen, which I expect it normally would be.) Rob Actually this would be used for both fullscreen and non-fullscreen applications. The reason for this is because it's often CPU intensive to run a complex canvas application in fullscreen. Another key part that Kenneth mentioned was the ability to get deltaX and deltaY of the mouse which is very powerful when you have the mouse locked. In games this allows you to move your mouse to edge of the canvas element and continue to detect mouse changes whereas in a fullscreen application moving your mouse to the left side will lock to 0 for the x mouse position even though the mouse may still be moving left. The deltaX would say like -12 for instance showing the person is still moving left. Hopefully that clears things up.
Re: Mouse Capture for Canvas
On Tue, Feb 8, 2011 at 8:54 PM, Kenneth Russell k...@google.com wrote: How would you satisfy that use-case without enabling abusive behavior by Web sites? Per the proposal posted earlier and at http://www.w3.org/Bugs/Public/show_bug.cgi?id=9557 : 1. Only enable mouse capture in response to a user gesture (clicking on the element). This proposal seems to say that mouse capture is enabled by adding an event handler to an element. I don't like this: - It's a major break from the normal event model. Merely defining an event shouldn't cause side-effects. - It permanently bakes the requirement that mouse capture can only happen in response to a click into the API. There are legitimate cases to capture the mouse without first requiring a click. Browsers may not want to allow this, but if they can do so without causing abuse then it should be possible to do so. This is very similar to mouse capture at the OS level, where users needs to be able to escape from misbehaving mouse-capturing applications. It may be worth comparing the interfaces used for that to see if they can be applied to web apps. Also note that as fullscreen and mouse capture often go together, the mouseover the top of the screen mechanisms associated with fullscreen won't work when both are enabled. (I'm not a fan of that UI, either, as they take over the top portion of the screen, preventing UIs from putting menus there.) For an API, I'd suggest simply adding element.captureMouse() and element.releaseMouse(), with events when the mouse is actually captured and released. Browsers can still choose to ignore captureMouse if not called in response to a click, and the spec can require that at the start if that's really wanted, but that behavior isn't baked permanently into the API and could be relaxed later on. Note that mouse capture may be the wrong name for this. Mouse capture usually refers to capturing mouse movement even when the mouse leaves the window, usually to implement dragging--this is what IE's mouse capture API is for. This is different--the mouse cursor is typically hidden and locked in place, so mouse motion never hits the boundaries of the screen and clicks never go to another window. It might be better to call this something else to avoid confusion with regular mouse capture; I'd suggest mouse grabbing. -- Glenn Maynard
Re: Mouse Capture for Canvas
On Tue, Feb 8, 2011 at 10:27 PM, Charles Pritchard ch...@jumis.com wrote: - It's a major break from the normal event model. Merely defining an event shouldn't cause side-effects. This proposal seems to say that mouse capture is enabled by adding an event handler to an element. I don't like this: window.open is another item that only fires during an event handle. I'm sure full screen is on that grounds. Drag+drop does that. [input type=file] is another. Sorry, that's not what I meant. It's OK--if less than ideal--for functionality to *only be available* during certain events. What I meant was that this proposal seems to cause mouse capture to happen as a side-effect of the event handler being set at all. Adding the mousecapture event causes clicking the element to capture. That's what I don't like in particular. User initiated events are part of the security model; and the current issues with mouse capture are about security. I typed this before but elided it since my mail got too long: window.open is an example of why restricting these things to clicks doesn't work very well. Browsers tried to prevent unwanted popups by only allowing them during clicks, and now instead of popups opening when you load a page, they open the first time you click anywhere in the window. That said, it would still help prevent non-malicious but misbehaving scripts from accidentally taking over the browser, which can happen anywhere, even on trusted sites. However, that's just one possible way of dealing with that problem, and browsers should be able to look for less restrictive solutions (which is what I had in mind when I referred to how operating systems deal with this). -- Glenn Maynard
Re: Mouse Capture for Canvas
On 2/8/2011 8:03 PM, Glenn Maynard wrote: On Tue, Feb 8, 2011 at 10:27 PM, Charles Pritchard ch...@jumis.com mailto:ch...@jumis.com wrote: - It's a major break from the normal event model. Merely defining an event shouldn't cause side-effects. This proposal seems to say that mouse capture is enabled by adding an event handler to an element. I don't like this: window.open is another item that only fires during an event handle. I'm sure full screen is on that grounds. Drag+drop does that. [input type=file] is another. Sorry, that's not what I meant. It's OK--if less than ideal--for functionality to *only be available* during certain events. What I meant was that this proposal seems to cause mouse capture to happen as a side-effect of the event handler being set at all. Adding the mousecapture event causes clicking the element to capture. That's what I don't like in particular. I missed that (mousecapture). User initiated events are part of the security model; and the current issues with mouse capture are about security. I typed this before but elided it since my mail got too long: window.open is an example of why restricting these things to clicks doesn't work very well. Browsers tried to prevent unwanted popups by only allowing them during clicks, and now instead of popups opening when you load a page, they open the first time you click anywhere in the window. I've found it to be an improvement. If I don't click on a page, it's not going to spring nastiness on me. Passive indicators provide some middle ground, though I find it to be a little difficult with [html manifest] in Firefox, but it's still an improvement. That said, it would still help prevent non-malicious but misbehaving scripts from accidentally taking over the browser, which can happen anywhere, even on trusted sites. However, that's just one possible way of dealing with that problem, and browsers should be able to look for less restrictive solutions (which is what I had in mind when I referred to how operating systems deal with this). Trusted sites aren't well defined, so for the time being, I'm fine with them taking over the browser. As I understand things, operating systems have their function keys: the Windows key, the Mac key, the single special button on the iPhone, and so on. (I use Win all the time when things go wrong) Otherwise, they haven't gotten any further on the issue. Well... there's also the reset key, the power button, and the plug that runs out of the computer, or the switch that releases the battery.
