Bug 30080 - Web Inspector: Show content for plugin requests in network panel.
Summary: Web Inspector: Show content for plugin requests in network panel.
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (Deprecated) (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Vsevolod Vlasov
URL:
Keywords:
Depends on: 63917
Blocks: 14259
  Show dependency treegraph
 
Reported: 2009-10-05 10:02 PDT by Patrick Mueller
Modified: 2011-07-05 03:17 PDT (History)
12 users (show)

See Also:


Attachments
Patch (38.72 KB, patch)
2011-06-23 06:37 PDT, Vsevolod Vlasov
no flags Details | Formatted Diff | Diff
Patch (for gtk bot) (63.12 KB, patch)
2011-06-27 14:55 PDT, Vsevolod Vlasov
no flags Details | Formatted Diff | Diff
Patch (for gtk bot) (64.32 KB, patch)
2011-06-28 03:54 PDT, Vsevolod Vlasov
no flags Details | Formatted Diff | Diff
Patch (68.36 KB, patch)
2011-06-29 05:00 PDT, Vsevolod Vlasov
no flags Details | Formatted Diff | Diff
Patch with build fixes (71.20 KB, patch)
2011-06-29 07:14 PDT, Vsevolod Vlasov
pfeldman: review+
webkit.review.bot: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Mueller 2009-10-05 10:02:26 PDT
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>
Comment 1 Patrick Mueller 2009-10-05 10:14:29 PDT
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.
Comment 2 Patrick Mueller 2009-10-06 12:53:26 PDT
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.
Comment 3 Timothy Hatcher 2009-10-06 12:56:10 PDT
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.
Comment 4 Patrick Mueller 2009-10-06 13:03:23 PDT
(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
Comment 5 Jeroen Bensch 2009-10-06 13:09:11 PDT
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.
Comment 6 Vsevolod Vlasov 2011-06-23 06:37:26 PDT
Created attachment 98342 [details]
Patch
Comment 7 Pavel Feldman 2011-06-27 02:29:14 PDT
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.
Comment 8 Vsevolod Vlasov 2011-06-27 14:55:51 PDT
Created attachment 98792 [details]
Patch (for gtk bot)
Comment 9 Gustavo Noronha (kov) 2011-06-27 17:17:19 PDT
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
Comment 10 Vsevolod Vlasov 2011-06-28 03:54:44 PDT
Created attachment 98896 [details]
Patch (for gtk bot)
Comment 11 Vsevolod Vlasov 2011-06-29 05:00:44 PDT
Created attachment 99073 [details]
Patch
Comment 12 Vsevolod Vlasov 2011-06-29 07:14:59 PDT
Created attachment 99086 [details]
Patch with build fixes
Comment 13 Pavel Feldman 2011-06-29 07:38:11 PDT
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?
Comment 14 Dimitri Glazkov (Google) 2011-07-04 11:44:31 PDT
(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.
Comment 15 WebKit Review Bot 2011-07-04 12:39:01 PDT
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
Comment 16 Vsevolod Vlasov 2011-07-04 13:08:15 PDT
Committed r90373: <http://trac.webkit.org/changeset/90373>
Comment 18 Vsevolod Vlasov 2011-07-05 03:17:03 PDT
Committed r90389: <http://trac.webkit.org/changeset/90389>