RE: [IndexedDB] Reason for aborting transactions

(back!) From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Jeremy Orlow Sent: Wednesday, February 09, 2011 6:47 PM >> On Wed, Feb 9, 2011 at 5:54 PM, Jonas Sicking wrote: >> On Wed, Feb 9, 2011 at 5:43 PM, Jeremy Orlow wrote: >> > On Wed, Feb 9, 2011 at 5:3

[Bug 12027] New: 呵呵呵 as these tend to change rapidly and make your feedback hard

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12027 Summary: 呵呵呵 as these tend to change rapidly and make your feedback hard Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-ap

Re: Mouse Capture for Canvas

> On Wed, Feb 9, 2011 at 11:37 PM, Brandon Andrews > wrote: >> So what you'd prefer would be to allow the mouse to call >> element.lockMouse(), >>element.unlockMouse() whenever it wanted. Then assume the user-agent will >>perform restrictions? >> These restrictions would be asking the user to a

Re: Mouse Capture for Canvas

On Wed, Feb 9, 2011 at 11:37 PM, Brandon Andrews < warcraftthre...@sbcglobal.net> wrote: > So what you'd prefer would be to allow the mouse to call element.lockMouse(), element.unlockMouse() whenever it wanted. Then assume the user-agent will perform restrictions? > These restrictions would be aski

Re: Mouse Capture for Canvas

On Thu, Feb 10, 2011 at 12:25 AM, Robert O'Callahan wrote: > On Thu, Feb 10, 2011 at 5:32 PM, Glenn Maynard wrote: > >> It applies to non-game uses, too. For example, a common annoyance with >> Google Maps is when you're dragging the map and your mouse cursor hits the >> side of the screen, the

Re: Mouse Capture for Canvas

> On Wed, Feb 9, 2011 at 9:20 PM, Brandon Andrews > >wrote: >>> If I load a first-person game in a tab, I shouldn't need to click >the window >>> to allow the page to capture the mouse. That'll force every game >to >>> start >>> with a superfluous box saying "click here to start".

Re: Mouse Capture for Canvas

On Thu, Feb 10, 2011 at 5:32 PM, Glenn Maynard wrote: > It applies to non-game uses, too. For example, a common annoyance with > Google Maps is when you're dragging the map and your mouse cursor hits the > side of the screen, the map stops moving; you have to release the button and > reposition

Re: Mouse Capture for Canvas

On Wed, Feb 9, 2011 at 10:52 PM, Robert O'Callahan wrote: > What are some real use-cases for capturing with the mouse up in > non-fullscreen windows? Do a significant number of users want to play > mouse-capturing games in non-fullscreen mode? > I'd certainly want to be able to debug them in a wi

Re: [IndexedDB] Reason for aborting transactions

On Wed, Feb 9, 2011 at 9:46 PM, Jonas Sicking wrote: > > - Some errors are implementation-specific. For example, if "internal > error" > > is caused by SQLite under the hood returning an unexpected error that the > > browser can't recover from, the browser could include the SQLite error > > mess

Re: Mouse Capture for Canvas

On Wed, Feb 9, 2011 at 3:55 PM, Brandon Andrews < warcraftthre...@sbcglobal.net> wrote: > 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. > Looking f

Re: Mouse Capture for Canvas

On Wed, Feb 9, 2011 at 9:20 PM, Brandon Andrews < warcraftthre...@sbcglobal.net> wrote: > > If I load a first-person game in a tab, I shouldn't need to click the window > > to allow the page to capture the mouse. That'll force every game to start > > with a superfluous box saying "click here to st

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Wed, Feb 9, 2011 at 6:12 PM, Glenn Maynard wrote: > On Wed, Feb 9, 2011 at 8:39 PM, Jonas Sicking wrote: >> >> On Wed, Feb 9, 2011 at 5:26 PM, Glenn Maynard wrote: >> > Another related issue: what happens if a long-running number-cruncher >> > worker >> > keeps a database open while it works,

Re: [IndexedDB] Reason for aborting transactions

On Wed, Feb 9, 2011 at 5:54 PM, Jonas Sicking wrote: > On Wed, Feb 9, 2011 at 5:43 PM, Jeremy Orlow wrote: > > On Wed, Feb 9, 2011 at 5:37 PM, ben turner > wrote: > >> > >> > Normal exceptions have error messages that are not consistient across > >> > implementations and are not localized. Wha

Re: [IndexedDB] Reason for aborting transactions

