RE: [IndexedDB] Reason for aborting transactions

[Pablo Castro]

(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: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. (None of our DOM exceptions, IDB or
>> >> otherwise, have message properties btw, they're only converted to some
>> >> message if they make it to the error console).
>> >>
>> >> > For stuff like internal errors, they seem especially important.
>> >>
>> >> You're thinking of having multiple messages for the INTERAL_ERROR_ABORT
>> >> code?
>> >
>> > I think that'd be ideal, yes.  Since internal errors will be UA specific,
>> > string matching wouldn't be so bad there.
>> > If no one likes this idea, I'm happy hiding away the message in some
>> > webkitAbortMessage attribute so it's super clear it's just us who 
>> > implements
>> > this.  (Speaking of which, maybe you guys should do that with getAll.)
>> We'll definitely put getAll under a vendor prefix once we drop the
>> "front door" prefix on .indexeddb.
>>
>> I'm with Ben here. I'd prefer to hide the message away under a vendor
>> prefix (either now or once you drop the front door one) for now to
>> gather feedback on how it'll be used.
>>

I'm not sure about this...as I was catching up on the thread I understood this 
more as a debugging helper feature. In the end if we didn't have this you could 
just have a database-wide error handler and stash errors as they come in a 
global array or something, and that's okay for diagnostics. If we want to make 
it easier to just look at the transaction and see what happened, we may as well 
let UAs include a descriptive string so you can really find out on the spot. I 
don't have a strong opinion about excluding (or vendor-prefixing) the property, 
but it seems it would come in handy.

-pablo

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

[bugzilla]

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-apps/current-work/#top
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P3
 Component: Web Messaging (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: contribu...@whatwg.org
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org


Specification: http://dev.w3.org/html5/postmsg/
Section: http://www.whatwg.org/specs/web-apps/current-work/complete.html#top

Comment:
呵呵呵 as these tend to change rapidly and make your
feedback hard

Posted from: 114.80.133.7

-- 
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: Mouse Capture for Canvas

[Brandon Andrews]

> 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 allow the action and 
>> preventing 
>>abuse?
>> Sounds good. This gets rid of the events completely.

> The events should still exist, so you can tell if your request was accepted, 
>and you can tell if the browser has locked or unlocked the mouse for other 
>reasons, such as pressing a hotkey to release the mouse.  There should 
>probably 
>also be a "lockrefused" event, to notify that a lock request was rejected.

Whoops. Forgot to remove that when I was typing my post. I kind of felt like I 
missed something.
The events would be mouselock(event) and mouseunlock(event) now. So both of 
those would have events.
event.successful to see if the mouselock was successful?
The event could be called MouseLockEvent.
Fits with MouseEvent, KeyboardEvent, WheelEvent
(On another note the WheelEvent deltaX and deltaY can be moved to MouseEvent 
since both are the same data type. The wheel and mousemove event would just use 
them differently. Might be a poor design decision that will need to be checked 
out).

Does the mouseunlock require an event? (Could you cancel the event?)

>> Assuming that a person can call the lock function whenever in any mouse or 
>>keyboard event then there is no initial interaction required. Sounds like 
>>what 
>>you want, and it would be very flexible.
> This would still require initial interaction; for example, in the "lobby 
> timer" 
>case, you'd still have to do something--click the screen or press a key--to 
>initiate it.
A query could be implemented ( element.canLockMouse() ) to see if the 
domain/page is allowed to capture the mouse. If not it could call the 
element.lockMouse() to initiate the browser's security feature. A browser that 
doesn't implement any would just return true for allowed. That seems very 
different from what I've seen in any DOM stuff though.

Re: Mouse Capture for Canvas

[Glenn Maynard]

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 asking the user to allow the action and
preventing abuse?
> Sounds good. This gets rid of the events completely.

The events should still exist, so you can tell if your request was accepted,
and you can tell if the browser has locked or unlocked the mouse for other
reasons, such as pressing a hotkey to release the mouse.  There should
probably also be a "lockrefused" event, to notify that a lock request was
rejected.

> Assuming that a person can call the lock function whenever in any mouse or
keyboard event then there is no initial interaction required. Sounds like
what you want, and it would be very flexible.

This would still require initial interaction; for example, in the "lobby
timer" case, you'd still have to do something--click the screen or press a
key--to initiate it.

Methods for relaxing that can be explored later.  For example (as mentioned
just previously) a browser might allow locking the mouse without any
interaction if the page is fullscreened, or if the page is acting as a
standalone application (eg. an "application shortcut" in Chrome or a
Chromium packaged app).

(If this gains any traction, of course--agreeing about something here
doesn't automatically make things get implemented.  :)

--
Glenn Maynard

Re: Mouse Capture for Canvas

[Glenn Maynard]

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 map stops moving; you have to release the button and
>> reposition the cursor.  Mouse grabbing would trivially fix this.
>>
>
> Sure, but this is not a use-case for capturing while the mouse button is
> up.
>

It's a case for grabbing the mouse when windowed where IE's "capture" API
won't work due to the below, though (which was what I figured you were
referring to).



At least in Windows, it's hard to get deltas without grabbing the mouse.  If
>> the mouse cursor is at the right edge of the screen and the user moves the
>> mouse to the right, Windows doesn't report the motion--the clamping happens
>> too early on.  Games work around this by hiding the mouse cursor and
>> constantly warping the hidden cursor to the center of the screen, which is
>> probably what browsers would do too.
>>
>
> Hmm, interesting. That might make things nasty indeed.
>
> 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]
>



-- 
Glenn Maynard

Re: Mouse Capture for Canvas

[Brandon Andrews]

> 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". >> >> So 
>right when you go to that tab even just to glance at it your mouse will >> be 
>grabbed.  > That depends on how it's implemented.  (I'd rather not go into 
>specifically > how I think browsers might do this--those particular details 
>aren't the > point, at least at this stage.)

> Of course, browsers can still choose to only allow initiating a grab on > 
>click, and it can even be codified in the spec if that's what people really > 
>want.  Again, the point is that it's not necessary to do that in a way > 
>that's 
>impossible to change later on.  If grabbing the mouse happens by the > act of 
>receiving a particular event, then it's impossible to ever relax the > 
>restriction without making a whole new API. 
>
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 allow the action and preventing 
abuse?
Sounds good. This gets rid of the events completely.
 >> I want to point out that most FPS games have a menu at the front.  > Try 
 >> not 
to make too many assumptions about UIs.  A couple more examples:  > - Depending 
on clicking on the main menu to grab the mouse is brittle.  It > means you need 
to determine *at the time of the click* whether to grab the > mouse.  For 
example, if you have "start game" and "options" menu items, the > menu item 
itself needs to know to grab the mouse when "start game" is > clicked, but not 
when "options" is clicked.  That's an ugly, limiting > design. > - It breaks 
down in a typical "lobby" UI.  For example, you have a window > where people 
can 
join a game about to start, set options, chat, etc., with a > timer counting 
down for the game to start.  When the timer reaches 0, the > lobby UI goes away 
and the game starts--and everyone's mouse should be > grabbed without needing 
to 
click the window again.

I can agree with that use-case. Sounds like something to allow.

> - VMware grabs keyboard and mouse input to redirect it to the VM.  You can > 
> do 
>this by clicking the window, but you can also do it with a keyboard > shortcut 
>(^G), so you can fully grab input with the keyboard alone.  This > should be 
>allowed from the start: mouse grabbing should be allowed from any > input 
>event 
>(other than mousemove), including keyboard events. 
>
Assuming that a person can call the lock function whenever in any mouse or 
keyboard event then there is no initial interaction required. Sounds like what 
you want, and it would be very flexible.
 > (Please don't nitpick the individual examples; the point is that there are > 
lots of cases where it makes sense to grab the mouse without it being in > 
response to a click.) 

I won't, but these examples will help to refine and point out problems. I think 
we're finding a pretty solid solution.
 >> But yeah the main problem with just grabbing the mouse is that people just 
>> switching through tabs probably don't want their mouse grabbed. That and >> 
what happens when a tab isn't in view when capture is called?  > It fails, as 
if 
the user was prompted for permission and clicked "no". 

That works.

Re: Mouse Capture for Canvas

[Robert O'Callahan]

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 the cursor.  Mouse grabbing would trivially fix this.
>

Sure, but this is not a use-case for capturing while the mouse button is up.

At least in Windows, it's hard to get deltas without grabbing the mouse.  If
> the mouse cursor is at the right edge of the screen and the user moves the
> mouse to the right, Windows doesn't report the motion--the clamping happens
> too early on.  Games work around this by hiding the mouse cursor and
> constantly warping the hidden cursor to the center of the screen, which is
> probably what browsers would do too.
>

Hmm, interesting. That might make things nasty indeed.

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

[Glenn Maynard]

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 window.

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 the cursor.  Mouse grabbing would trivially fix this.

Being fullscreen and grabbing the mouse are orthogonal features, though of
course browsers could use fullscreen as a factor in deciding whether to
honor a request to grab the mouse cursor.  They might be more lenient with
granting the request in fullscreen.

I agree an API to get mouse deltas is needed. I would suggest introducing a
> completely separate API that lets applications monitor mouse deltas while
> their window has focus, one that doesn't interact with normal mouse events
> at all.
>

At least in Windows, it's hard to get deltas without grabbing the mouse.  If
the mouse cursor is at the right edge of the screen and the user moves the
mouse to the right, Windows doesn't report the motion--the clamping happens
too early on.  Games work around this by hiding the mouse cursor and
constantly warping the hidden cursor to the center of the screen, which is
probably what browsers would do too.

-- 
Glenn Maynard

Re: [IndexedDB] Reason for aborting transactions

[Glenn Maynard]

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
> > message.  That's not something that should be specced specifically, but
> it
> > may be very helpful on the developer's side to knowing what went wrong on
> a
> > user's system to be able to follow up the problem.  Similarly, if a
> File-API
> > write fails due to EDQUOT because of the user's hard disk quota (not to
> be
> > confused with the browser's quota), receiving strerror(EDQUOT) as part of
> > the message would be very useful, but shouldn't be laid out as a specific
> > error code in the spec.
>
> Note that in both these cases the browser probably doesn't want to
> forward the message it gets from the OS or from SQLite directly to the
> webpage. Such a message can contain sensitive information such as
> usernames and filenames.
>

Right; it's the implementation's job to pay attention to where its messages
are coming from.  For example, you shouldn't blindly forward an error
message string from a database backend (which may include paths).  However,
returning a stringification of SQLITE_* constants or strerror(errno), seems
perfectly safe and very useful.

 > - Some errors contain other information that may not be
> > implementation-specific, but may not be worth codifying into the spec.
> For
> > example, it's not worth trying to encode an error message for every
> possible
> > Regex parsing failure.  Browsers may also give additional information
> that's
> > not useful to spec; for example, "17" in "open parentheses at pos 17 not
> > closed".  Javascript parsing failures might include the context of a
> > compilation error.
>
> This is more interesting, but I'm not sure that it applies to abort
> codes? The one case I can think of is unhandled errors which result in
> an abort. However in that case we should have already fired
> window.onerror with the information you're talking about.
>

I was looking over the spec on success and error events some more while
considering this, and I'm deeply confused: 3.2.2 describes the success and
error events being fired at the Window ("at each Window object") rather then
at the request, which seems bizarre.  I feel like this is an embarrassing
spec-novice question, but could someone clue me in on what's happening here?

-- 
Glenn Maynard

Re: Mouse Capture for Canvas

[Robert O'Callahan]

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 forward not-very-far,  will be scaled using the GPU for most
users, so this issue should go away. Or, you can put the canvas in the
middle of a blank page and make that fullscreen.

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 agree an API to get mouse deltas is needed. I would suggest introducing a
completely separate API that lets applications monitor mouse deltas while
their window has focus, one that doesn't interact with normal mouse events
at all.

I don't think requiring a user click on a page to trigger capture is good
enough to prevent abuse. It's easy to get users to click on things in the
page.

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

[Glenn Maynard]

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 start".
>
> So right when you go to that tab even just to glance at it your mouse will
be grabbed.

That depends on how it's implemented.  (I'd rather not go into specifically
how I think browsers might do this--those particular details aren't the
point, at least at this stage.)

Of course, browsers can still choose to only allow initiating a grab on
click, and it can even be codified in the spec if that's what people really
want.  Again, the point is that it's not necessary to do that in a way
that's impossible to change later on.  If grabbing the mouse happens by the
act of receiving a particular event, then it's impossible to ever relax the
restriction without making a whole new API.

(I also seriously doubt that any proposal will gain traction that causes
merely listening to an event to have side-effects.  That's not how DOM
events work.)

> I want to point out that most FPS games have a menu at the front.

Try not to make too many assumptions about UIs.  A couple more examples:

- Depending on clicking on the main menu to grab the mouse is brittle.  It
means you need to determine *at the time of the click* whether to grab the
mouse.  For example, if you have "start game" and "options" menu items, the
menu item itself needs to know to grab the mouse when "start game" is
clicked, but not when "options" is clicked.  That's an ugly, limiting
design.
- It breaks down in a typical "lobby" UI.  For example, you have a window
where people can join a game about to start, set options, chat, etc., with a
timer counting down for the game to start.  When the timer reaches 0, the
lobby UI goes away and the game starts--and everyone's mouse should be
grabbed without needing to click the window again.
- VMware grabs keyboard and mouse input to redirect it to the VM.  You can
do this by clicking the window, but you can also do it with a keyboard
shortcut (^G), so you can fully grab input with the keyboard alone.  This
should be allowed from the start: mouse grabbing should be allowed from any
input event (other than mousemove), including keyboard events.

(Please don't nitpick the individual examples; the point is that there are
lots of cases where it makes sense to grab the mouse without it being in
response to a click.)

> But yeah the main problem with just grabbing the mouse is that people just
switching through tabs probably don't want their mouse grabbed. That and
what happens when a tab isn't in view when capture is called?

It fails, as if the user was prompted for permission and clicked "no".

> Since grab has no opposite mousegrab doesn't work. (ungrab isn't an
English word and "let go" sounds wrong).

I don't think "ungrab" is unnatural, but I'm not too concerned with the
naming, aside from avoiding "capture".

--
Glenn Maynard

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

[Jonas Sicking]

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, to read data or output results?
>> > There's no API for sending versionchange events for IDBDatabaseSync, and
>> > it
>> > doesn't fit in any obvious way since it's inherently asynchronous.  I
>> > suppose the developer-side workaround would be to open the same database
>> > asynchronously in the UI thread just to listen for versionchange, and to
>> > terminate the thread when it's received.  Is that generally what's
>> > intended?
>>
>> This is a good point. We should add the ability to dispatch
>> versionchange events on IDBDatabaseSync. There is no reason we
>> couldn't just make it a event target and add a .onversionchange
>> property to it.
>>
>> Just because the object has some (or many, or only) synchronous
>> methods, doesn't mean it can't also dispatch events.
>
> That works provided your worker periocally returns to the caller, to allow
> events to be dispatched; otherwise the event will never be received.  That's
> usually the case--even for number-crunching workers, most use cases look
> like "receive a request, spend a few seconds doing calculations and I/O and
> return the result".
>
> Not all do--some number-crunching cases might take minutes to run.

That's true, but that's not really a problem with the IDBDatabaseSync
API, but rather with worker design. For example a worker could open
use the asynchronous IDBDatabase for a bit and then start doing a lot
of number crunching and synchronous FileReader/XMLHttpRequest
operations. We can asynchronously fire a event at the IDBDatabase
instance in the worker all we want, but as you point out, until the
worker returns to the event loop it won't be able to receive it.

We could add some sort of IDBDatabaseSync.versionChangePending
property which would allow a long-running script to check for pending
version changes and if so close the database. However it takes a fair
amount of work to use. With an event based interface all you need to
do is add a event handler once and then not worry any more about it.
With a .versionChangePending property, you have to add code to check
the property to every single inner loop where you can spend
significant amounts of time. This will quickly get out of hand as we
start adding more APIs like this which people will have to tend to in
their inner loops.

An alternative solution would be to add a
IDBDatabaseSync.onversionchange property along with an event. Then
asynchronously dispatch the event as with the asynchronous interface.
However if the event goes undispatched for X seconds, forcefully close
the IDBDatabaseSync instance. Note this means that as long as you
return to the event loop, even if you don't handle the event, the
IDBDatabaseSync won't be closed.

I'm not a huge fan of that solution though.

> The
> typical example is expensive renderers, such as a raytracer that may take a
> couple minutes to render a scene.  These sorts of tasks wouldn't want to
> return to the caller--being able to write these algorithms linearly rather
> than in an incremental, setTimeout-based fashion is a basic use case of
> workers.  That said, these are uncommon enough that it's the "asynchronous
> watcher in a separate thread" workaround seems acceptable.

Could be. And since we have worker.terminate() it is possible to
quickly terminate a worker which is using a database.

/ Jonas

Re: [IndexedDB] Reason for aborting transactions

[Jeremy Orlow]

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.  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 properties btw, they're only converted to some
> >> message if they make it to the error console).
> >>
> >> > For stuff like internal errors, they seem especially important.
> >>
> >> You're thinking of having multiple messages for the INTERAL_ERROR_ABORT
> >> code?
> >
> > I think that'd be ideal, yes.  Since internal errors will be UA specific,
> > string matching wouldn't be so bad there.
> > If no one likes this idea, I'm happy hiding away the message in some
> > webkitAbortMessage attribute so it's super clear it's just us who
> implements
> > this.  (Speaking of which, maybe you guys should do that with getAll.)
>
> We'll definitely put getAll under a vendor prefix once we drop the
> "front door" prefix on .indexeddb.
>
> I'm with Ben here. I'd prefer to hide the message away under a vendor
> prefix (either now or once you drop the front door one) for now to
> gather feedback on how it'll be used.
>

