This seems kinda screwy, since data:url resources will be placed in the Font group. But if it were loaded via XHR, then it goes to the XHR group, given a blank icon and Resource Type in the sidebar reads "XHR". The fact that it came by XHR seems secondary to whether it's HTML, image, etc. (It does seem that they are properly syntax highlighted, so maybe the text editor respects mime type but content view creation doesn't?)
<rdar://problem/19767070>
*** Bug 134725 has been marked as a duplicate of this bug. ***
Another repro (copied from the bug dupe'd to this one): 1. Load http://en.wikipedia.org/wiki/Deh_Kahan 2. Click on the map to show a bigger view, which is loaded by XHR 3. Select the XHR resource in the resource sidebar panel 4. Gibberish, as what appears to be binary data is interpreted as text
Problem still exists in Safari 9 Seed1
Still reproduces after other encoding issue was fixed.
It looks like the frontend could quickly get updated to use the correct mimetype, but it doesn’t look like we get the correct data from the backend. NetworkAgent.getResponseBody (called from Resource.js) returns (a promise with) the raw image, instead of a base64 encoded blob, which is what gets shown as text. Looks like it comes from InspectorNetworkAgent::didFinishXHRLoading and NetworkResourcesData::setResourceContent, but not quite sure how far back to track it.
<rdar://problem/5940775>
*** Bug 165495 has been marked as a duplicate of this bug. ***
Created attachment 328403 [details] [PATCH] Proposed Fix I suspect there might be some fallout here from default XHR application/octet-stream (which we used to treat as Text will now treat as binary), and probably show a blank Generic View. After some testing I'll see if we should add back a fallback to treat this as text for XHR only (not for Other / Fetch). Ideally a binary / general fallback view would be best.
Comment on attachment 328403 [details] [PATCH] Proposed Fix View in context: https://bugs.webkit.org/attachment.cgi?id=328403&action=review r=me, I am so glad you finally dug into this. It's one of my biggest pet peeves. > LayoutTests/inspector/page/searchInResources.html:27 > + InspectorTest.debug(); Please remove. > Source/WebCore/inspector/agents/InspectorNetworkAgent.cpp:872 > + || MIMETypeRegistry::isSupportedNonImageMIMEType(mimeType); I'm curious what will happen with video content and video metadata. This is something we can revisit later since we do a poor job anyway and it's not a current focus. > Source/WebCore/inspector/agents/InspectorNetworkAgent.cpp:875 > +RefPtr<TextResourceDecoder> InspectorNetworkAgent::createTextDecoder(const String& mimeType, const String& textEncodingName) Nit: this should return a Ref. > Source/WebCore/inspector/agents/InspectorNetworkAgent.cpp:898 > + if (InspectorNetworkAgent::cachedResourceContent(cachedResource, &result, &base64Encoded)) { Eww, we should clean up the parameter types. Can you make this by reference? > Source/WebCore/inspector/agents/InspectorNetworkAgent.cpp:906 > +bool InspectorNetworkAgent::cachedResourceContent(CachedResource& resource, String* result, bool* base64Encoded) Ditto. Looks like there are only two use sites. > Source/WebCore/inspector/agents/InspectorPageAgent.cpp:492 > + if (auto* resource = cachedResource(frame, kurl)) { kurl 👴🏻 > Source/WebInspectorUI/ChangeLog:26 > + Better handle a no content cases. -a > Source/WebInspectorUI/ChangeLog:32 > + This is done by looking at the ResourceType, and MIME Type. -,
"/Volumes/Data/EWS/WebKit/Source/WebCore/inspector/agents/InspectorNetworkAgent.cpp:885:16: error: no viable conversion from 'WTF::Ref<WebCore::TextResourceDecoder>' to 'RefPtr<WebCore::TextResourceDecoder>' return decoder; ^~~~~~~ " Looks like you need to use this constructor: template<typename T> template<typename U> inline RefPtr<T>::RefPtr(Ref<U>&& reference)
Created attachment 328415 [details] [PATCH] For Bots
Comment on attachment 328415 [details] [PATCH] For Bots Attachment 328415 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/5495012 New failing tests: http/tests/inspector/network/xhr-response-body.html http/tests/inspector/network/fetch-response-body.html
Created attachment 328424 [details] Archive of layout-test-results from ews101 for mac-elcapitan The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews101 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Comment on attachment 328415 [details] [PATCH] For Bots Attachment 328415 [details] did not pass mac-debug-ews (mac): Output: http://webkit-queues.webkit.org/results/5495079 New failing tests: http/tests/inspector/network/xhr-response-body.html http/tests/inspector/network/fetch-response-body.html
Created attachment 328426 [details] Archive of layout-test-results from ews117 for mac-elcapitan The attached test failures were seen while running run-webkit-tests on the mac-debug-ews. Bot: ews117 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Created attachment 328432 [details] [PATCH] For Bots (with test debugging)
Comment on attachment 328415 [details] [PATCH] For Bots Attachment 328415 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: http://webkit-queues.webkit.org/results/5495689 New failing tests: loader/go-back-cached-main-resource.html
Created attachment 328434 [details] Archive of layout-test-results from ews122 for ios-simulator-wk2 The attached test failures were seen while running run-webkit-tests on the ios-sim-ews. Bot: ews122 Port: ios-simulator-wk2 Platform: Mac OS X 10.12.6
Comment on attachment 328432 [details] [PATCH] For Bots (with test debugging) Attachment 328432 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/5496147 New failing tests: http/tests/inspector/network/xhr-response-body.html http/tests/inspector/network/fetch-response-body.html
Created attachment 328435 [details] Archive of layout-test-results from ews103 for mac-elcapitan The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews103 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Comment on attachment 328432 [details] [PATCH] For Bots (with test debugging) Attachment 328432 [details] did not pass mac-debug-ews (mac): Output: http://webkit-queues.webkit.org/results/5496276 New failing tests: http/tests/inspector/network/xhr-response-body.html http/tests/inspector/network/fetch-response-body.html
Created attachment 328437 [details] Archive of layout-test-results from ews117 for mac-elcapitan The attached test failures were seen while running run-webkit-tests on the mac-debug-ews. Bot: ews117 Port: mac-elcapitan Platform: Mac OS X 10.11.6
So, this fails on WebKit1 because WebKit1 appears to allow plugins to register any mime type as a non-image mime type even if it is an image mime type. TestNetscapePlugIn (used by DumpRenderTree) registers "image/png", and WebKit adds this to the MIMETypeRegistry::getSupportedNonImageMIMETypes. Which seems completely wrong since "image/png" is an image mime type. I'm going to drop use of SupportedNonImageMIMETypes since it looks like it can't be trusted.
Created attachment 328481 [details] [PATCH] Proposed Fix
Comment on attachment 328481 [details] [PATCH] Proposed Fix Clearing flags on attachment: 328481 Committed r225546: <https://trac.webkit.org/changeset/225546>