On Wed, Feb 9, 2011 at 6:39 PM, Glenn Maynard wrote: > On Wed, Feb 9, 2011 at 9:04 PM, ben turner wrote: >> >> > (It's somewhat frustrating when they come back localized, but bearable.) >> >> Sounds like what you really want is more specific error codes, not >> really messages, right? > > Not alw

Re: [IndexedDB] Reason for aborting transactions

On Wed, Feb 9, 2011 at 9:04 PM, ben turner wrote: > > (It's somewhat frustrating when they come back localized, but bearable.) > > Sounds like what you really want is more specific error codes, not > really messages, right? > Not always: - Some errors are implementation-specific. For example,

Re: Mouse Capture for Canvas

>> I hate to ask, since there could be use cases I'm missing, but what is a >> >> use >>case where a browser would need to grab the mouse immediately when the >> >>page >>starts? I'm not against the idea, but it might need a strategy to stop >> >>abuse. >>Here are some steps I see happening.

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Wed, Feb 9, 2011 at 8:39 PM, Jonas Sicking wrote: > On Wed, Feb 9, 2011 at 5:26 PM, Glenn Maynard wrote: > > Another related issue: what happens if a long-running number-cruncher > worker > > keeps a database open while it works, to read data or output results? > > There's no API for sending

Re: [IndexedDB] Reason for aborting transactions

> (It's somewhat frustrating when they come back localized, but bearable.) Sounds like what you really want is more specific error codes, not really messages, right? -Ben

Re: [IndexedDB] Reason for aborting transactions

On Wed, Feb 9, 2011 at 8:37 PM, ben turner wrote: > > Normal exceptions have error messages that are not consistient across > > implementations and are not localized. What's the difference? > > These messages aren't part of any exception though, it's just some > property on a transaction object.

Re: [IndexedDB] Reason for aborting transactions

On Wed, Feb 9, 2011 at 5:43 PM, Jeremy Orlow wrote: > On Wed, Feb 9, 2011 at 5:37 PM, ben turner wrote: >> >> > Normal exceptions have error messages that are not consistient across >> > implementations and are not localized.  What's the difference? >> >> These messages aren't part of any excepti

Re: [IndexedDB] Reason for aborting transactions

On Wed, Feb 9, 2011 at 5:37 PM, ben turner wrote: > > Normal exceptions have error messages that are not consistient across > > implementations and are not localized. What's the difference? > > These messages aren't part of any exception though, it's just some > property on a transaction object.

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Wed, Feb 9, 2011 at 5:26 PM, Glenn Maynard wrote > > > On a related note, please see this statement from section 5.5 of the >> MessagePort spec: >> >> Authors are strongly encouraged to explicitly close >> MessagePort objects >> to disentangle them

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Wed, Feb 9, 2011 at 5:26 PM, Glenn Maynard wrote: > Another related issue: what happens if a long-running number-cruncher worker > keeps a database open while it works, to read data or output results? > There's no API for sending versionchange events for IDBDatabaseSync, and it > doesn't fit in

Re: Quota API to query/request quota for offline storages (e.g. IndexedDB, FileSystem)

2011/2/7 Kinuko Yasuda : > On Sat, Feb 5, 2011 at 7:29 AM, Glenn Maynard wrote: >> On Fri, Feb 4, 2011 at 12:07 AM, Kinuko Yasuda wrote: >>> >>> If we want to make the quota API treat each API differently this would >>> make a lot sense, but I'm not fully convinced by the idea. >>> Putting aside

Re: [IndexedDB] Reason for aborting transactions

> Normal exceptions have error messages that are not consistient across > implementations and are not localized.  What's the difference? These messages aren't part of any exception though, it's just some property on a transaction object. (None of our DOM exceptions, IDB or otherwise, have message

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Wed, Feb 9, 2011 at 5:05 PM, Drew Wilson wrote: > In some cases we leak them, yes (they live for the life of the parent > context) if the developer does not close them. Typically this is only when > you've cloned a MessagePort and sent the other end to a different process. > Trying to figure o

Re: [IndexedDB] Reason for aborting transactions

On Wed, Feb 9, 2011 at 5:17 PM, ben turner wrote: > Hm, Jeremy is right, If you want to look just at the transaction and > see why it aborted you can't rely on errorCode. Ick. > > The only thing I'd change then is the abortMessage property. It's > easier to tell why your transaction aborted with

Re: [IndexedDB] Reason for aborting transactions

Hm, Jeremy is right, If you want to look just at the transaction and see why it aborted you can't rely on errorCode. Ick. The only thing I'd change then is the abortMessage property. It's easier to tell why your transaction aborted with the error code, and I'd hate people doing string comparisons

Re: Mouse Capture for Canvas

(Hello, Brandon) On Wed, Feb 9, 2011 at 7:20 PM, Brandon Andrews < warcraftthre...@sbcglobal.net> wrote: > Regarding forcing a user action before the mouse is captured/grabbed I think it's pivotal. If a page can simply call a method to capture the mouse everytime it's released it because exploitab

Re: [Bug 11948] New: index.openCursor's cursor should have a way to access the index's "value" (in addition to the index's key and objectStore's value)

On Wed, Feb 9, 2011 at 4:00 PM, Jonas Sicking wrote: > On Mon, Feb 7, 2011 at 3:55 PM, Jeremy Orlow wrote: > > On Mon, Feb 7, 2011 at 3:47 PM, Jonas Sicking wrote: > >> > >> On Sat, Feb 5, 2011 at 11:02 AM, Jeremy Orlow > wrote: > >> > On Fri, Feb 4, 2011 at 11:50 PM, Jonas Sicking > wrote: >

Re: [IndexedDB] Reason for aborting transactions

On Wed, Feb 9, 2011 at 4:03 PM, Jeremy Orlow wrote: > On Wed, Feb 9, 2011 at 3:22 PM, Jonas Sicking wrote: >> >> On Tue, Feb 8, 2011 at 10:48 AM, Jeremy Orlow wrote: >> > On Tue, Feb 8, 2011 at 10:38 AM, Jonas Sicking wrote: >> >> >> >> On Tue, Feb 8, 2011 at 9:16 AM, Jeremy Orlow >> >> wrote:

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

Re: [IndexedDB] Reason for aborting transactions

On Wed, Feb 9, 2011 at 3:22 PM, Jonas Sicking wrote: > On Tue, Feb 8, 2011 at 10:48 AM, Jeremy Orlow wrote: > > 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: >

Re: [Bug 11948] New: index.openCursor's cursor should have a way to access the index's "value" (in addition to the index's key and objectStore's value)

On Mon, Feb 7, 2011 at 3:55 PM, Jeremy Orlow wrote: > On Mon, Feb 7, 2011 at 3:47 PM, Jonas Sicking wrote: >> >> On Sat, Feb 5, 2011 at 11:02 AM, Jeremy Orlow wrote: >> > On Fri, Feb 4, 2011 at 11:50 PM, Jonas Sicking wrote: >> >> >> >> On Fri, Feb 4, 2011 at 3:30 PM, Jeremy Orlow >> >> wrote:

Re: [IndexedDB] Reason for aborting transactions

On Tue, Feb 8, 2011 at 10:48 AM, Jeremy Orlow wrote: > 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:

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Wed, Feb 9, 2011 at 2:03 PM, Jonas Sicking wrote: > > For what it's worth, shared workers already expose GC behavior. You'll > get a already-existing shared worker, or a new one will be created, > depending on if GC has collected the worker or not. > Hmmm. That was certainly not the intent wh

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

In some cases we leak them, yes (they live for the life of the parent context) if the developer does not close them. Typically this is only when you've cloned a MessagePort and sent the other end to a different process. Trying to figure out if a port is reachable when the entangled port lives in a

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Wed, Feb 9, 2011 at 11:05 AM, Drew Wilson wrote: > This discussion reminds me of a similar issue with MessagePorts. The > original MessagePort spec exposed GC behavior through the use of onclose > events/closed attributes on MessagePorts. It turns out that on Chromium, > there are situations wh

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Wed, Feb 9, 2011 at 2:05 PM, Drew Wilson wrote: > This discussion reminds me of a similar issue with MessagePorts. The > original MessagePort spec exposed GC behavior through the use of onclose > events/closed attributes on MessagePorts. It turns out that on Chromium, > there are situations wh

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Wed, Feb 9, 2011 at 11:20 AM, Jeremy Orlow wrote: > On Wed, Feb 9, 2011 at 11:05 AM, Drew Wilson wrote: > >> This discussion reminds me of a similar issue with MessagePorts. The >> original MessagePort spec exposed GC behavior through the use of onclose >> events/closed attributes on MessageP

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Wed, Feb 9, 2011 at 11:05 AM, Drew Wilson wrote: > This discussion reminds me of a similar issue with MessagePorts. The > original MessagePort spec exposed GC behavior through the use of onclose > events/closed attributes on MessagePorts. It turns out that on Chromium, > there are situations w

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

This discussion reminds me of a similar issue with MessagePorts. The original MessagePort spec exposed GC behavior through the use of onclose events/closed attributes on MessagePorts. It turns out that on Chromium, there are situations where it's very difficult for us to GC MessagePorts (a port's r

RE: [widget] proposal to add defaultlocale attribute to widget element (P&C Spec), I18N ACTION-18

Dear Marcos, [this is a reply on behalf of the Internationalization Core WG] We agree that not providing a default locale for a Widget is an oversight in the Widget's localization model. The ability to provide multiple languages in the configuration file or in the locales directory structure do