It's common for people to do something like this:
indexeddb = indexeddb || moz_indexedDB || mozIndexedDB || webkitIndexedDB;
and then pretty much ignore which vendor's implementation they're using from
then on whenever possible, so I think it's worth doing a prefix on every
level of vendor specific stuff.  So we'll definitely use a prefix for the
abort message.  And I'd encourage you to do the same with getAll if you can
before FF4 ships.

J

Re: [IndexedDB] Reason for aborting transactions

[Jonas Sicking]

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 always:
>
> - 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
> message.  That's not something that should be specced specifically, but it
> may be very helpful on the developer's side to knowing what went wrong on a
> user's system to be able to follow up the problem.  Similarly, if a File-API
> write fails due to EDQUOT because of the user's hard disk quota (not to be
> confused with the browser's quota), receiving strerror(EDQUOT) as part of
> the message would be very useful, but shouldn't be laid out as a specific
> error code in the spec.

Note that in both these cases the browser probably doesn't want to
forward the message it gets from the OS or from SQLite directly to the
webpage. Such a message can contain sensitive information such as
usernames and filenames.

> - Some errors contain other information that may not be
> implementation-specific, but may not be worth codifying into the spec.  For
> example, it's not worth trying to encode an error message for every possible
> Regex parsing failure.  Browsers may also give additional information that's
> not useful to spec; for example, "17" in "open parentheses at pos 17 not
> closed".  Javascript parsing failures might include the context of a
> compilation error.

