Bug 132402 – Move Blob.slice() implementation into BlobRegistryImpl

• Component: WebCore Misc.
• Status: RESOLVED FIXED

[Alexey Proskuryakov]

Blob is an API object living in WebProcess that shouldn't know the details of snapshotting or size computation. That should happen on NetworkProcess side.

[Alexey Proskuryakov]

File size tracking is tricky. At the moment, we capture the size in BlobBuilder, and also in Blob.slice(). This is inconsistent - Files that were used in these APIs are snapshotted, but Files that come from drag&drop or file chooser are not.

This makes particularly little sense for BlobBuilder, because it does not need the size.

[Alexey Proskuryakov]

Created attachment 230525 [details]
proposed patch

[WebKit Commit Bot]

Attachment 230525 [details] did not pass style-queue:


ERROR: Source/WebKit2/NetworkProcess/NetworkConnectionToWebProcess.h:93:  The parameter name "url" adds no information, so it should be removed.  [readability/parameter_name] [5]
Total errors found: 1 in 16 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Anders Carlsson]

Comment on attachment 230525 [details]
proposed patch

View in context: https://bugs.webkit.org/attachment.cgi?id=230525&action=review

> Source/WebCore/fileapi/ThreadableBlobRegistry.cpp:94
>      if (isMainThread())
>          blobRegistry().registerBlobURL(url, std::move(blobData));

I think yo should put an early return here instead of an else block.

> Source/WebCore/fileapi/ThreadableBlobRegistry.cpp:112
>      if (isMainThread())
>          blobRegistry().registerBlobURL(url, srcURL);

Same thing here.

> Source/WebCore/fileapi/ThreadableBlobRegistry.cpp:127
> +    unsigned long long resultSize;
> +    if (isMainThread())
> +        resultSize = blobRegistry().registerBlobURLForSlice(newURL, srcURL, start, end);

Same thing here.

> Source/WebCore/fileapi/ThreadableBlobRegistry.cpp:137
> +        semaphore.wait(DBL_MAX);

Use std::numeric_limits<double>::max() instead.

[Alexey Proskuryakov]

We normally do an early return for the unusual case, but here, it's the unusual (secondary thread) case that is long.

[Alexey Proskuryakov]

Committed <http://trac.webkit.org/r168054>.