[Webkit-unassigned] [Bug 55095] IndexedDB: fire versionchange events when calling setVersion

[bugzilla-daemon at webkit.org]

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





--- Comment #8 from David Grogan <dgrogan at chromium.org>  2011-02-28 13:12:59 PST ---
(From update of attachment 84099)
View in context: https://bugs.webkit.org/attachment.cgi?id=84099&action=review

The spec doesn't seem to anticipate a connection calling setVersion but closing before its versionchange events get sent to the other connections or its blocked event getting fired.  Should those events fire?  The spec, in 4.7.4, is clear that such a connection shouldn't receive the versionchange events from OTHER connections, but doesn't mention its own events.

The code in this patch prevents the blocked event from being delivered to the closed connection (because the text of 4.7.4 and 4.7.5 could, possibly, be tortured to indicate this is proper) but allows the other connections to receive versionchange events originating from the closed connection.  I suspect that they shouldn't receive such events, though.

> Source/WebCore/storage/IDBDatabase.cpp:168
> +void IDBDatabase::enqueueEvent(PassRefPtr<Event> event)

this override seems necessary to call event->setTarget(this);  True?

> Source/WebCore/storage/IDBDatabase.cpp:179
> +    if (m_noNewTransactions)

This behavior is in the spec.

But is it kosher to withhold events in ::dispatchEvent or do I need to use something like the local event queue from your outstanding transaction patch?

> Source/WebCore/storage/IDBDatabaseBackendImpl.cpp:177
> +    if (m_databaseCallbacksSet.size() > 1) {

I'm not sure how correct this is.  The spec says:
4.7.4: fire versionchange events
4.7.5: "If running asynchronously and any of the connections in openDatabases are still not closed, fire a blocked event at request."  That "still" seems to indicate that the other connections should be given a chance to close before firing onblocked at the connection calling setVersion.  But this implementation does no such thing, it just fires away.  Does the spec wording need to be changed, or does this code?

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