Bug 14313 - XMLHttpRequests do not show response contents, preview images
Summary: XMLHttpRequests do not show response contents, preview images
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (Deprecated) (show other bugs)
Version: 523.x (Safari 3)
Hardware: All All
: P2 Normal
Assignee: Kevin McCullough
URL:
Keywords: InRadar
: 16616 (view as bug list)
Depends on: 18451
Blocks: 17776
  Show dependency treegraph
 
Reported: 2007-06-22 12:14 PDT by Soryu Waldfee
Modified: 2008-05-21 20:37 PDT (History)
1 user (show)

See Also:


Attachments
Test cases to view XHR behavior (454.26 KB, application/octet-stream)
2008-03-21 15:45 PDT, Kevin McCullough
no flags Details
New archive with missing CSS file (454.68 KB, application/octet-stream)
2008-03-24 11:38 PDT, Kevin McCullough
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Soryu Waldfee 2007-06-22 12:14:49 PDT
XmlHttpRequests are shown in the network view of Web Inspector and Request and Response Headers are shown, too.

For each request an item is placed under the “OTHER” node but the content is not viewable when clicking that icon. Neither for things sent with application/xml nor text/html. Images are not previewed either if loaded via XHR and are placed under “OTHER” as well.
Comment 1 Timothy Hatcher 2007-12-26 23:48:08 PST
*** Bug 16616 has been marked as a duplicate of this bug. ***
Comment 2 Adam Roben (:aroben) 2008-01-29 10:56:51 PST
<rdar://problem/5712804>
Comment 3 Kevin McCullough 2008-03-21 15:45:13 PDT
Created attachment 19945 [details]
Test cases to view XHR behavior
Comment 4 Kevin McCullough 2008-03-21 15:45:44 PDT
Could you clarify what you mean by loading images via XHR?  I've attached a test case that uses XHR to load images but doesn't actually send the image via XHR except in the case of a 64bit encoded image.
Comment 5 Soryu Waldfee 2008-03-22 15:44:09 PDT
Nice test case. I don’t know whether you intentionally left out the xhrCSS.css file, though (at least it was missing for me).
It works as expected wrt images now. If you watch the Web Inspector closely you will see that the images are first appended to the OTHER node and some time later (maybe after they are fully loaded) moved to the IMAGES node. The base64 encoded image has a duplicate as xhrKevinMcCullough.txt in the OTHER view. (This might actually be desirable, if one could actually view the data, see below.)
For all other data delivered via XHR the documents (xhrCSS.css, xhrHTML.html, xhrXML.xml) show up under OTHER, regardless of Content-Type and their content cannot be inspected by clicking on them. The right hand pane stays empty.

When I created the bug, images were not moved to the IMAGES node and thus could not be viewed. The only thing left would be to show the contents of OTHER documents, at least when the Content-Type indicates them as not binary or something. XML, HTML and JSON data really should be viewable for debugging purposes.
Comment 6 Kevin McCullough 2008-03-24 11:38:49 PDT
Created attachment 20008 [details]
New archive with missing CSS file
Comment 7 Kevin McCullough 2008-03-24 11:43:12 PDT
Oops good call, I've uploaded a new test case with the CSS.  Yes, the type of the images is not determined until they are fully loaded although I haven't searched the code enough to know why.  I think it is ok for now for them to be in other until they fully load.  At least they end up in the right place after the fact.

And yes everything else ends up in other.  The reason for this is that the Inspector Controller asks for the CachedResource of each resource, but the subresource load for XHR is not cached, so there is no type information or data to display for XHR resources.

We are working on a way for the InspectorController to cache the XHR resources, but we want to be careful to not hog resources or affect the browsing experience when people don't need the Inspector.
Comment 8 Timothy Hatcher 2008-05-21 20:37:38 PDT
This can be closed now.