This is more interesting, but I'm not sure that it applies to abort
codes? The one case I can think of is unhandled errors which result in
an abort. However in that case we should have already fired
window.onerror with the information you're talking about.

/ Jonas

Re: [IndexedDB] Reason for aborting transactions

[Glenn Maynard]

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, 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
message.  That's not something that should be specced specifically, but it
may be very helpful on the developer's side to knowing what went wrong on a
user's system to be able to follow up the problem.  Similarly, if a File-API
write fails due to EDQUOT because of the user's hard disk quota (not to be
confused with the browser's quota), receiving strerror(EDQUOT) as part of
the message would be very useful, but shouldn't be laid out as a specific
error code in the spec.
- Some errors contain other information that may not be
implementation-specific, but may not be worth codifying into the spec.  For
example, it's not worth trying to encode an error message for every possible
Regex parsing failure.  Browsers may also give additional information that's
not useful to spec; for example, "17" in "open parentheses at pos 17 not
closed".  Javascript parsing failures might include the context of a
compilation error.

Error codes are useful when there are meaningful ways for a script to
respond to a particular type of failure, but there's not much you can do in
response to EDQUOT beyond displaying and/or reporting the error--the same is
probably true for most implementation-specific database "internal errors"
and so on.

-- 
Glenn Maynard

Re: Mouse Capture for Canvas

[Brandon Andrews]

>> 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. > > 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".

So right when you go to that tab even just to glance at it your mouse will be 
grabbed.
I want to point out that most FPS games have a menu at the front. But yeah the 
main problem with just grabbing the mouse is that people just switching through 
tabs probably don't want their mouse grabbed. That and what happens when a tab 
isn't in view when capture is called?

>> Also what are your guy's name ideas? I think I prefer mousecapture and >> 
>>mouserelease and just push aside the IE API. > > "Mouse capture" isn't just 
>>an 
>>IE API.  There's also a similar Win32 API with > the same name, with the same 
>>use case as IE's API: to continue receiving > mouse motion when dragging.  
>>I'm 
>>sure there are other windowing systems with > it, too. > > I'd suggest 
>>"mousegrab".

Since grab has no opposite mousegrab doesn't work. (ungrab isn't an English 
word 
and "let go" sounds wrong).

