[Webkit-unassigned] [Bug 40054] [indexedDB] It is impossible to create object stores

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Jun 2 10:03:40 PDT 2010


--- Comment #11 from Jeremy Orlow <jorlow at chromium.org>  2010-06-02 10:03:40 PST ---
(In reply to comment #10)
> (In reply to comment #7)
> > WebCore/storage/IDBDatabaseImpl.h:60
> >  +      RefPtr<IDBWeakFramePtr> m_weakFramePtr;
> > I don't think it makes sense for this to be here.  The frame pointer is really an issue that should be entirely constrained to the request objects.
> >
> Yes, but the IDBDatabase needs to be able to create Request objects of its own, so it need to pass the weak reference to them.

We need to figure out another way.  In Chromium, these pointers don't exist in the browser process which is where the impl exists.  I know you're hijacking them at the proxy layer, but it's still pretty ugly.  Lets figure out a way.

> > WebCore/storage/IndexedDatabaseRequest.h:57
> >  +      void disconnectFrame() { m_framePtr->disconnectFrame(); }
> > I think you should get rid of disconnectFrame here, have DOMWindow create the IDBWeakFramePtr on demand, and call disconnectFrame direclty on it when necessary.
> I am not sure I agree. Right now, the weak pointer is a private implementation detail of the IDB module. The entry point to that is the IndexedDatabaseRequest class so I think it is neater to let the DOMWindow only know about the IndexedDatabaseRequest instance. Perhaps we should reconsider this if we are to use the weak pointer idea in other places?

Is it possible for IndexedDatabaseRequest to go away before disconnectFrame is called?  If so, we have a problem.  If not then add an assert into ~IndexedDatabaseRequest to ensure the weak pointer is 0.  That'll alleviate my worry if so.

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

More information about the webkit-unassigned mailing list