[ABANDONED] Get content of resources from Blob when the downloadToFile option is enabled

Get content of resources from Blob when the downloadToFile option is enabled

When the downloadToFile options is enabled, a resource has a file-path
instead of a buffer. So the Inspector cannot get content directly from
the resource.
So we introduce Blob content data to NetworkResourcesData::ResourceData.
It holds the Blob and the textEncodingName. The Inspector get content
from it by using FileReaderLoader.

Currently, there's no resources with the downloadToFile option except
for Pepper API. So these codes are not used yet. However we're working on
optimizing XHR with responseType="blob"[1] and it will leverage this option.
So not to break the inspector, first we need to land this patch.

[1]: http://crbug.com/269055

BUG=269055

[yusukesuzuki, 2013-09-12 12:18:32]

https://chromiumcodereview.appspot.com/23658039/diff/5001/LayoutTests/http/te...
File
LayoutTests/http/tests/inspector/network/network-xhr-async-response-type-blob.html
(right):

https://chromiumcodereview.appspot.com/23658039/diff/5001/LayoutTests/http/te...
LayoutTests/http/tests/inspector/network/network-xhr-async-response-type-blob.html:30:
var request1 =
WebInspector.panel("network").requests[WebInspector.panel("network").requests.length
- 1];
Since FileReaderLoader uses DocumentThreadableLoader, a new request loading Blob
appears when loading the result of requestContent of XHR with
responseType="blob". I filed this issue here[1].

This problem also happens when WebSocket sends a Blob and FileReader reads a
Blob. So this should be fixed in the other CL.

[1]: http://crbug.com/288658

[yusukesuzuki, 2013-09-13 12:36:44]

The CL of introducing optimizing XHR blob implementation[1] will use this
implementation.
In that CL, these code are tested.

[1]: https://chromiumcodereview.appspot.com/23444058/

[vsevik, 2013-09-13 13:02:39]

not lgtm.

The correct way to load blob contents on frontend would be to introduce a new
protocol method Network.requestblobContent.
However, I am not convinced that we really need to have blob content on frontend
given complexity that is introduced by this change.
Also I would expect blob content to be binary in most cases and could not
actually be shown on frontend in a meaningful way. 
I am sorry I didn't realize that while reviewing your first patch. I don't think
this blocks http://crbug.com/269055 and you could move on with it.

https://chromiumcodereview.appspot.com/23658039/diff/14001/Source/devtools/pr...
File Source/devtools/protocol.json (right):

https://chromiumcodereview.appspot.com/23658039/diff/14001/Source/devtools/pr...
Source/devtools/protocol.json:288: "async": true,
We don't have blob resources (resources are actually documents, scripts,
stylesheets, etc. only. XHRs are not considered resources by inspector), so we
should not change page domain protocol at all.

https://chromiumcodereview.appspot.com/23658039/diff/14001/Source/devtools/pr...
Source/devtools/protocol.json:1055: "async": true,
This is a method in public protocol and clients could rely (explicitly or
implicitly) on the order of events. This method should not be made async.

[yusukesuzuki, 2013-09-13 14:04:33]

On 2013/09/13 13:02:39, vsevik wrote:
> not lgtm.
> 
> The correct way to load blob contents on frontend would be to introduce a new
> protocol method Network.requestblobContent.
> However, I am not convinced that we really need to have blob content on
frontend
> given complexity that is introduced by this change.
> Also I would expect blob content to be binary in most cases and could not
> actually be shown on frontend in a meaningful way.

Agreed.
I'm not sure the use case of XHR blob's Preview & Content view of Network Panel.
But I think it doesn't provide meaningful information.

So is it acceptable to change the result of requestContent for XHR Blob to null?

[vsevik, 2013-09-13 14:42:54]

> So is it acceptable to change the result of requestContent for XHR Blob to
null?
Yep.

[yusukesuzuki, 2013-09-13 15:29:23]

On 2013/09/13 14:42:54, vsevik wrote:
> > So is it acceptable to change the result of requestContent for XHR Blob to
> null?
> Yep.

Thanks, understood.
So I close this CL. And in the CL of optimizing XHR blob, I'll drop XHR blob
requestContent support and add tests for that.