Bug 141389 - Web Inspector: content views for resources loaded through XHR do not reflect declared mime-type
Summary: Web Inspector: content views for resources loaded through XHR do not reflect ...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Joseph Pecoraro
URL: https://popcorn.webmaker.org/en-US/ed...
Keywords: InRadar
: 134725 165495 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-02-09 10:05 PST by Brian Burg
Modified: 2017-12-05 14:30 PST (History)
11 users (show)

See Also:


Attachments
[PATCH] Proposed Fix (70.28 KB, patch)
2017-12-04 16:06 PST, Joseph Pecoraro
bburg: review+
Details | Formatted Diff | Diff
[PATCH] For Bots (68.59 KB, patch)
2017-12-04 17:02 PST, Joseph Pecoraro
ews: commit-queue-
Details | Formatted Diff | Diff
Archive of layout-test-results from ews101 for mac-elcapitan (2.16 MB, application/zip)
2017-12-04 18:44 PST, Build Bot
no flags Details
Archive of layout-test-results from ews117 for mac-elcapitan (2.89 MB, application/zip)
2017-12-04 19:07 PST, Build Bot
no flags Details
[PATCH] For Bots (with test debugging) (68.71 KB, patch)
2017-12-04 20:19 PST, Joseph Pecoraro
ews: commit-queue-
Details | Formatted Diff | Diff
Archive of layout-test-results from ews122 for ios-simulator-wk2 (2.13 MB, application/zip)
2017-12-04 20:45 PST, Build Bot
no flags Details
Archive of layout-test-results from ews103 for mac-elcapitan (2.33 MB, application/zip)
2017-12-04 21:03 PST, Build Bot
no flags Details
Archive of layout-test-results from ews117 for mac-elcapitan (2.97 MB, application/zip)
2017-12-04 21:47 PST, Build Bot
no flags Details
[PATCH] Proposed Fix (68.53 KB, patch)
2017-12-05 12:13 PST, Joseph Pecoraro
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Brian Burg 2015-02-09 10:05:54 PST
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?)
Comment 1 Radar WebKit Bug Importer 2015-02-09 10:06:31 PST
<rdar://problem/19767070>
Comment 2 Brian Burg 2015-02-11 14:45:39 PST
*** Bug 134725 has been marked as a duplicate of this bug. ***
Comment 3 Brian Burg 2015-02-11 14:48:20 PST
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
Comment 4 Derk-Jan Hartman 2015-06-30 13:57:12 PDT
Problem still exists in Safari 9 Seed1
Comment 5 Brian Burg 2016-08-01 10:43:51 PDT
Still reproduces after other encoding issue was fixed.
Comment 6 Johan K. Jensen 2016-08-01 15:11:19 PDT
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.
Comment 7 Joseph Pecoraro 2017-11-29 13:14:34 PST
<rdar://problem/5940775>
Comment 8 Joseph Pecoraro 2017-11-29 13:30:21 PST
*** Bug 165495 has been marked as a duplicate of this bug. ***
Comment 9 Joseph Pecoraro 2017-12-04 16:06:06 PST
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 10 Brian Burg 2017-12-04 16:18:29 PST
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.

-,
Comment 11 Brian Burg 2017-12-04 16:20:58 PST
"/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)
Comment 12 Joseph Pecoraro 2017-12-04 17:02:54 PST
Created attachment 328415 [details]
[PATCH] For Bots
Comment 13 Build Bot 2017-12-04 18:44:22 PST Comment hidden (obsolete)
Comment 14 Build Bot 2017-12-04 18:44:23 PST Comment hidden (obsolete)
Comment 15 Build Bot 2017-12-04 19:07:09 PST Comment hidden (obsolete)
Comment 16 Build Bot 2017-12-04 19:07:11 PST Comment hidden (obsolete)
Comment 17 Joseph Pecoraro 2017-12-04 20:19:50 PST
Created attachment 328432 [details]
[PATCH] For Bots (with test debugging)
Comment 18 Build Bot 2017-12-04 20:45:29 PST Comment hidden (obsolete)
Comment 19 Build Bot 2017-12-04 20:45:30 PST Comment hidden (obsolete)
Comment 20 Build Bot 2017-12-04 21:03:37 PST Comment hidden (obsolete)
Comment 21 Build Bot 2017-12-04 21:03:38 PST Comment hidden (obsolete)
Comment 22 Build Bot 2017-12-04 21:47:43 PST Comment hidden (obsolete)
Comment 23 Build Bot 2017-12-04 21:47:45 PST
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
Comment 24 Joseph Pecoraro 2017-12-05 12:08:26 PST
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.
Comment 25 Joseph Pecoraro 2017-12-05 12:13:11 PST
Created attachment 328481 [details]
[PATCH] Proposed Fix
Comment 26 WebKit Commit Bot 2017-12-05 14:09:40 PST
Comment on attachment 328481 [details]
[PATCH] Proposed Fix

Clearing flags on attachment: 328481

Committed r225546: <https://trac.webkit.org/changeset/225546>