Bug 30080 – Web Inspector: Show content for plugin requests in network panel.

• Component: Web Inspector (Deprecated)
• Status: RESOLVED FIXED

[Patrick Mueller]

In the Resources panel, the resource data (HTTP response data) is not always displayed.

See Bug 28812, comment 6.

A case where this occurs is when loading the URL:

   http://www.lumacentral.com/CocaCola/index.html

One of the resources, named "execBatch" has an HTTP response which is not displayed.  Here is a replay of the individual resource request in curl.  As you can see, there actually is some content coming from the request.

$ curl -H "Content-Type: application/xml" -d "<lw2p-requests><lw2p-request
action='getCurrentPortal'/></lw2p-requests>" -v
http://www.lumacentral.com/CocaCola/w2p/execBatch
- About to connect() to www.lumacentral.com port 80 (#0)
-   Trying 194.78.34.228... connected
- Connected to www.lumacentral.com (194.78.34.228) port 80 (#0)
> POST /CocaCola/w2p/execBatch HTTP/1.1
> User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
> Host: www.lumacentral.com
> Accept: */*
> Content-Type: application/xml
> Content-Length: 72
> 
< HTTP/1.1 200 OK
< Date: Mon, 05 Oct 2009 15:36:37 GMT
< Cache-Control: no-cache
< Set-Cookie: JSESSIONID=49ACA557EE891188BDB2B334CF2B4B7E; Path=/CocaCola
< mime-type: application/xml
< Transfer-Encoding: chunked
< Content-Type: text/plain
< 
<?xml version="1.0" encoding="UTF-8"?>
- Connection #0 to host www.lumacentral.com left intact
- Closing connection #0
<lw2p-replies><lw2p-reply action="getCurrentPortal"><portal description=""
id="52" name="CocaCola" version="10"/></lw2p-reply></lw2p-replies>

[Patrick Mueller]

Note that Bug 30079 concerns the same base URL for it's problem.   In talking to Jeroen Bensch, the originator of the problem requests, seems like 30079 may be a root cause here.  May want to investigate that one first.

[Patrick Mueller]

Jeroen, I'm wondering if those execBatch XHR calls are happening in the .swf movie itself.  I poked around the resources available from the original site, and didn't see any references to the execBatch urls.

This may explain why the resource content doesn't show up - there is a separate path to obtain the resource than other paths the browser goes through to get files.  Not that it's necessarily right, but it would explain a bit.

In fact, I just poked on the resource selectors, and noticed these execBatch URLs are showing up under "Other".  As is the .swf file itself, presumably loaded through an "embed" or "object" element (or whatever).

It's interesting that everything seems to be available for these resources, except the actual content.  Maybe it won't take much to hook that up.  Will need to investigate the plugin goop, I guess.

[Timothy Hatcher]

The Web Inspector does not know how to render "Other" content right now. We might have the data, but we don't attempt to show it.

We need to know what type of data to pick the view that shows it. We try to do this based on the category the engine tells us, images, etc. I think we also look at mime type.

[Patrick Mueller]

(In reply to comment #3)
> The Web Inspector does not know how to render "Other" content right now. We
> might have the data, but we don't attempt to show it.
> 
> We need to know what type of data to pick the view that shows it. We try to do
> this based on the category the engine tells us, images, etc. I think we also
> look at mime type.

(In reply to comment #3)
> The Web Inspector does not know how to render "Other" content right now. We
> might have the data, but we don't attempt to show it.
> 
> We need to know what type of data to pick the view that shows it. We try to do
> this based on the category the engine tells us, images, etc. I think we also
> look at mime type.

Sounds like we can DUP this for the existing Bug 14259

[Jeroen Bensch]

I'm following your reasoning and discussion here, but I don't know how I could help.

Thanks though for looking into it. I thought the reason why it wasn't shown is that because everything in that .swf file comes back as xml (with appropriate header) and you just discarded that when trying to show the response payload.

[Vsevolod Vlasov]

Created attachment 98342 [details]
Patch

[Pavel Feldman]

Comment on attachment 98342 [details]
Patch

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

> Source/WebCore/inspector/NetworkResourcesData.cpp:182
> +        m_contentSize -= resourceData->purgeContent();

This is clearly worth a test.

> Source/WebCore/inspector/NetworkResourcesData.h:68
> +        bool hasData() const { return m_dataBuffer; }

Make these private + a friend of the NetworkResourceData.

[Vsevolod Vlasov]

Created attachment 98792 [details]
Patch (for gtk bot)

[Gustavo Noronha (kov)]

Comment on attachment 98792 [details]
Patch (for gtk bot)

Attachment 98792 [details] did not pass gtk-ews (gtk):
Output: http://queues.webkit.org/results/8952335

[Vsevolod Vlasov]

Created attachment 98896 [details]
Patch (for gtk bot)

[Vsevolod Vlasov]

Created attachment 99073 [details]
Patch

[Vsevolod Vlasov]

Created attachment 99086 [details]
Patch with build fixes

[Pavel Feldman]

Comment on attachment 99086 [details]
Patch with build fixes

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

> Source/WebCore/WebCore.exp.in:1303
> +__ZNK7WebCore8Document4pageEv

@dglazkov: are we exporting webcore symbols both for webkit and for internals using the same file on mac?

[Dimitri Glazkov (Google)]

(In reply to comment #13)
> (From update of attachment 99086 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=99086&action=review
> 
> > Source/WebCore/WebCore.exp.in:1303
> > +__ZNK7WebCore8Document4pageEv
> 
> @dglazkov: are we exporting webcore symbols both for webkit and for internals using the same file on mac?

Yep.

[WebKit Review Bot]

Comment on attachment 99086 [details]
Patch with build fixes

Rejecting attachment 99086 [details] from commit-queue.

Failed to run "['./Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '--bot-id=ec2-cq-02', '--port..." exit_code: 2

Last 500 characters of output:
re/loader/FormState.o
Source/WebCore/loader/DocumentThreadableLoader.cpp: In member function 'virtual void WebCore::DocumentThreadableLoader::didReceiveData(WebCore::SubresourceLoader*, const char*, int)':
Source/WebCore/loader/DocumentThreadableLoader.cpp:232: error: 'didReceiveContentLength' is not a member of 'WebCore::InspectorInstrumentation'
make: *** [out/Debug/obj.target/webcore_remaining/Source/WebCore/loader/DocumentThreadableLoader.o] Error 1
make: *** Waiting for unfinished jobs....

Full output: http://queues.webkit.org/results/8982506

[Vsevolod Vlasov]

Committed r90373: <http://trac.webkit.org/changeset/90373>

[Vsevolod Vlasov]

Rolled out:

http://trac.webkit.org/changeset/90373
https://bugs.webkit.org/show_bug.cgi?id=63917

[Vsevolod Vlasov]

Committed r90389: <http://trac.webkit.org/changeset/90389>