Re: Mouse Capture for Canvas

On Tue, Feb 8, 2011 at 11:09 PM, Charles Pritchard wrote: > 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 tha

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 > 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 e

Re: Mouse Capture for Canvas

On Tue, Feb 8, 2011 at 10:27 PM, Charles Pritchard 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: >

Re: Mouse Capture for Canvas

On 2/8/2011 7:18 PM, Glenn Maynard wrote: On Tue, Feb 8, 2011 at 8:54 PM, Kenneth Russell > 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/Pu

Re: Mouse Capture for Canvas

On Tue, Feb 8, 2011 at 8:54 PM, Kenneth Russell 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

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 wrote: > On Wed, Feb 9, 2011 at 11:37 AM, Kenneth Russell wrote: >> > >> This API doesn't handle all of the desired use cases. In particular, >> to

Re: Mouse Capture for Canvas

On Tue, Feb 8, 2011 at 5:49 PM, Robert O'Callahan wrote: > On Wed, Feb 9, 2011 at 11:37 AM, Kenneth Russell 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 ne

Re: Mouse Capture for Canvas

On Wed, Feb 9, 2011 at 11:37 AM, Kenneth Russell 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

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Tue, Feb 8, 2011 at 3:31 PM, Glenn Maynard wrote: > On Tue, Feb 8, 2011 at 4:01 PM, Jeremy Orlow 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.

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Tue, Feb 8, 2011 at 4:01 PM, Jeremy Orlow 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-f

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Tue, Feb 8, 2011 at 3:31 PM, Glenn Maynard wrote: > On Tue, Feb 8, 2011 at 4:01 PM, Jeremy Orlow 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.

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 wrote: > IE ha

Re: Fullscreen API

On Tue, Feb 8, 2011 at 3:12 PM, João Eiras 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 m

Re: Fullscreen API

On Wed, Feb 9, 2011 at 9:12 AM, João Eiras wrote: > On Tue, Feb 8, 2011 at 7:49 PM, Robert O'Callahan > 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

[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

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

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. J On Tue, Feb 8, 2011 at 11:51 AM, ben turner wrote: > I'm actually fine with keeping the setVersion from proceeding

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-standa

Re: Fullscreen API

On Tue, Feb 8, 2011 at 7:49 PM, Robert O'Callahan wrote: > On Wed, Feb 9, 2011 at 7:53 AM, João Eiras 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 st

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 wha

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 on

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

2011/2/8 Jeremy Orlow : > On Tue, Feb 8, 2011 at 10:36 AM, Jonas Sicking wrote: >> >> On Tue, Feb 8, 2011 at 9:26 AM, Jeremy Orlow wrote: >> > On Tue, Feb 8, 2011 at 3:36 AM, João Eiras wrote: >> >> >> >> > Unless by "certain GC behavior" mean >> >> >> >> I referred to >> >> >> >> # The only sol

Re: [IndexedDB] Reason for aborting transactions

On Tue, Feb 8, 2011 at 11:37 AM, ben turner 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 n

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 (instead of forcing 1.1). On 2/2/11 7:34 AM, Andrey Nazarov wrote: Thank you, I

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 tha

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

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 b

Re: Fullscreen API

On Tue, Feb 8, 2011 at 6:14 PM, Doug Schepers 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 di

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/

Re: [IndexedDB] Reason for aborting transactions

On Tue, Feb 8, 2011 at 10:38 AM, Jonas Sicking wrote: > On Tue, Feb 8, 2011 at 9:16 AM, Jeremy Orlow wrote: > > On Tue, Feb 8, 2011 at 2:21 AM, Jonas Sicking wrote: > >> > >> On Mon, Feb 7, 2011 at 8:05 PM, Jeremy Orlow > wrote: > >> > On Mon, Feb 7, 2011 at 7:36 PM, Jonas Sicking > wrote: >

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Tue, Feb 8, 2011 at 10:36 AM, Jonas Sicking wrote: > On Tue, Feb 8, 2011 at 9:26 AM, Jeremy Orlow wrote: > > On Tue, Feb 8, 2011 at 3:36 AM, João Eiras wrote: > >> > >> > Unless by "certain GC behavior" mean > >> > >> I referred to > >> > >> # The only solution I can think of is to require (

Re: [IndexedDB] Reason for aborting transactions

On Tue, Feb 8, 2011 at 9:16 AM, Jeremy Orlow wrote: > On Tue, Feb 8, 2011 at 2:21 AM, Jonas Sicking wrote: >> >> On Mon, Feb 7, 2011 at 8:05 PM, Jeremy Orlow wrote: >> > On Mon, Feb 7, 2011 at 7:36 PM, Jonas Sicking wrote: >> >> >> >> On Fri, Jan 28, 2011 at 4:33 PM, Jeremy Orlow >> >> wrote:

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,J

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Tue, Feb 8, 2011 at 9:26 AM, Jeremy Orlow wrote: > On Tue, Feb 8, 2011 at 3:36 AM, João Eiras 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 >> >> Th

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

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Tue, Feb 8, 2011 at 3:36 AM, João Eiras 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 > sp

Re: [IndexedDB] Reason for aborting transactions

On Tue, Feb 8, 2011 at 2:21 AM, Jonas Sicking wrote: > On Mon, Feb 7, 2011 at 8:05 PM, Jeremy Orlow wrote: > > On Mon, Feb 7, 2011 at 7:36 PM, Jonas Sicking wrote: > >> > >> On Fri, Jan 28, 2011 at 4:33 PM, Jeremy Orlow > wrote: > >> > We do that as well. > >> > What's the best way to do it AP

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 wrote: > On Mon, Feb 7, 2011 at 8:05 PM, Je

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] setVersion blocked on uncollected garbage IDBDatabases

On Tue, Feb 8, 2011 at 3:26 AM, Jonas Sicking wrote: > On Tue, Feb 8, 2011 at 3:20 AM, João Eiras wrote: >> On Tue, Feb 8, 2011 at 10:52 AM, Jonas Sicking wrote: >>> On Tue, Feb 8, 2011 at 2:45 AM, João Eiras wrote: > The only solution I can think of is to require (or recommend) that >

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Tue, Feb 8, 2011 at 3:20 AM, João Eiras wrote: > On Tue, Feb 8, 2011 at 10:52 AM, Jonas Sicking wrote: >> On Tue, Feb 8, 2011 at 2:45 AM, João Eiras wrote: The only solution I can think of is to require (or recommend) that implementations run the garbage collector in a context after

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Tue, Feb 8, 2011 at 10:52 AM, Jonas Sicking wrote: > On Tue, Feb 8, 2011 at 2:45 AM, João Eiras 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 st

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Tue, Feb 8, 2011 at 2:45 AM, João Eiras 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

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

Re: [IndexedDB] Reason for aborting transactions

On Mon, Feb 7, 2011 at 8:05 PM, Jeremy Orlow wrote: > On Mon, Feb 7, 2011 at 7:36 PM, Jonas Sicking wrote: >> >> On Fri, Jan 28, 2011 at 4:33 PM, Jeremy Orlow 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 er

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Mon, Feb 7, 2011 at 8:09 PM, Jeremy Orlow 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 i

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 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 =

Re: [XHR2] FormData for

On Tue, 14 Sep 2010 20:19:27 +0200, Jonas Sicking wrote: On Tue, Sep 14, 2010 at 11:04 AM, Anne van Kesteren 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