[Bug 14408] New: [IndexedDB] Cursors .key/.primaryKey/.value shouldn't throw as soon as .continue is called

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14408

   Summary: [IndexedDB] Cursors .key/.primaryKey/.value shouldn't
throw as soon as .continue is called
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Indexed Database API
AssignedTo: dave.n...@w3.org
ReportedBy: jo...@sicking.cc
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org


Currently the 'got value' flag is set to false as soon as .continue() is
called. This makes it awkward to call .continue() at the top of your success
handler and then have several different branches that do different things
depending on the data since each branch has to take care to call .continue() at
the end.

Instead we should let cursors keep their current value until the success/error
event is fired, at which point their values are updated.

-- 
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: [IndexedDB] transaction order

[Israel Hilerio]

On Friday, October 07, 2011 2:52 PM, Jonas Sicking wrote:
> Hi All,
> 
> There is one edge case regarding transaction scheduling that we'd like to get
> clarified.
> 
> As the spec is written, it's clear what the following code should do:
> 
> trans1 = db.transaction(["foo"], IDBTransaction.READ_WRITE);
> trans1.objectStore("foo").put("value 1", "mykey");
> trans2 = db.transaction(["foo"], IDBTransaction.READ_WRITE);
> trans2.objectStore("foo").put("value 2", "mykey");
> 
> In this example it's clear that the implementation should first run
> trans1 which will put the value "value 1" in object store "foo" at key
> "mykey". The implementation should then run trans2 which will write
> overwrite the same value with "value 2". The end result is that "value 2" is
> the value that lives in the object store.
> 
> Note that in this case it's not at all ambiguous which transaction runs first.
> Since the two transactions have overlapping scope, trans2 won't even start
> until trans1 is committed. Even if we made the code something like:
> 
> trans1 = db.transaction(["foo"], IDBTransaction.READ_WRITE);
> trans1.objectStore("foo").put("value 1", "mykey");
> trans2 = db.transaction(["foo"], IDBTransaction.READ_WRITE);
> trans2.objectStore("foo").put("value 2", "mykey");
> trans1.objectStore("foo").put("value 3", "mykey");
> 
> we'd get the same result. Both put requests placed against trans1 will run
> first while trans2 is waiting for trans1 to commit before it begins running
> since they have overlapping scopes.
> 
> However, consider the following example:
> trans1 = db.transaction(["foo"], IDBTransaction.READ_WRITE);
> trans2 = db.transaction(["foo"], IDBTransaction.READ_WRITE);
> trans2.objectStore("foo").put("value 2", "mykey");
> trans1.objectStore("foo").put("value 1", "mykey");
> 
> In this case, while trans1 is created first, no requests are placed against 
> it,
> and so no database operations are started. The first database operation that
> is requested is one placed against trans2. In the firefox implementation, this
> makes trans2 run before trans1. I.e.
> we schedule transactions when the first request is placed against them, and
> not when the IDBDatabase.transaction() function returns.
> 
> The advantage of firefox approach is obvious in code like this:
> 
> someElement.onclick = function() {
>   trans1 = db.transaction(["foo"], IDBTransaction.READ_WRITE);
>   ...
>   trans2 = db.transaction(["foo"], IDBTransaction.READ_WRITE);
>   trans2.objectStore.put("some value", "mykey");
>   callExpensiveFunction();
> }
> 
> In this example no requests are placed against trans1. However since
> trans1 is supposed to run before trans2 does, we can't send off any work to
> the database at the time when the .put call happens since we don't yet
> know if there will be requests placed against trans1. Only once we return to
> the event loop at the end of the onclick handler will trans1 be "committed"
> and the requests in trans2 can be sent to the database.
> 
> However, the downside with firefox approach is that it's harder for
> applications to control which order transactions are run. Consider for
> example a program is parsing a big hunk of binary data. Before parsing, the
> program starts two transactions, one READ_WRITE and one READ_ONLY. As
> the binary data is interpreted, the program issues write requests against the
> READ_WRITE transactions and read requests against the READ_ONLY
> transaction. The idea being that the read requests will always run after the
> write requests to read from database after all the parsed data has been
> written. In this setup the firefox approach isn't as good since it's less
> predictable which transaction will run first as it might depend on the binary
> data being parsed. Of course, you could force the writing transaction to run
> first by placing a request against it after it has been created.
> 
> I am however not able to think of any concrete examples of the above binary
> data structure that would require this setup.
> 
> So the question is, which solution do you think we should go with. One thing
> to remember is that there is a very small difference between the two
> approaches here. It only makes a difference in edge cases. The edge case
> being that a transaction is created, but no requests are placed against it 
> until
> another transaction, with overlapping scope, is created.
> 
> Firefox approach has strictly better performance in this edge case.
> However it could also have somewhat surprising results.
> 
> I personally don't feel strongly either way. I also think it's rare to make a
> difference one way or another as it'll be rare for people to hit this edge 
> case.
> 
> But we should spell things out clearly in the spec which approach is the
> conforming one.
> 
> / Jonas
> 

