[webkit-dev] Notifications for Blob serialization/deserialization

[Greg Billock]

I've been working with Michael Nordman on a problem related to Blob
serialization. Currently, if we serialize a Blob, there's no
notification to the BlobRegistry, so the serialized Blob will be
garbage collected at an indeterminate time if the context in which it
was created is closed. This lifetime scoping is spelled out clearly
for Blob URLs created using the URL API. I see nothing in the spec
imposing the same lifetime scoping on Blobs themselves, so I think it
is an implementation flaw. To correctly handle this serialization
case, however, the BlobRegistry needs to know when serialization and
deserialization operations happen for Blob objects.

I've created a patch that adds that logic and plumbs it through to the
Chromium API. Webkit patch:
https://bugs.webkit.org/show_bug.cgi?id=89921 The corresponding
Chromium-side patch is here: http://codereview.chromium.org/10662024/


The strategy I used is to create a new internal URL and use that for
serialization:

  KURL cloneURL = BlobURL::createInternalURL();
  blobRegistry().didSerializeBlob(cloneURL, blob->url());
  m_writer.writeBlob(cloneURL.string(), blob->type(), blob->size());
  m_blobURLs.append(cloneURL.string());

Then upon deserialization, there's a corresponding didDeserializeBlob call.

There are a couple alternatives I considered. One is to not instrument
the SerializedScriptValue this way, but require callers to use the
blobURLs() accessor and do the right thing then. I'm more in favor of
inserting this logic directly into serialization, since it removes an
implementation gotcha and I think this more closely follows the spec.
Since the primary interaction with the BlobRegistry is via URL, I
maintained that as well. The other is to use BlobData directly here.
Michael is planning on doing some maintenance work to the ID system
used internally anyway, and that may end up being the right path to
take in that case.

The open-ended implication of this change is that throwing away
serialized values is now not acceptable -- they need to be checked for
blob refs and then have some to-be-written code invoked to trigger the
deref of the BlobData. We don't know where all that may be happening,
currently, so it's still something of a science project. We already
have a SerializedScriptValue object we could interrogate upon
destruction, but the whole point is that the wire format created there
could show up anywhere, so we need to either restrict that ability and
maintain object-level control, or trust callers of the serialized wire
string accessor to handle them correctly. Neither is particularly
exciting. Any better ideas?

-Greg