Summary: | Web Inspector: Show content for plugin requests in network panel. | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Patrick Mueller <pmuellr> | ||||||||||||
Component: | Web Inspector (Deprecated) | Assignee: | Vsevolod Vlasov <vsevik> | ||||||||||||
Status: | RESOLVED FIXED | ||||||||||||||
Severity: | Normal | CC: | apavlov, aroben, caseq, dglazkov, gustavo, jeroen.bensch, kmccullough, pfeldman, vsevik, webkit.review.bot, xan.lopez, yurys | ||||||||||||
Priority: | P2 | ||||||||||||||
Version: | 528+ (Nightly build) | ||||||||||||||
Hardware: | All | ||||||||||||||
OS: | All | ||||||||||||||
Bug Depends on: | 63917 | ||||||||||||||
Bug Blocks: | 14259 | ||||||||||||||
Attachments: |
|
Description
Patrick Mueller
2009-10-05 10:02:26 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. 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. 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. (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 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. Created attachment 98342 [details]
Patch
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. Created attachment 98792 [details]
Patch (for gtk bot)
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 Created attachment 98896 [details]
Patch (for gtk bot)
Created attachment 99073 [details]
Patch
Created attachment 99086 [details]
Patch with build fixes
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? (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 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 Committed r90373: <http://trac.webkit.org/changeset/90373> Committed r90389: <http://trac.webkit.org/changeset/90389> |