[Webkit-unassigned] [Bug 141405] Web Inspector: Large background image fails to load in inspector

[bugzilla-daemon at webkit.org]

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

Brian Burg <burg at cs.washington.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burg at cs.washington.edu

--- Comment #4 from Brian Burg <burg at cs.washington.edu> ---
(In reply to comment #3)
> We can bump it. I picked it at random. I wonder if there is a limit on URL
> size?
> 
> Using Blob and URL.createObjectURL() would be the best solution. We would
> just need to call URL.revokeObjectURL() at the right time
> (ContentView.close?). We didn't have support for Blob and createObjectURL
> when we did this 1 MiB data URL thing.

I was just looking at this code as well, since my element tracking feature sends many screenshots which can be >1MB. Simply bumping the cap will not help that much since photograph-level details can create pngs with sizes over 5 MiB. Plus there is the URL length issue, which seems like skating on thin ice and can make 2nd level inspector unusable if you happen to log the data. It would be nice to keep protocol messages to some fixed size

So, the new way would be to send over in chunks, turn that into a blob, then (optionally) turn that into an ObjectURL? It would be nice to make the protocol API agnostic to the contents of the blob. For example, some uses may already prepend the mime type, while others create it on the inspector side.

I propose altering the protocol to support multi-part messages for blob-like objects. Suppose a command exists like this:

{
    "name": "getResourceContent",
    "params": [
        {"name": "id", "type": "integer"},
        {"name": "url", "type": "string"}
    ],
    "returns" [
        {"name": "data", "type": "blob"},
        {"name": "dummyNumber", "type": "number"}
    ]
}

The protocol traffic would look like this:

<------ {"id": 33, "method": "DOM.getResourceContent", "params":{id: 42, url: "https://apple.com"}}
...
...
------> {"id": 33, "result": {"data": {"blobId": 99}, "dummyNumber": 123}, "multipart": true}
------> {"id": 33, "part": {"blobId": 99, "data": "60oeubeu0e6ueene6..."}, "multipart": true}
------> {"id": 33, "part": {"blobId": 99, "data": "92409646eeaffbbce..."}, "multipart": true}
------> {"id": 33, "part": {"blobId": 99, "data": "13941021406aef064..."}}

Multipart messages continue with the same sequence id. The "multipart":true key indicates that more chunks will be sent. When a chunk arrives without that key, a Blob object is created with the chunks, inserted into the result object, and dispatched in the frontend from InspectorBackend.

Note that this would cause the command reply to appear delayed relative to other replies whose commands were sent after getResourceContent. I don't think this is generally a problem, as the "async" command keyword can similarly delay messages and hasn't been a great source of bugs.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150210/6d3e1c6e/attachment-0002.html>