After discussing this in the IRC channel for whatwg it seems like mouselock and 
mouseunlock are recommended. They describe the operation pretty well that the 
mouse is locked to an element.
Anyone have disagreements or other ideas?

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

[Glenn Maynard]

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 versionchange events for IDBDatabaseSync, and
> it
> > doesn't fit in any obvious way since it's inherently asynchronous.  I
> > suppose the developer-side workaround would be to open the same database
> > asynchronously in the UI thread just to listen for versionchange, and to
> > terminate the thread when it's received.  Is that generally what's
> intended?
>
> This is a good point. We should add the ability to dispatch
> versionchange events on IDBDatabaseSync. There is no reason we
> couldn't just make it a event target and add a .onversionchange
> property to it.
>
> Just because the object has some (or many, or only) synchronous
> methods, doesn't mean it can't also dispatch events.
>

That works provided your worker periocally returns to the caller, to allow
events to be dispatched; otherwise the event will never be received.  That's
usually the case--even for number-crunching workers, most use cases look
like "receive a request, spend a few seconds doing calculations and I/O and
return the result".

Not all do--some number-crunching cases might take minutes to run.  The
typical example is expensive renderers, such as a raytracer that may take a
couple minutes to render a scene.  These sorts of tasks wouldn't want to
return to the caller--being able to write these algorithms linearly rather
than in an incremental, setTimeout-based fashion is a basic use case of
workers.  That said, these are uncommon enough that it's the "asynchronous
watcher in a separate thread" workaround seems acceptable.

(That's also another case where the API discussed in the "synchronously
handling events" thread would become useful: you could send a message to the
thread while it's running, without needing to terminate it outright.)

-- 
Glenn Maynard

Re: [IndexedDB] Reason for aborting transactions

[ben turner]

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

[Glenn Maynard]

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. (None of our DOM exceptions, IDB or
> otherwise, have message properties btw, they're only converted to some
> message if they make it to the error console).
>

FWIW, I think that any scripting error message useful to display on the
console is useful to make accessible from scripts, provided they don't
contain sensitive information, like database paths.  I often attach a global
error handler to window.onerror and send script errors to the server
automatically, which is indispensable for quickly discovering lurking bugs
on user systems.  This is particularly important if there's more specific
information in the message than the exception itself, which seems likely
with error codes like "internal error".

(It's somewhat frustrating when they come back localized, but bearable.)

-- 
Glenn Maynard

Re: [IndexedDB] Reason for aborting transactions

[Jonas Sicking]

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 exception though, it's just some
>> property on a transaction object. (None of our DOM exceptions, IDB or
>> otherwise, have message properties btw, they're only converted to some
>> message if they make it to the error console).
>>
>> > For stuff like internal errors, they seem especially important.
>>
>> You're thinking of having multiple messages for the INTERAL_ERROR_ABORT
>> code?
>
> I think that'd be ideal, yes.  Since internal errors will be UA specific,
> string matching wouldn't be so bad there.
> If no one likes this idea, I'm happy hiding away the message in some
> webkitAbortMessage attribute so it's super clear it's just us who implements
> this.  (Speaking of which, maybe you guys should do that with getAll.)

We'll definitely put getAll under a vendor prefix once we drop the
"front door" prefix on .indexeddb.

I'm with Ben here. I'd prefer to hide the message away under a vendor
prefix (either now or once you drop the front door one) for now to
gather feedback on how it'll be used.

/ Jonas

Re: [IndexedDB] Reason for aborting transactions

[Jeremy Orlow]

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. (None of our DOM exceptions, IDB or
> otherwise, have message properties btw, they're only converted to some
> message if they make it to the error console).
>
> > For stuff like internal errors, they seem especially important.
>
> You're thinking of having multiple messages for the INTERAL_ERROR_ABORT
> code?
>

I think that'd be ideal, yes.  Since internal errors will be UA specific,
string matching wouldn't be so bad there.

If no one likes this idea, I'm happy hiding away the message in some
webkitAbortMessage attribute so it's super clear it's just us who implements
this.  (Speaking of which, maybe you guys should do that with getAll.)

J

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

[Drew Wilson]

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, so that their resources can be recollected. Creating
>> many MessagePort  objects
>> and discarding them without closing them can lead to high memory usage.
>>
>
> For explicitly-created MessagePorts this is natural enough.  It's slightly
> less obvious for MessagePorts created implicitly by Worker/SharedWorker
> objects, though; I'd predict that becoming a common cause of leaks on pages
> that create and destroy a lot of threads.
>

It's not an issue, because when a Worker shuts down it implicitly closes all
of its MessagePorts, which would allow the renderer side to be GC'd - the
leak only happens when you release a reference to a MessagePort without
closing it. If you're creating lots of worker threads and leaving them
running, then you've got bigger memory issues than a few hundred bytes of
MessagePorts.

But, yeah, back to IDB now :)

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

[Jonas Sicking]

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 any obvious way since it's inherently asynchronous.  I
> suppose the developer-side workaround would be to open the same database
> asynchronously in the UI thread just to listen for versionchange, and to
> terminate the thread when it's received.  Is that generally what's intended?

This is a good point. We should add the ability to dispatch
versionchange events on IDBDatabaseSync. There is no reason we
couldn't just make it a event target and add a .onversionchange
property to it.

Just because the object has some (or many, or only) synchronous
methods, doesn't mean it can't also dispatch events.

/ Jonas

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

[Eric Uhrhane]

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 the localStorage for now, do you still see significant
>>> issues in having a sshared single quota?  Also let me note that
>>> this API does not and should not guarantee that the app can actually
>>> *write* that amount of data into the storage, even after the quota is
>>> granted, and the UA could still stop an API to write further even if
>>> it's within the quota.
>>
>> I suppose that even the 2-3x difference--requesting 256 MB and actually
>> getting 512 MB over different APIs--is acceptable, since to users,
>> requesting storage is an order-of-magnitude question more than a precise
>> number.  As long as implementations are still allowed to implement separate
>> quotas if they want, it's probably acceptable for this API to not reflect
>> them precisely and to be biased towards a shared quota.
>
> If we think that most of users/developers wouldn't be interested in
> specifying 'giving X bytes to storage A' and 'giving Y bytes to
> storage B' or such that while both storage A and B eats the user's
> disk, then probably UA should evolve in that direction.  That's my
> assumption and why the proposed API look like that (i.e. biased
> towards a shared quota).

Agreed.  Users won't care about the distinction, so let's make it so
developers don't have to care.

>> 2011/2/4 Ian Fette (イアンフェッティ) 
>>> For instance, if a user has been using a site for months, uses it
>>> frequently, and the site hits its 5GB limit but there's still 300GB free on
>>> the drive, perhaps we just give the site another 5GB and give the user a
>>> passive indication that we've done so, and let them do something if they
>>> actually care.
>>
>> That's interesting; reducing the amount users are nagged about things that
>> they probably don't care about is important.  It would also need to suppress
>> prompting from calls to requestQuota if the quota increase would have been
>> allowed automatically.
>
> The proposing API itself doesn't specify the frequency of
> notifications or the behavior of out-of-quota scenarios, but probably
> it might be worth adding some note about calling 'requestQuota()' does
> not (and should not) always need to result in the UA prompting, and it
> must be generally prohibited prompting the user too frequently.

Possibly in non-normative text, but I think it's implied if you just
leave it out that implementers can do whatever they want with the UI.

> The bottom line of whether we should prompt or not is, I suppose, if
> UA ask for the user's permission to store some data in the storage,
> the UA shouldn't delete the data without the user's permission.

Yup.

Re: [IndexedDB] Reason for aborting transactions

[ben turner]

> 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 properties btw, they're only converted to some
message if they make it to the error console).

