[Webkit-unassigned] [Bug 103484] IndexedDB: Implement IndexedDB bindings for JSC

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=103484


Kentaro Hara <haraken at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #177628|review?                     |review+
               Flag|                            |




--- Comment #11 from Kentaro Hara <haraken at chromium.org>  2012-12-04 20:26:58 PST ---
(From update of attachment 177628)
View in context: https://bugs.webkit.org/attachment.cgi?id=177628&action=review

Looks OK. This will behave consistently with V8's one.

> > > Source/WebCore/bindings/js/IDBBindingUtilities.cpp:228
> > > +    ExecState* exec = requestState->exec();
> > > +    APIEntryShim entryShim(exec);
> > 
> > You can use DOMRequestState::Scope.
> > 
> > BTW, V8 binding isn't creating a scope of DOMRequestState::Scope, which looks wrong.
>
> I've removed all APIEntryShim scopes from IDBBindingUtilities.cpp. The V8 implementation of  IDBBindingUtilities.cpp assumes that the proper DOMRequestState scope has already been established  in the core IDB code, and the same now holds true for the JSC implementation.

OK, then why does V8 binding need to create 'v8::HandleScope handleScope;' in IDBBindingUtilities.cpp ? (e.g. createIDBKeyFromScriptValueAndKeyPath())

BTW, maybe I'm wrong but do we really need DOMRequestState? What we need is just to keep a ScriptExecutionContext, isn't it?

> Source/WebCore/bindings/js/IDBBindingUtilities.cpp:87
> +            unsigned length = array->length();

Nit: unsigned => size_t

The same comment for all unsigneds in this patch.

> Source/WebCore/bindings/js/IDBBindingUtilities.cpp:247
> +    return canInjectNthValueOnKeyPath(exec, scriptValue.jsValue(),
> +        keyPathElements, keyPathElements.size() - 1);

Nit: Don't wrap the line.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.