In IE, the transaction that is first created locks the object stores associated 
with it.
Therefore in the scenario outlined by Jonas:

trans1 = db.transaction(["foo"], IDBTransaction.RE

RE: [indexeddb] Exception type for NON_TRANSIENT_ERR code

[Israel Hilerio]

On Monday, October 03, 2011 7:18 PM, Jonas Sicking wrote:
> On Mon, Oct 3, 2011 at 4:21 PM, Israel Hilerio 
> wrote:
> > On Thursday, September 29, 2011 12:04 AM, Jonas Sicking wrote:
> >> For several of these I think we can reuse existing DOMExceptions.
> >> Here's how I'd map the exceptions which are currently in the
> >> IndexedDB
> >> spec:
> >>
> >> UNKNOWN_ERR
> >> Mint a new UnknownError. Alternatively we could simply throw an
> >> ECMAScript Error object with no more specific type.
> >>
> >> NON_TRANSIENT_ERR
> >> I think in many cases we should simply throw a TypeError here. That
> >> seems to match closely to how TypeError is used by WebIDL now.
> >
> > As I'm mapping the Exception codes to the new Exception type model, I
> thought we should mint a new type for NON_TRANSIENT_ERR,
> NonTransientError.  The reason is that TypeError seems to be designed to
> cover all intrinsic conversion cases and NON_TRANSIENT_ERR seems to be
> dealing with additional validation beyond what TypeError normally checks
> for.  This will also allow us to assign a code value of 0 and a message: "This
> error occurred because an operation was not allowed on an object. A retry
> of the same operation would fail unless the cause of the error is corrected."
> 
> The reason I'm not a fan of NonTransientError is that it doesn't really mean
> anything. All it says is "you'd get the same error if you tried the operation
> again". However that is true for almost all exceptions in any DOM spec. The
> only case that I can think of where that isn't the case is when using the
> synchronous IndexedDB API or when using synchronous XHR.send and there
> is a IO or network error.
> 
> I looked through the spec and came up with this list for when we're currently
> throwing NON_TRANSIENT_ERR and I agree that not in all of them it makes
> sense to use TypeError. Here is what I came up with:
> 
> IDBFactory.cmp if either key is not a valid key
>   This should throw DataError per Joshua's email.
> 
> IDBDatabase(Sync).createObjectStore if the keypath argument contains an
> invalid keypath
>   This best fit here seems to be "SyntaxError" in DOMException.
> 
> IDBDatabase(Sync).createObjectStore if the options argument is handed an
> object with properties other than those in the dictionary.
>   This doesn't actually match how dictionaries are supposed to behave per
> WebIDL. They are defined to ignore all properties not defined by the
> dictionary IDL. So we should remove this exception and also change the type
> of this argument to use "IDBDatabaseOptionalParameters"
> rather than "Object".
> 
> IDBDatabase(Sync).transaction when passed an invalid mode
>   I think other specs throw a TypeError in similar situations, but can't 
> think of
> any examples off the top of my head.
> 
> IDBObjectStore(Sync).createIndex if the keypath argument contains an
> invalid keypath
>   Same as for createObjectStore
> 
> IDBObjectStore(Sync).createIndex if the options argument is handed an
> object with properties other than those in the dictionary.
>   Same as for createObjectStore
> 
> IDBCursor(Sync).advance if passed a negative or zero value
>   WebIDL throws TypeError in other similar out-of-range situations
> 
> Let me know what you think.
> 
> / Jonas

Sounds reasonable!  I'll make sure we include these changes when we update the 
spec.
Thanks,

Israel

Re: Question about implementing DataTransfer.addElement

[Tab Atkins Jr.]

On Fri, Oct 7, 2011 at 3:18 PM, Daniel Cheng  wrote:
> The way drag images work today is we take a snapshot and then hand it off to
> the system. To support addElement(), we'd need:
> 1. Some way to detect when that element has changed in visual appearance so
> we can update the drag image.
> 2. Some way to actually update the drag image in the middle of a drag. This
> is (as far as I'm aware) impossible with the documented interface for
> Windows DnD, and I'm not aware of an undocumented way to do it either.
> I'm more concerned about the latter, and while I don't believe it's
> impossible to solve, I think it would be difficult to make performant in
> case of things like video or other embedded content.

Ah, I wasn't aware that we simply handed the image off to the system
and let it handle the drag.  Ignore my message, then.

~TJ

Re: Question about implementing DataTransfer.addElement

[Daniel Cheng]

The way drag images work today is we take a snapshot and then hand it off to
the system. To support addElement(), we'd need:
1. Some way to detect when that element has changed in visual appearance so
we can update the drag image.
2. Some way to actually update the drag image in the middle of a drag. This
is (as far as I'm aware) impossible with the documented interface for
Windows DnD, and I'm not aware of an undocumented way to do it either.

I'm more concerned about the latter, and while I don't believe it's
impossible to solve, I think it would be difficult to make performant in
case of things like video or other embedded content.

Daniel

On Fri, Oct 7, 2011 at 15:01, James Robinson  wrote:

> On Fri, Oct 7, 2011 at 2:56 PM, Tab Atkins Jr. wrote:
>
>> On Fri, Oct 7, 2011 at 2:45 PM, Daniel Cheng  wrote:
>> > For technical reasons, animating the drag image is non-trivial and not
>> > likely to be implemented in the near future, if it is ever implemented.
>>
>> I would think that it's basically identical, technically, to
>> implementing the element() function from CSS Image Values, which I
>> believe we're planning to do.
>>
>
> Not quite.  With the element() function the 'live copy' still lives in the
> page and renders the same way everything else does.  My understanding (and
> Daniel can correct me if I'm wrong) is that drag images do not render the
> same way due to platform integration concerns and so the technical cost for
> the two is fairly different.
>
> - James
>
>
>> ~TJ
>>
>>
>

RE: [indexeddb] Change IDBRequest.errorCode property to match new Exception type model

[Israel Hilerio]

On Monday, October 03, 2011 7:31 PM, Jonas Sicking wrote:
> On Mon, Oct 3, 2011 at 5:36 PM, Israel Hilerio  wrote:
> > Jonas,
> >
> > We're removing error code values as part of the new exception type
> model.
> > This will impact the IDBRequest.errorCode property.  I believe we want
> > to rename this property to errorName and change its type to DOMString
> > in order to match the new Exception type model name. This change will
> > impact all the places where errorCode is used today in the spec.
> > However, it should be fairly easy to fix assuming we follow the above
> model.
> >
> > Do you agree?
> 
> We might want to do something similar to what the FileAPI spec is doing,
> and the HTML5 spec is doing for HTMLMediaElement. Both specs have a
> .error property which returns an object which contains error information. A
> nice aspect of that approach is that it enables us to add more information
> about the error later, and even have different pieces of information for
> different errors.
> 
> / Jonas

We like the approach!  We'll update the IDBRequest.errorCode property to 
IDBRequest.error and assign it a type of DOMError to mimic the spec changes in 
the File API [1].  We'll also use the same DOMError reference as you.

In addition, we'll add a new "error" property to the IDBTransaction property, 
per our previous email thread, to capture the request or system error that 
triggered the onerror and onabort handlers.

Everywhere where we currently use an errorCode like "section 4.4 Steps for 
aborting a transaction" step 2.1, we'll change the text from:

1. Set the done flag on the request to true, set result of the request to 
undefined and set errorCode of the request to ABORT_ERR.

To something equivalent but using DOMError:

1. Set the done flag on the request to true, set result of the request to 
undefined and set the error attribute to a new DOMError object with a name 
attribute of AbortError.

Is this what you had in mind?

Israel
[1] http://dev.w3.org/2006/webapi/FileAPI/

Re: Question about implementing DataTransfer.addElement

[James Robinson]

On Fri, Oct 7, 2011 at 2:56 PM, Tab Atkins Jr.  wrote:

> On Fri, Oct 7, 2011 at 2:45 PM, Daniel Cheng  wrote:
> > For technical reasons, animating the drag image is non-trivial and not
> > likely to be implemented in the near future, if it is ever implemented.
>
> I would think that it's basically identical, technically, to
> implementing the element() function from CSS Image Values, which I
> believe we're planning to do.
>

Not quite.  With the element() function the 'live copy' still lives in the
page and renders the same way everything else does.  My understanding (and
Daniel can correct me if I'm wrong) is that drag images do not render the
same way due to platform integration concerns and so the technical cost for
the two is fairly different.

- James


> ~TJ
>
>

[Bug 13717] Clarify that a MessagePort clone, when created, hasn't been transfered, even if it was created as a result of another being transfered. ("If any object is listed in transfer more than on

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13717

Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #1 from Ian 'Hixie' Hickson  2011-10-07 22:00:12 UTC 
---
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the tracker issue; or you may create a tracker issue
yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: see diff given below
Rationale: Concurred with reporter's comments.

-- 
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: Question about implementing DataTransfer.addElement

[Tab Atkins Jr.]

On Fri, Oct 7, 2011 at 2:45 PM, Daniel Cheng  wrote:
> For technical reasons, animating the drag image is non-trivial and not
> likely to be implemented in the near future, if it is ever implemented.

I would think that it's basically identical, technically, to
implementing the element() function from CSS Image Values, which I
believe we're planning to do.

~TJ

[IndexedDB] transaction order

[Jonas Sicking]

Hi All,

There is one edge case regarding transaction scheduling that we'd like
to get clarified.

As the spec is written, it's clear what the following code should do:

trans1 = db.transaction(["foo"], IDBTransaction.READ_WRITE);
trans1.objectStore("foo").put("value 1", "mykey");
trans2 = db.transaction(["foo"], IDBTransaction.READ_WRITE);
trans2.objectStore("foo").put("value 2", "mykey");

In this example it's clear that the implementation should first run
trans1 which will put the value "value 1" in object store "foo" at key
"mykey". The implementation should then run trans2 which will write
overwrite the same value with "value 2". The end result is that "value
2" is the value that lives in the object store.

Note that in this case it's not at all ambiguous which transaction
runs first. Since the two transactions have overlapping scope, trans2
won't even start until trans1 is committed. Even if we made the code
something like:

trans1 = db.transaction(["foo"], IDBTransaction.READ_WRITE);
trans1.objectStore("foo").put("value 1", "mykey");
trans2 = db.transaction(["foo"], IDBTransaction.READ_WRITE);
trans2.objectStore("foo").put("value 2", "mykey");
trans1.objectStore("foo").put("value 3", "mykey");

we'd get the same result. Both put requests placed against trans1 will
run first while trans2 is waiting for trans1 to commit before it
begins running since they have overlapping scopes.

However, consider the following example:
trans1 = db.transaction(["foo"], IDBTransaction.READ_WRITE);
trans2 = db.transaction(["foo"], IDBTransaction.READ_WRITE);
trans2.objectStore("foo").put("value 2", "mykey");
trans1.objectStore("foo").put("value 1", "mykey");

In this case, while trans1 is created first, no requests are placed
against it, and so no database operations are started. The first
database operation that is requested is one placed against trans2. In
the firefox implementation, this makes trans2 run before trans1. I.e.
we schedule transactions when the first request is placed against
them, and not when the IDBDatabase.transaction() function returns.

The advantage of firefox approach is obvious in code like this:

someElement.onclick = function() {
  trans1 = db.transaction(["foo"], IDBTransaction.READ_WRITE);
  ...
  trans2 = db.transaction(["foo"], IDBTransaction.READ_WRITE);
  trans2.objectStore.put("some value", "mykey");
  callExpensiveFunction();
}

In this example no requests are placed against trans1. However since
trans1 is supposed to run before trans2 does, we can't send off any
work to the database at the time when the .put call happens since we
don't yet know if there will be requests placed against trans1. Only
once we return to the event loop at the end of the onclick handler
will trans1 be "committed" and the requests in trans2 can be sent to
the database.

However, the downside with firefox approach is that it's harder for
applications to control which order transactions are run. Consider for
example a program is parsing a big hunk of binary data. Before
parsing, the program starts two transactions, one READ_WRITE and one
READ_ONLY. As the binary data is interpreted, the program issues write
requests against the READ_WRITE transactions and read requests against
the READ_ONLY transaction. The idea being that the read requests will
always run after the write requests to read from database after all
the parsed data has been written. In this setup the firefox approach
isn't as good since it's less predictable which transaction will run
first as it might depend on the binary data being parsed. Of course,
you could force the writing transaction to run first by placing a
request against it after it has been created.

I am however not able to think of any concrete examples of the above
binary data structure that would require this setup.

So the question is, which solution do you think we should go with. One
thing to remember is that there is a very small difference between the
two approaches here. It only makes a difference in edge cases. The
edge case being that a transaction is created, but no requests are
placed against it until another transaction, with overlapping scope,
is created.

Firefox approach has strictly better performance in this edge case.
However it could also have somewhat surprising results.

I personally don't feel strongly either way. I also think it's rare to
make a difference one way or another as it'll be rare for people to
hit this edge case.

But we should spell things out clearly in the spec which approach is
the conforming one.

/ Jonas

Question about implementing DataTransfer.addElement

[Daniel Cheng]

What's the difference between addElement and setDragImage()?

The spec says:

> The difference between setDragImage() and addElement() is that the latter
> automatically generates the image based on the current rendering of the
> elements added (potentially keeping it updated as the drag continues, e.g.
> if the elements include an actively playing video), whereas the former uses
> the exact specified image at the time the method is invoked.


For technical reasons, animating the drag image is non-trivial and not
likely to be implemented in the near future, if it is ever implemented.
However, if we don't implement dynamic drag image updates, doesn't that make
it essentially the same as setDragImage()? In that case, what's the point of
having addElement(); wouldn't it make more sense to just remove it rather
than having two different ways of doing the same thing?

Daniel

Re: [IndexedDB] Passing an empty array to IDBDatabase.transaction

[Jonas Sicking]

On Fri, Oct 7, 2011 at 11:51 AM, Israel Hilerio  wrote:
> On Thursday, October 06, 2011 5:44 PM, Jonas Sicking wrote:
>> Hi All,
>>
>> In both the Firefox and the Chrome implementation you can pass an empty
>> array to IDBDatabase.transaction in order to create a transaction which has
>> a scope that covers all objectStores in the database. I.e. you can do
>> something like:
>>
>> trans = db.transaction([]);
>> trans.objectStore();
>>
>> (Note that this is *not* a dynamic scoped transaction, it's still a static 
>> scope
>> that covers the whole database).
>>
>> In other words, these implementations treat the following two lines as
>> equivalent:
>>
>> trans = db.transaction([]);
>> trans = db.transaction(db.objectStoreNames);
>>
>> This, however, is not specified behavior. According to the spec as it is now
>> the transaction should be created with an empty scope.
>>
>> I suspect both Mozilla and Google implemented it this way because we had
>> discussions about this syntax on the list. However apparently this syntax
>> never made it into the spec. I don't recall why.
>>
>> I'm personally not a big fan of this syntax. My concern is that it makes it
>> easier to create a widely scoped transaction which has less ability to run in
>> parallel with other transactions, than to create a transaction with as narrow
>> scope as possible. And passing db.objectStoreNames is always possible.
>>
>> What do people think we should do? Should we add this behavior to the
>> spec? Or are implementations willing to remove it?
>>
>> / Jonas
>>
>
> Our implementation interprets the empty array as an empty scope.  We allow 
> the transaction to be created but we throw a NOT_FOUND_ERR when trying to 
> access any object stores.
> I vote for not having this behavior :-).

I'm fine with this, but I'd like to hear from Google too.

/ Jonas

CfC: adding Mutation Observers to DOM4; deadline Oct 14 [Was: Re: Mutation Observers: a replacement for DOM Mutation Events]

[Arthur Barstow]

On 10/6/11 9:11 AM, ext Arthur Barstow wrote:

On 9/30/11 3:40 PM, ext Ms2ger wrote:

On 09/29/2011 04:32 PM, Doug Schepers wrote:

Hi, Adam-

I'm glad to see some progress on a replacement for Mutation Events.

Would you be interested in being the editor for this spec? It's already
in our charter, we just need someone to take it up. Olli has offered
offlist to be a co-editor, so between the two of you, I think it would
be pretty manageable.

I'd be happy to help get you started.


I repeat my objections to speccing this outside DOM4. I would, of 
course, welcome Olli or Adam to become co-editors if they would wish 
that.


I scanned the list archive and did not find your objection. Which 
message(s) includes your objection?


Ms2ger responded in IRC that [1] includes his objection (not sure how I 
could have missed that one ;-)). I don't know why, but I never received 
the Oct 1 response from Ojan [2] nor the Oct 3 response from Adam [3] 
and just learned about them today.


It appears a next step is to determine if anyone objects to Mutation 
Observers [4] being added to DOM4. As such, this is a CfC to do so and 
if anyone has any comments, please reply to this e-mail by October 14.


-AB

[1] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0790.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0029.html
[3] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0003.html
[4] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1622.html

[Bug 14406] ывавып ав ыав р р

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14406

Art Barstow  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||art.bars...@nokia.com
 Resolution||INVALID

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

[Bug 14406] New: ывавып ав ыав р р

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14406

   Summary: ывавып ав ыав р р
   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 Storage (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: contribu...@whatwg.org
 QAContact: member-webapi-...@w3.org
CC: i...@hixie.ch, m...@w3.org, public-webapps@w3.org


Specification: http://dev.w3.org/html5/webstorage/
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top

Comment:
ывавып ав ыав р р 

Posted from: 95.132.132.171
User agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like
Gecko) Chrome/14.0.835.202 Safari/535.1

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

[File API] Calling requestFileSystem with bad filesystem type

[Mark Pilgrim]

What should this do?

requestFileSystem(2, 100, successCallback); // assume successCallback
is defined properly

-Mark

RE: [IndexedDB] Passing an empty array to IDBDatabase.transaction

[Israel Hilerio]

On Thursday, October 06, 2011 5:44 PM, Jonas Sicking wrote:
> Hi All,
> 
> In both the Firefox and the Chrome implementation you can pass an empty
> array to IDBDatabase.transaction in order to create a transaction which has
> a scope that covers all objectStores in the database. I.e. you can do
> something like:
> 
> trans = db.transaction([]);
> trans.objectStore();
> 
> (Note that this is *not* a dynamic scoped transaction, it's still a static 
> scope
> that covers the whole database).
> 
> In other words, these implementations treat the following two lines as
> equivalent:
> 
> trans = db.transaction([]);
> trans = db.transaction(db.objectStoreNames);
> 
> This, however, is not specified behavior. According to the spec as it is now
> the transaction should be created with an empty scope.
> 
> I suspect both Mozilla and Google implemented it this way because we had
> discussions about this syntax on the list. However apparently this syntax
> never made it into the spec. I don't recall why.
> 
> I'm personally not a big fan of this syntax. My concern is that it makes it
> easier to create a widely scoped transaction which has less ability to run in
> parallel with other transactions, than to create a transaction with as narrow
> scope as possible. And passing db.objectStoreNames is always possible.
> 
> What do people think we should do? Should we add this behavior to the
> spec? Or are implementations willing to remove it?
> 
> / Jonas
> 

Our implementation interprets the empty array as an empty scope.  We allow the 
transaction to be created but we throw a NOT_FOUND_ERR when trying to access 
any object stores.
I vote for not having this behavior :-).

Israel

[Bug 14405] New: Steps for firing success/error events on a request are very transaction-centric

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14405

   Summary: Steps for firing success/error events on a request are
very transaction-centric
   Product: WebAppsWG
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Indexed Database API
AssignedTo: dave.n...@w3.org
ReportedBy: m...@kylehuey.com
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org


e.g.
http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-fire-a-success-event

In particular, this obscures the fact that if a success event handler throws on
a request that has no transaction (e.g. IDBOpenDBRequest) there is no error
event fired (because that error event is fired from the steps for aborting a
transaction, and there is no transaction to abort).

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

[Bug 14404] New: Version of an IDBDatabase from an aborted version change transaction needs to be specified

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14404

   Summary: Version of an IDBDatabase from an aborted version
change transaction needs to be specified
   Product: WebAppsWG
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Indexed Database API
AssignedTo: dave.n...@w3.org
ReportedBy: m...@kylehuey.com
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org


Consider the following for a database that does not already exist:

var db;
var request = indexedDB.open(name, 1);
request.onupgradeneeded = function() {
  db = request.result;
  throw "STOP";
}
request.onerror = function() {
  alert(db.version);
}

What should the version be here?  The new version?  The old version?  Something
else?  By my reading of the spec, since the version is not supposed to change
throughout the lifetime of an IDBDatabase, the answer is the new version, which
seems quite unintuitive since the upgrade failed.

-- 
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: RfC: LCWD of Web Socket API; comment deadline October 21

[Ian Hickson]

On Fri, 7 Oct 2011, Arthur Barstow wrote:
> 
> Would you please elaborate on this change?

Elaborate in what way?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: RfC: LCWD of Web Socket API; comment deadline October 21

[Arthur Barstow]

Hi Hixie,

In [1], Julian asks about Web Socket API rev 1.247 [2], the change that 
adds the Parsing WebSocket URLs section (CVS comment "Revert the part of 
r5409 that removed the URL parsing algorithms, since it's no longer 
defined in the protocol spec. (whatwg r6632)").


Would you please elaborate on this change?

-AB

[1] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0125.html
[2] 
http://dev.w3.org/cvsweb/html5/websockets/Overview.html.diff?r1=1.246;r2=1.247;f=h


On 10/5/11 3:15 AM, ext Julian Reschke wrote:

On 2011-09-29 18:28, Arthur Barstow wrote:

On September 29, aLCWD of Web Sockets API was published:

http://www.w3.org/TR/2011/WD-websockets-20110929/

Please send all comments to public-webapps@w3.org by October 21.


I just noted that as of yesterday, the API spec contains the custom 
URI parsing algorithm that we removed from the protocol spec a long 
time ago.


This was a post-LC change.

What's the Webapps WG's procedure to manage changes during LC?

Best regards, Julian

Re: Spec changes for LCs and later maturity levels [Was: Re: RfC: LCWD of Web Socket API; comment deadline October 21]

[Julian Reschke]

On 2011-10-07 13:55, Arthur Barstow wrote:

Hi Julian, All - I changed the subject to reflect the general
process-related issue here. I will respond separately to the WebSocket
specifics ...

WebApps has always used the Edit First, Review Second process, as
documented in our [WorkMode] document.

Overall, I think the process has worked reasonably well, yet it can
create some challenges, especially as a spec enters the later maturity
levels i.e. LC and later.

For specs in LC or later, I think the Editor(s) should feel free to make
minor changes e.g. editorial changes and bug fixes that would not
invalidate an implementation, without any explicit notification to the
group. However, for major changes e.g. a new feature or a bug fix that
would affect an implementation, I think it is reasonable to expect the
Editor(s) to make some type of explicit notification and that could be
done via an e-mail, bug report, new issue (e.g. Tracker), etc.
...


OK, so it would be helpful to understand whether the change I noticed 
(adding a section about ws-specific URL parsing that was removed from 
the protocol spec) is considered editorial or a bug fix.


As far as I recall, we agreed in the IETF WG that parsing of web socket 
URIs should work exactly the same way as for any other URI scheme. It 
appears that the API spec now tries to override this, and this looks 
problematic to me.


Best regards, Julian

Dictionaries in WebIDL

[Ross Burton]

Hi,

I'm trying to express in WebIDL an interface with a string attribute
"uri", and a string-string dictionary "options" that has no
restrictions on the keys.

In JS this would be something like this as a literal:

{
  uri: "",
  options: {}
}

Now I came up with the following WebIDL:

  /* arbitrary key-value hints */
  dictionary Options {};

  [Constructor]
  interface Item {
attribute DOMString uri;
attribute Options options;
  };

Which seems reasonable to me but the specification says "Dictionaries
must not be used as the type of an attribute, constant or exception
field".  Maybe I'm misreading the spec but doesn't this make my IDL
invalid?  Is there a better way of expressing what I want?

Related: is there a good tutorial/annotated reference/set of examples
for WebIDL?  The spec is quite... concise and isn't that great for
learning from. :)

Thanks,
Ross

Spec changes for LCs and later maturity levels [Was: Re: RfC: LCWD of Web Socket API; comment deadline October 21]

[Arthur Barstow]

On 10/5/11 3:15 AM, ext Julian Reschke wrote:

On 2011-09-29 18:28, Arthur Barstow wrote:

On September 29, aLCWD of Web Sockets API was published:

http://www.w3.org/TR/2011/WD-websockets-20110929/

Please send all comments to public-webapps@w3.org by October 21.


I just noted that as of yesterday, the API spec contains the custom 
URI parsing algorithm that we removed from the protocol spec a long 
time ago.


This was a post-LC change.

What's the Webapps WG's procedure to manage changes during LC?
Hi Julian, All - I changed the subject to reflect the general 
process-related issue here. I will respond separately to the WebSocket 
specifics ...


WebApps has always used the Edit First, Review Second process, as 
documented in our [WorkMode] document.


Overall, I think the process has worked reasonably well, yet it can 
create some challenges, especially as a spec enters the later maturity 
levels i.e. LC and later.


For specs in LC or later, I think the Editor(s) should feel free to make 
minor changes e.g. editorial changes and bug fixes that would not 
invalidate an implementation, without any explicit notification to the 
group. However, for major changes e.g. a new feature or a bug fix that 
would affect an implementation, I think it is reasonable to expect the 
Editor(s) to make some type of explicit notification and that could be 
done via an e-mail, bug report, new issue (e.g. Tracker), etc.


Some groups have defined relatively detailed processes for handling 
changes to specs at LC and later. My expectation is that everyone is 
participating with the best of intentions, and as such, I would prefer 
to not be overly prescriptive with the group's change process.


If others have additional or contrary thoughts about how the group 
should handle spec changes for specs at LC or later, please speak up.


-Art Barstow

[WorkMode] http://www.w3.org/2008/webapps/wiki/WorkMode

Re: Adding Web Intents to the Webapps WG deliverables

[Rich Tibbett]

Arthur Barstow wrote:

[ + DAPI Chairs and Team Contact ]

Hi Ian, All - for now, I think it is OK to use public-webapps for
*technical* discussions regarding James' proposal.

Let's plan to continue the charter-related part of this discussion
during WebApp's TPAC meeting. I added it to the Monday October 31
13:00-15:00 time slot:

http://www.w3.org/2008/webapps/wiki/TPAC2011#Agenda_Monday.2C_October_31

(FYI, Robin added a "Merge DAP into WebApps, proposed by Robin Berjon"
topic ins this same time slot.)


Robin is proposing an interesting idea.

Perhaps we could form a sub-group in WebApps to work on Device related 
features. Exactly what device-related features get picked up would be at 
the discretion of those involved. The options at this point are a.) None 
b.) some or c.) all of the deliverables of DAP transferring over to a 
group that has more comprehensive IP exclusion coverage.


