I'm sick of seeing these errors in the console: Failed to load resource: the server responded with a status of 404 (Not Found) https://something/favicon.ico Especially when the content of the page didn't request it, but the browser did. At best this could be a warning, maybe with better text? "The browser was unable to find a favicon for this site."
<rdar://problem/31620816>
Steps to Reproduce: 1. $ run-safari --no-saved-state 2. Open and inspect about:blank 3. Drag and drop a local simple.html onto Safari => Error in console about favicon.ico 404
Created attachment 307086 [details] [PATCH] Proposed Fix I still want to get rid of the file:///favicon.ico but my brain continues to think "maybe this could be legit". Maybe we should just prevent against this single file URL path, since its so unlikely to be real?
Attachment 307086 [details] did not pass style-queue: ERROR: Source/WebCore/platform/network/ResourceRequestBase.h:155: enum members should use InterCaps with an initial capital letter or initial 'k' for C-style enums. [readability/enum_casing] [4] Total errors found: 1 in 10 files If any of these errors are false positives, please file a bug against check-webkit-style.
Given that you are inspecting what the browser is doing, and it is making a request to your server, it seems like removing it altogether wouldn't be ideal (in fact, there are other requests the browser is making to your server, for other icons, that it would be nice if the inspector showed in some way).
(In reply to Sam Weinig from comment #5) > Given that you are inspecting what the browser is doing, and it is making a > request to your server, it seems like removing it altogether wouldn't be > ideal (in fact, there are other requests the browser is making to your > server, for other icons, that it would be nice if the inspector showed in > some way). Perhaps just indicating a "soft failure", would be more appropriate?
(In reply to Sam Weinig from comment #6) > Perhaps just indicating a "soft failure", would be more appropriate? This patch converted the console message from an error to a warnings. The "setHiddenFromInspector(true)" part of the patch hides the resource from the Network/Resources tab. I think its weird that it shows up there when it is not a resource requested by the page, I can add it back. I see the Web Inspector as page centric, not browser centric. You can have two separate pages being inspected, and they don't show each others traffic. That said, I would see the benefit of showing some actions the browser takes on behalf of the page. In this case if the page explicitly set a favicon path it would make sense to show details about the browser's request for the icon.
Comment on attachment 307086 [details] [PATCH] Proposed Fix Attachment 307086 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: http://webkit-queues.webkit.org/results/3536683 New failing tests: webrtc/multi-video.html
Created attachment 307178 [details] Archive of layout-test-results from ews121 for ios-simulator-wk2 The attached test failures were seen while running run-webkit-tests on the ios-sim-ews. Bot: ews121 Port: ios-simulator-wk2 Platform: Mac OS X 10.11.6
Comment on attachment 307086 [details] [PATCH] Proposed Fix This patch feels bad. We're passing a loader around that is mostly nullptr except one place. The layering feels wrong but I'm not sure how to describe what would be better. This is a very specific case we want to ignore, but we seem to be ignoring errors from ALL icon loads. Also, there are no tests.