> For stuff like internal errors, they seem especially important.

You're thinking of having multiple messages for the INTERAL_ERROR_ABORT code?

-Ben

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

[Glenn Maynard]

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 out if a port is reachable when the entangled port lives in
> a different process (and whose reachability may itself depend on the
> reachability of a third port in yet another process ad infinitum) is a
> fairly intractable problem.


OK.  At least the heap snapshotting in Chrome is good enough to make
debugging this reasonably easy, if it results in nontrivial leaks.


>  This does not happen with the implicit ports associated with dedicated
> workers, because in WebKit those aren't actually MessagePorts (mainly
> because the webkit implementation of dedicated workers predates message
> ports). Chromium SharedWorkers use real MessagePorts though, so if you do
> this:
>
> var w = new SharedWorker("foo.html");
> w.port.onmessage = function() {...};
>
> that port will not be GC'd in chromium, even if the SharedWorker drops its
> end of the port on the floor, until either the SharedWorker calls close() on
> the port, the worker exits or your parent document is collected.
>

That's natural, of course--the event handler holds a reference to the
object.

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, so that their resources can be recollected. Creating
> many MessagePort  objects
> and discarding them without closing them can lead to high memory usage.
>

For explicitly-created MessagePorts this is natural enough.  It's slightly
less obvious for MessagePorts created implicitly by Worker/SharedWorker
objects, though; I'd predict that becoming a common cause of leaks on pages
that create and destroy a lot of threads.


Back on IDB: If one page has an opened database (whether from not being
closed, a GC issue, or a simpler site issue), and a new tab is failing to
setVersion as a result, figuring out the cause may be painful.  Hopefully
browsers will at least be able to tell which other tab is holding the
database open, and retrieve a stack trace of where it was opened, even if
it's in a closed tab.  If that information is available, it would be useful
to include it in the "blocked" event, as an optional, informative message
that scripts can send to their server-side error logging if it blocks for
too long.

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 any obvious way since it's inherently asynchronous.  I
suppose the developer-side workaround would be to open the same database
asynchronously in the UI thread just to listen for versionchange, and to
terminate the thread when it's received.  Is that generally what's intended?

-- 
Glenn Maynard

Re: [IndexedDB] Reason for aborting transactions

[Jeremy Orlow]

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 the error code, and
> I'd hate people doing string comparisons instead of checking the error
> code. And what about localization?
>

Normal exceptions have error messages that are not consistient across
implementations and are not localized.  What's the difference?

For stuff like internal errors, they seem especially important.

J

Re: [IndexedDB] Reason for aborting transactions

[ben turner]

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 instead of checking the error
code. And what about localization?

-Ben

Re: Mouse Capture for Canvas

[Glenn Maynard]

(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 exploitable. If a person accidently
allows a page to capture their mouse they can just press the release key.

It's only exploitable if there are no other mechanisms to prevent abuse.
Requiring a click isn't the only conceivable way of doing that.

Also, "trusted" applications may want to relax restrictions like this, to
allow web apps to behave more like native applications.

Even if implementations will usually require a click, there's no need to
bolt that into the API and make it impossible to change later on.

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

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".

> Also what are your guy's name ideas? I think I prefer mousecapture and
mouserelease and just push aside the IE API.

"Mouse capture" isn't just an IE API.  There's also a similar Win32 API with
the same name, with the same use case as IE's API: to continue receiving
mouse motion when dragging.  I'm sure there are other windowing systems with
it, too.

I'd suggest "mousegrab".

--
Glenn Maynard

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)

[Jeremy Orlow]

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:
> >> >>
> >> >> On Fri, Feb 4, 2011 at 3:30 PM, Jeremy Orlow 
> >> >> wrote:
> >> >> > We haven't used the term primary key too much in the spec, but I
> >> >> > think a
> >> >> > lot
> >> >> > might actually be more clear if we used it more.  And I think it'd
> >> >> > also
> >> >> > make
> >> >> > a good name here.  So I'm OK with that being the name we choose.
> >> >> > Here's another question: what do we set primaryKey to for cursors
> >> >> > opened
> >> >> > via
> >> >> > index.openKeyCursor and objectStore.openCursor?  It seems as though
> >> >> > setting
> >> >> > them to null/undefined could be confusing.  One possibility is to
> >> >> > have
> >> >> > .value and .primaryKey be the same thing for the former and .key
> and
> >> >> > .primaryKey be the same for the latter, but that too could be
> >> >> > confusing.
> >> >> >  (I
> >> >> > think we have this problem no matter what we name it, but if there
> >> >> > were
> >> >> > some
> >> >> > name that was more clear in these contexts, then that'd be a good
> >> >> > reason
> >> >> > to
> >> >> > consider it instead.)
> >> >> > J
> >> >> >
> >> >> > For objectStore.openCursor, if we went with primaryKey, then would
> we
> >> >> > set
> >> >> > both key and primaryKey to be the same thing?  Leaving it
> >> >> > undefined/null
> >> >> > seems odd.
> >> >>
> >> >> I've been pondering the same questions but so far no answer seems
> >> >> obviously best.
> >> >>
> >> >> One way to think about it is that it's good if you can use the same
> >> >> code to iterate over an index cursor as a objectStore cursor. For
> >> >> example to display a list of results in a table. This would indicate
> >> >> that for objectStore cursors .key and .primaryKey should have the
> same
> >> >> value. This sort of makes sense too since it means that a objectStore
> >> >> cursor is just a special case of an index cursor where the iterated
> >> >> index just happens to be the primary index.
> >> >>
> >> >> This would leave the index key-cursor. Here it would actually make
> >> >> sense to me to let .key be the index key, .primaryKey be the key in
> >> >> the objectStore, and .value be empty. This means that index cursors
> >> >> and index key-cursors work the same, with just .value being empty for
> >> >> the latter.
> >> >>
> >> >> So in summary
> >> >>
> >> >> objectStore.openCursor:
> >> >> .key = entry key
> >> >> .primaryKey = entry key
> >> >> .value = entry value
> >> >>
> >> >> index.openCursor:
> >> >> .key = index key
> >> >> .primaryKey = entry key
> >> >> .value = entry value
> >> >>
> >> >> index.openKeyCursor:
> >> >> .key = index key
> >> >> .primaryKey = entry key
> >> >> .value = undefined
> >> >>
> >> >>
> >> >> There are two bad things with this:
> >> >> 1. for an objectStore cursor .key and .primaryKey are the same. This
> >> >> does seem unneccesary, but I doubt it'll be a source of bugs or
> >> >> require people to write more code. I'm less worried about confusion
> >> >> since both properties are in fact keys.
> >> >
> >> > As long as we're breaking backwards compatibility in the name of
> >> > clarity, we
> >> > might as well change key to indexKey and keep it null undefined for
> >> > objectStore.openCursor I think.  This would eliminate the confusion.
> >> > If we do break compat, is it possible for FF4 to include these
> changes?
> >> >  If
> >> > not, then I would actually lean towards leaving .key and .value as is
> >> > and
> >> > having .primaryKey duplicate info for index.openKeyCursor and
> >> > objectStore.openCursor.
> >>
> >> Actually, I quite like the idea of having objectStore-cursors just be
> >> a special case of index-cursors. Which also allows us to keep the nice
> >> and short name "key" of being the key that you are iterating (be that
> >> a primary key or an index key).
> >
> > Can you explain further?  I don't fully understand you.
>
> My thinking was that iterating over an objectStore and iterating over
> an index should essentially expose the same API. So iterating over the
> objectStore is basically just iterating over the index that happens to
> be the primary key.
>
> In this light, the following API makes a lot of sense:
>
> objectStore.openCursor:
> .key = entry key
> .primaryKey = entry key
> .value = entry value
>
> index.openCursor:
> .key = index key
> .primaryKey = entry key
> .value = entry value
>
> In other words, you access .key if you want to get the value of the
> property you are currently iterating using, and you access .primaryKey
> if you need to get a reference which uniquely identifies the entry
> (for example for use as unique identifier in a join, or for outputting
> links to entries).
>
> It seems like we agree th

