Bug 19450 - [IndexedDB] Key path segments should permit reserved words
Summary: [IndexedDB] Key path segments should permit reserved words
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: Indexed Database API (show other bugs)
Version: unspecified
Hardware: All All
: P2 minor
Target Milestone: ---
Assignee: This bug has no owner yet - up for the taking
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-10 20:57 UTC by Joshua Bell
Modified: 2013-03-01 01:06 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joshua Bell 2012-10-10 20:57:35 UTC
In the IDB spec the definition of a valid key path is built around:

A DOMString containing a JavaScript identifier [ECMA-262].

... plus dotted combinations of identifiers and arrays thereof.

ECMA-262 gives:

Identifier ::
  IdentifierName but not ReservedWord

IdentifierName ::
  IdentifierStart
  IdentifierName IdentifierPart
(etc)

And defines ReservedWord as:

ReservedWord ::
  Keyword
  FutureReservedWord
  NullLiteral
  BooleanLiteral

Keyword :: one of
  break do instanceof typeof case else new var ...
(etc)

This would appear to preclude key paths such as:

"foo.delete.bar"
"my.public.data"
"response.true.details"
"options.null"

Neither FF nor Chrome appear to reject such key paths.

I suggest the IDB spec be updated to refer specifically to the IdentifierName production in ECMA-262.
Comment 1 Odin Hørthe Omdal 2012-10-18 10:12:55 UTC
Opera also allows such keypaths. Looking at the implementation it calls the IdentifierName checker from our ecmascript module. Guess that's what everyone else did as well :P

I proactively changed keypath tests to also test that:

http://w3c-test.org/webapps/IndexedDB/tests/submissions/Opera/keypath.htm
Comment 2 Joshua Bell 2013-03-01 01:06:39 UTC
https://dvcs.w3.org/hg/IndexedDB/rev/c6b12332f5ae