It would be a lot easier if everyone joined the DAP WG instead but I 
feel we're going nowhere with that approach.


- Rich

Re: Adding Web Intents to the Webapps WG deliverables

[Arthur Barstow]

[ + DAPI Chairs and Team Contact ]

Hi Ian, All - for now, I think it is OK to use public-webapps for 
*technical* discussions regarding James' proposal.


Let's plan to continue the charter-related part of this discussion 
during WebApp's TPAC meeting. I added it to the Monday October 31 
13:00-15:00 time slot:


http://www.w3.org/2008/webapps/wiki/TPAC2011#Agenda_Monday.2C_October_31

(FYI, Robin added a "Merge DAP into WebApps, proposed by Robin Berjon" 
topic ins this same time slot.)


-ArtB

On 10/4/11 1:22 PM, ext Ian Fette (イアンフェッティ) wrote:
Circling back to the original topic, it seems like there's a good 
amount of interest and opinions, and that the spec would probably 
benefit from the input of the people in this WG, especially since 
multiple platforms are all shipping something similar in approach 
(android intents, contracts in win8 and whatever implication that has 
for Metro/IE, and the proposed web intents). This is good to see.


-Ian

On Thu, Sep 29, 2011 at 11:34 AM, Charles Pritchard > wrote:


Top posting: in web messaging, we typically set an origin property
on events and authors are expected to check that property.

Are your concerns addressed by that practice?

It is an added step, an added nuance. And developers may neglect
it. But, if they are neglecting origin, they are just plain
leaving security holes.



On Sep 28, 2011, at 12:09 PM, Adrienne Porter Felt
mailto:a...@berkeley.edu>> wrote:


Android developers chronically misunderstand and misuse Android
Intents, and these mistakes lead to security bugs. To illustrate
how prevalent the confusion is, Erika Chin and I found that 9 of
20 popular Android apps (45%!) contain security vulnerabilities
due to misusing Intents. I've also found these same types of bugs
in Google-produced Android applications (the default ones that
ship as built-in apps). I posted examples & details of two
real-world applications that exhibit these vulnerabilities:
http://www.adrienneporterfelt.com/blog/?p=313.

It's my hope that Web Intents can be designed to prevent
developers from making the same mistakes.

There are two common types of errors:

1) Android Intents can be used for both inter- and
intra-application communication, and developers don't know the
difference. A canonical accident occurs when a developer creates
a "unique" action string like foo.bar.xyz and uses it for
internal communication. The problem is that any other application
can register for the same action string, even if it's supposedly
hard to guess. This introduces two security bugs. (1) The
component that receives foo.bar.xyz has been unintentionally made
public, since anyone can send that action string to it. (2)
Another application could register to receive foo.bar.xyz and
steal any data associated with it, or simply gain the user's
attention away from the original app.

2) The Android OS sends Intents to applications as notifications.
Developers register components to receive these system Intents.
By default, registering for a system Intent makes a component
public. Developers don't realize that these components become
public by default, so they don't check that the Intent was really
sent by the OS.

I have two suggestions to prevent these same errors from
appearing in Web Intents:

1) Developers need to be discouraged from using Web Intents for
internal application communication. One way to do this is to make
it so that Web Intents are only delivered after the user selects
a service in a browser popup window. (Nothing hidden in the
background!) This would be annoying for intra-application
communication, so I think developers would avoid it.

2) If a developer registers to receive a Web Intent from the
browser (like for a system notification), that component should
NOT be invocable by any other application unless it's registered
for a second Intent as well.

Adrienne