Re: [IndexedDB] Reason for aborting transactions

[Jonas Sicking]

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:
>> >> > 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 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  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.
>> >
>> > I think that's what Ben was suggesting.  I was suggesting that it seemed
>> > kind of odd though, and I'd prefer the following:
>> > Add the following to IDBTransaction:
>> >   readonly attribute EXPLICIT_ABORT = 1
>> >   r

Re: Mouse Capture for Canvas

[Brandon Andrews]

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

> In this case, I'm mostly referring to sites where you've previously clicked
> "always allow this site to do this"--probably the usual case.  Legitimate
> sites aren't going to deliberately hijack the mouse cursor, but it might
> happen due to a bug, and I must always be able to escape without having to
> close the whole browser window.

When I wrote this up I was thinking of the easiest way to handle this without 
allowing a webpage to take a mouse over and over. To make things more flexible 
it could be simply on mouse down instead of click. Mouse down would allow a 
person to click and continue moving the mouse inside of the region without 
releasing.

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 exploitable. If a person accidently allows a page to 
capture their mouse they can just press the release key.

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

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.

1) User directs their user-agent to a new page.
2) Javascript calls mousecapture
3) user-agent displays a yellow bar at the top informing the user that the page 
is requesting to capture the mouse
4) User selects allow
5) User presses escape
6) In the mouserelease callback there's a mousecapture call
7) User is confused why mouse didn't release and kills 6 people.

So we have to stop that (the mouse release and immediate capture). My proposal 
is if the user presses the release key twice in a row the yellow allow/deny bar 
is reset. But that assumes every human reacts the same way to mouse that is 
locked and keeps hitting the escape key. You'll need to find a solution because 
I can't think of one that works.

Also what are your guy's name ideas? I think I prefer mousecapture and 
mouserelease and just push aside the IE API.

Re: [IndexedDB] Reason for aborting transactions

[Jeremy Orlow]

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:
> >> >>
> >> >> 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 <
> 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  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.
> >
> > I think that's what Ben was suggesting.  I was suggesting that it seemed
> > kind of odd though, and I'd prefer the following:
> > Add the following to IDBTransaction:
> >   readonly attribute EXPLICIT_ABORT = 1
> >   readonly attribute INTERNAL_ERROR_ABORT = 2
> >   readonly attribute QUOTA_ERROR_ABORT=3
> >   ... etc
> >   readonly attribute abortMessage;
> >   readonly attribute abortCode;
> > And just set the message/code right before firing an abort event.
>
> Yeah, I think Jeremy is right. If we ar

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)

[Jonas Sicking]

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:
>> >> > We haven't used the term primary key too much in the spec, but I
>> >> > think a
>> >> > lot
>> >> > might actually be more clear if we used it more.  And I think it'd
>> >> > also
>> >> > make
>> >> > a good name here.  So I'm OK with that being the name we choose.
>> >> > Here's another question: what do we set primaryKey to for cursors
>> >> > opened
>> >> > via
>> >> > index.openKeyCursor and objectStore.openCursor?  It seems as though
>> >> > setting
>> >> > them to null/undefined could be confusing.  One possibility is to
>> >> > have
>> >> > .value and .primaryKey be the same thing for the former and .key and
>> >> > .primaryKey be the same for the latter, but that too could be
>> >> > confusing.
>> >> >  (I
>> >> > think we have this problem no matter what we name it, but if there
>> >> > were
>> >> > some
>> >> > name that was more clear in these contexts, then that'd be a good
>> >> > reason
>> >> > to
>> >> > consider it instead.)
>> >> > J
>> >> >
>> >> > For objectStore.openCursor, if we went with primaryKey, then would we
>> >> > set
>> >> > both key and primaryKey to be the same thing?  Leaving it
>> >> > undefined/null
>> >> > seems odd.
>> >>
>> >> I've been pondering the same questions but so far no answer seems
>> >> obviously best.
>> >>
>> >> One way to think about it is that it's good if you can use the same
>> >> code to iterate over an index cursor as a objectStore cursor. For
>> >> example to display a list of results in a table. This would indicate
>> >> that for objectStore cursors .key and .primaryKey should have the same
>> >> value. This sort of makes sense too since it means that a objectStore
>> >> cursor is just a special case of an index cursor where the iterated
>> >> index just happens to be the primary index.
>> >>
>> >> This would leave the index key-cursor. Here it would actually make
>> >> sense to me to let .key be the index key, .primaryKey be the key in
>> >> the objectStore, and .value be empty. This means that index cursors
>> >> and index key-cursors work the same, with just .value being empty for
>> >> the latter.
>> >>
>> >> So in summary
>> >>
>> >> objectStore.openCursor:
>> >> .key = entry key
>> >> .primaryKey = entry key
>> >> .value = entry value
>> >>
>> >> index.openCursor:
>> >> .key = index key
>> >> .primaryKey = entry key
>> >> .value = entry value
>> >>
>> >> index.openKeyCursor:
>> >> .key = index key
>> >> .primaryKey = entry key
>> >> .value = undefined
>> >>
>> >>
>> >> There are two bad things with this:
>> >> 1. for an objectStore cursor .key and .primaryKey are the same. This
>> >> does seem unneccesary, but I doubt it'll be a source of bugs or
>> >> require people to write more code. I'm less worried about confusion
>> >> since both properties are in fact keys.
>> >
>> > As long as we're breaking backwards compatibility in the name of
>> > clarity, we
>> > might as well change key to indexKey and keep it null undefined for
>> > objectStore.openCursor I think.  This would eliminate the confusion.
>> > If we do break compat, is it possible for FF4 to include these changes?
>> >  If
>> > not, then I would actually lean towards leaving .key and .value as is
>> > and
>> > having .primaryKey duplicate info for index.openKeyCursor and
>> > objectStore.openCursor.
>>
>> Actually, I quite like the idea of having objectStore-cursors just be
>> a special case of index-cursors. Which also allows us to keep the nice
>> and short name "key" of being the key that you are iterating (be that
>> a primary key or an index key).
>
> Can you explain further?  I don't fully understand you.

My thinking was that iterating over an objectStore and iterating over
an index should essentially expose the same API. So iterating over the
objectStore is basically just iterating over the index that happens to
be the primary key.

