Hello all,
Recently I've been working on a mobile application that makes heavy use of
IndexedDB. In particular, there are times when this app must query a
potentially large, non-consecutive list of keys. Currently (to my knowledge)
the IndexedDB API requires that this be done via separate
On Tue, May 14, 2013 at 4:24 AM, Charles McCathie Nevile
cha...@yandex-team.ru wrote:
On Mon, 13 May 2013 17:25:23 +0100, Anne van Kesteren ann...@annevk.nl
wrote:
What's wrong with the http://url.spec.whatwg.org/ URL standard.
1. It is apparently not intended to become a stable reference
IDBKeyRange.inList looks practically useful, but it can be achieve
continue (continuePrimary) cursor iteration. Performance will be
comparable except multiple round trip between js and database.
Querying by parallel multiple get in a single transaction should also
be fast as well.
Additionally
Sorry for reposting again for
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0422.html Perhaps
I am not well explain enough.
In put and add method of object store and index, DataCloneError and
DataError are immediately throw before executing IDBRequest. It seems good
that exception
It will be good, if we can provide data priority per database and/or per
object store.
Web app already assume Indexeddb data is temporary, recovery process are in
place at the beginning after database is successfully open. So silently
drop all data and set version to 0 is good way to go. I think
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22093
Bug ID: 22093
Summary: Consider adding candidatewindowshow/update/hide events
and getCandidateWindowClientRect()
Classification: Unclassified
Product: WebAppsWG
Version:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22094
Bug ID: 22094
Summary: Add 'target' in InputMethodContext
Classification: Unclassified
Product: WebAppsWG
Version: unspecified
Hardware: All
OS: All
Status:
