Original test: http://mxr.mozilla.org/mozilla2.0/source/dom/indexedDB/test/test_open_empty_db.html?force=1 Expected result: webkitIndexedDB.open(null, 'foo') should throw a webkitIDBDatabaseException.NON_TRANSIENT_ERR Actual result: no exception thrown Citation: http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#widl-IDBFactory-open states that name can not be null. Mozilla throws NON_TRANSIENT_ERR in response to this condition.
Created attachment 92068 [details] test case
Created attachment 92073 [details] Patch
I'm happy to r+ this patch (seems simple enough), but it would be nice if someone actually working on indexeddb took a look.
Comment on attachment 92073 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=92073&action=review unofficial r+ > Source/WebCore/storage/IDBFactory.cpp:71 > + if (name.isNull()) { Mark, do you want to file a w3 bug saying that the spec should be updated to reflect throwing NON_TRANSIENT_ERR in this case? > Source/WebCore/storage/IDBFactory.idl:31 > + [CallWith=ScriptExecutionContext] IDBRequest open(in [ConvertNullToNullString] DOMString name) Tony, do you know if [ConvertNullToNullString] has downsides that might have caused it to be omitted initially?
Comment on attachment 92073 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=92073&action=review >> Source/WebCore/storage/IDBFactory.idl:31 >> + [CallWith=ScriptExecutionContext] IDBRequest open(in [ConvertNullToNullString] DOMString name) > > Tony, do you know if [ConvertNullToNullString] has downsides that might have caused it to be omitted initially? I don't know of any downsides. I suspect it was just an oversight.
Comment on attachment 92073 [details] Patch Clearing flags on attachment: 92073 Committed r85770: <http://trac.webkit.org/changeset/85770>
All reviewed patches have been landed. Closing bug.
http://trac.webkit.org/changeset/85770 might have broken GTK Linux 64-bit Debug The following tests are not passing: http/tests/navigation/response204.html