In this light, the following API makes a lot of sense:

objectStore.openCursor:
.key = entry key
.primaryKey = entry key
.value = entry value

index.openCursor:
.key = index key
.primaryKey = entry key
.value = entry value

In other words, you access .key if you want to get the value of the
property you are currently iterating using, and you access .primaryKey
if you need to get a reference which uniquely identifies the entry
(for example for use as unique identifier in a join, or for outputting
links to entries).

It seems like we agree that a index-key-cursor should have the same
API as normal index-cursors, with just .value missing.

/ Jonas

Re: [IndexedDB] Reason for aborting transactions

[Jonas Sicking]

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:
>> >> > 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 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  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.
>
> I think that's what Ben was suggesting.  I was suggesting that it seemed
> kind of odd though, and I'd prefer the following:
> Add the following to IDBTransaction:
>   readonly attribute EXPLICIT_ABORT = 1
>   readonly attribute INTERNAL_ERROR_ABORT = 2
>   readonly attribute QUOTA_ERROR_ABORT=3
>   ... etc
>   readonly attribute abortMessage;
>   readonly attribute abortCode;
> And just set the message/code right before firing an abort event.

Yeah, I think Jeremy is right. If we are going to expose the abort
reason then this is way to do it.

However, the above is somewhat ugly. Do we really need this feature?
The only thing it seems like you can really make use of is the "quota
abort" reason. When that happens you can show to the user a message
like "Unable to synchronize emails since you didn't give me enough
quo

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

[Drew Wilson]

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 when I was discussing the WebKit
implementation with Hixie, but either there was a miscommunication or the
definition of when a document becomes "discarded" has changed since then. In
the WebKit implementation, SharedWorker lifecycle is not tied to GC, but is
instead tied to specific deterministic navigation/close actions on the
parent document.

Dependence of SharedWorkers on GC is bad for all the same reasons I outlined
above - I'll follow up in a separate thread whether that is indeed the
intent of the spec.


> Not saying that this is great, just pointing out that this is the case.
>
> / Jonas
>

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

[Drew Wilson]

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 different process (and whose reachability may itself depend on the
reachability of a third port in yet another process ad infinitum) is a
fairly intractable problem.

This does not happen with the implicit ports associated with dedicated
workers, because in WebKit those aren't actually MessagePorts (mainly
because the webkit implementation of dedicated workers predates message
ports). Chromium SharedWorkers use real MessagePorts though, so if you do
this:

var w = new SharedWorker("foo.html");
w.port.onmessage = function() {...};

that port will not be GC'd in chromium, even if the SharedWorker drops its
end of the port on the floor, until either the SharedWorker calls close() on
the port, the worker exits or your parent document is collected.

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, so that their resources can be recollected. Creating
many MessagePort  objects and
discarding them without closing them can lead to high memory usage.

-atw

On Wed, Feb 9, 2011 at 12:56 PM, Glenn Maynard  wrote:

> 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 where it's very difficult for us to GC MessagePorts (a
>> port's reachability depends on the reachability of the entangled port on an
>> entirely separate process), and so we just don't.
>
>
> Err, so you just leak MessagePorts?  Or just in those situations, whatever
> they are?  Does this happen even for the implicit MessagePort associated
> with each worker?
>
> --
> Glenn Maynard
>

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

[Jonas Sicking]

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 where it's very difficult for us to GC MessagePorts (a
> port's reachability depends on the reachability of the entangled port on an
> entirely separate process), and so we just don't.
> My concern is that there may be situations like this with IDB - if at some
> point it's possible for events to be fired on an IDB instance (if we support
> triggers), you'll have a situation where the reachability of an IDB instance
> may depend on the reachability of that same DB in other processes. The net
> effect is that on multi-process/multi-heap platforms, we may not be able to
> GC databases, while on other platforms (which have a unified heap) we will
> be able to GC them. This will end up being a source of cross-browser
> incompatibility, because code will work just fine on platforms that are able
> to deterministically GC databases, but then will break on other platforms
> that cannot.
> (As an aside, Jeremy mentions that there may already be situations where we
> cannot GC databases today - I don't know the spec well enough to comment,
> though, so perhaps he can elaborate).

I definitely agree that if there could be events fired at the
IDBDatabase instance, and there are event listeners attached to it,
then you shouldn't GC the instance. This is similar to how you
shouldn't GC  elements which are still loading images and have an
onload handler attached.

That seems no different from script holding a strong reference to the
instance though, so it's a situation the implementation has to deal
with anyway (by firing a "blocked" event at the setVersion request and
waiting for the user to close the tab).

> In any case, I don't think that IDB should be the first place in the entire
> web platform where we expose GC behavior to clients.

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.

Not saying that this is great, just pointing out that this is the case.

/ Jonas

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

[Glenn Maynard]

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 where it's very difficult for us to GC MessagePorts (a
> port's reachability depends on the reachability of the entangled port on an
> entirely separate process), and so we just don't.


Err, so you just leak MessagePorts?  Or just in those situations, whatever
they are?  Does this happen even for the implicit MessagePort associated
with each worker?

-- 
Glenn Maynard

Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

[Drew Wilson]

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 MessagePorts. It turns out that on Chromium,
>> there are situations where it's very difficult for us to GC MessagePorts (a
>> port's reachability depends on the reachability of the entangled port on an
>> entirely separate process), and so we just don't.
>>
>> My concern is that there may be situations like this with IDB - if at some
>> point it's possible for events to be fired on an IDB instance (if we support
>> triggers), you'll have a situation where the reachability of an IDB instance
>> may depend on the reachability of that same DB in other processes. The net
>> effect is that on multi-process/multi-heap platforms, we may not be able to
>> GC databases, while on other platforms (which have a unified heap) we will
>> be able to GC them. This will end up being a source of cross-browser
>> incompatibility, because code will work just fine on platforms that are able
>> to deterministically GC databases, but then will break on other platforms
>> that cannot.
>>
>> (As an aside, Jeremy mentions that there may already be situations where
>> we cannot GC databases today - I don't know the spec well enough to comment,
>> though, so perhaps he can elaborate).
>>
>
> Yeah.  Talking to Drew made me realize that we (WebKit) already have a
> cycle so that we probably can't collect IDBDatabase objects with event
> listeners attached to it.  When there's a listener, we have to hold a
> reference to the JavaScript wrapper since it's what holds onto the
> JavaScript function we call.  But the wrapper holds a reference to our
> WebCore object.  We can break the cycle only when we know that we're not
> going to call any more events on it.  We know that when .close() is called.
>
> Working around this as is will be tricky, but isn't really a spec problem.
>  But it does mean that the developer will need to always call .close() or
> ask the user to close the tab in order to ever be able to run a setVersion
> transaction.  At least for the time being in any WebKit browser.
>

This mainly becomes an issue if some browsers are able to GC when others are
not - if that happens, then you end up with incompatible behavior because
setVersion() calls that work on one browser won't work on others. So if
setVersion() is going to expose GC behavior, then I think you have to codify
in the spec the Least Common Denominator GC behavior (for example,
spec-compliant implementations *must not* GC databases with event handlers
registered). This is a rabbit hole I don't think we want to go down.


>
>
>> In any case, I don't think that IDB should be the first place in the
>> entire web platform where we expose GC behavior to clients.
>>
>> -atw
>>
>> On Tue, Feb 8, 2011 at 4:43 PM, Jonas Sicking  wrote:
>>
>>> 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.
>>> >
>>> > 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: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

[Jeremy Orlow]

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 where it's very difficult for us to GC MessagePorts (a
> port's reachability depends on the reachability of the entangled port on an
> entirely separate process), and so we just don't.
>
> My concern is that there may be situations like this with IDB - if at some
> point it's possible for events to be fired on an IDB instance (if we support
> triggers), you'll have a situation where the reachability of an IDB instance
> may depend on the reachability of that same DB in other processes. The net
> effect is that on multi-process/multi-heap platforms, we may not be able to
> GC databases, while on other platforms (which have a unified heap) we will
> be able to GC them. This will end up being a source of cross-browser
> incompatibility, because code will work just fine on platforms that are able
> to deterministically GC databases, but then will break on other platforms
> that cannot.
>
> (As an aside, Jeremy mentions that there may already be situations where we
> cannot GC databases today - I don't know the spec well enough to comment,
> though, so perhaps he can elaborate).
>

Yeah.  Talking to Drew made me realize that we (WebKit) already have a cycle
so that we probably can't collect IDBDatabase objects with event listeners
attached to it.  When there's a listener, we have to hold a reference to the
JavaScript wrapper since it's what holds onto the JavaScript function we
call.  But the wrapper holds a reference to our WebCore object.  We can
break the cycle only when we know that we're not going to call any more
events on it.  We know that when .close() is called.

Working around this as is will be tricky, but isn't really a spec problem.
 But it does mean that the developer will need to always call .close() or
ask the user to close the tab in order to ever be able to run a setVersion
transaction.  At least for the time being in any WebKit browser.


> In any case, I don't think that IDB should be the first place in the entire
> web platform where we expose GC behavior to clients.
>
> -atw
>
> On Tue, Feb 8, 2011 at 4:43 PM, Jonas Sicking  wrote:
>
>> 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.
>> >
>> > 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: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

[Drew Wilson]

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 reachability depends on the reachability of the entangled port on an
entirely separate process), and so we just don't.

My concern is that there may be situations like this with IDB - if at some
point it's possible for events to be fired on an IDB instance (if we support
triggers), you'll have a situation where the reachability of an IDB instance
may depend on the reachability of that same DB in other processes. The net
effect is that on multi-process/multi-heap platforms, we may not be able to
GC databases, while on other platforms (which have a unified heap) we will
be able to GC them. This will end up being a source of cross-browser
incompatibility, because code will work just fine on platforms that are able
to deterministically GC databases, but then will break on other platforms
that cannot.

(As an aside, Jeremy mentions that there may already be situations where we
cannot GC databases today - I don't know the spec well enough to comment,
though, so perhaps he can elaborate).

In any case, I don't think that IDB should be the first place in the entire
web platform where we expose GC behavior to clients.

-atw

On Tue, Feb 8, 2011 at 4:43 PM, Jonas Sicking  wrote:

> 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.
> >
> > 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: [widget] proposal to add defaultlocale attribute to widget element (P&C Spec), I18N ACTION-18

[Phillips, Addison]

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 does not provide 
the Widget container with a clear choice when the runtime language is not one 
of the languages provided.

Part of this oversight may be due to an expectation that there would be a 
"default" set of resources present in the Widget. For example, if you had a 
structure like this:

   Foo.html
   /locales
  /de-DE
  Foo.html

... then if the top "Foo.html" is the start file, it is the default and 
"/locales/de-DE/Foo.html" represents a German appropriate resource 
corresponding to that same file. The language of the top-level resource can be 
anything and can be defined using the usual attributes. However, there is no 
requirement that such content be provided nor that it be in any particular 
language.

This does not, as you point out, work with items defined in the config.xml file 
itself.

In practice, most resource systems require that the "base" or "root" locale's 
resources be present to guarantee full functionality. The description in 
Widget's P&C implies this. It should state it explicitly and/or provide a 
mechanism for specifying the default.

The attribute 'defaultlocale' that you propose makes sense as a means of doing 
this. The alternative is to overload xml:lang="", but this has a number of 
negative things associated with it--such as the fact that it prevents the 
format from indicating what language the default is.

Finally, on a separate topic, we want to note that there is significant 
progress on internationalization additions to ECMAScript going on currently, 
which will be of great benefit to widget writers interested in 
internationalization and which may be of interest to Webapps WG as a result.

Regards (for I18N),

Addison

Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature.
It is an architecture.


> -Original Message-
> From: public-i18n-core-requ...@w3.org [mailto:public-i18n-core-
> requ...@w3.org] On Behalf Of Marcos Caceres
> Sent: Monday, December 27, 2010 5:29 AM
> To: public-webapps; public-i18n-c...@w3.org
> Cc: Richard Ishida
> Subject: [widget] proposal to add defaultlocale attribute to widget
> element (P&C Spec), was Re: [widgets] Span example
> 
> On Fri, Apr 30, 2010 at 5:16 PM, Marcos Caceres 
> wrote:
> > Hi Richard,
> >
> > On Fri, Mar 26, 2010 at 9:32 PM, Richard Ishida 
> wrote:
> >>
> >> The example looks rather baroque, but I think it does illustrate
> a number
> >> of points.  (I think that in real life it may be simpler to just
> use
> >> xml:lang="he" and dir="rtl" on the description tag in a
> localized config
> >> file like this.  The example does currently illustrate
> inheritance though.
> >
> > Yeah, the example is convoluted on purpose to illustrate all the
> features
> > you mentioned.
> >
> >>
> >> It also shows how to markup up the language while still marking
> default
> >> text for localization failures.  I hadn't realised that that was
> how you
> >> indicated the default for localization. FWIW I'd have preferred
> a special
> >> attribute for that, rather than overloading the xml:lang
> attribute, but I
> >> guess it's too late to change that now. An attribute like
> >> localizationdefault="yes" would reduce the need for the extra
> spans.
> >
> > good point. We can add it to our list of things to add in the
> future.
> 
> Seems the future finally arrived!:)... After some experience with
> deploying i18nlized widgets and trying to communicate the i18n
> model
> of widgets to developers, Opera strongly feels the need to add a
> "defaultlocale" (or similarly named) attribute to the widget
> element
> defined in the P&C spec.
> 
> As was pointed out by Richard, the problem with the current spec is
> that we have overloaded the semantics and functionality of xml:lang.
> As a result, the only way for an author to say that some content is
> not localized was for it not to have an xml:lang attribute (or for
> the
> xml:lang attribute to be explicitly empty). This is causing
> confusion
> amongst our development community. What would be preferable would
> be
> to have some means for authors to explicitly declare the default
> locale of a widget.
> 
> Consider the addition of a defaultlocale attribute:
> 
> http://www.w3.org/ns/widgets";
> defaultlocale = "en-us">
> 
>
> The Ultimate Weather Widget
>
> 
>
> Boletim Metereológico
>
> 
> 
> As in this case there is no unlocalized content, the user agent
> that
> does not support either 'en-us' or 'pt' will not select any content
> (!). Having  the defaultlocale allows the author to hint to user
> agent
> which one of the two to use in case it cannot match any conte