Bug 5029 – Assertion failure in -[NSPasteboard(WebExtras) _web_writeImage:URL:title:archive:types:] when trying to drag an image from a site with no favicon

• Component: WebKit Misc.
• Status: VERIFIED FIXED

Development build of WebKit crashes with the message
ASSERTION FAILED: [[[WebImageRendererFactory sharedFactory] supportedMIMETypes] containsObject:
[resource MIMEType]] (WebKit/Misc.subproj/WebNSPasteboardExtras.m:245 -[NSPasteboard(WebExtras) 
_web_writeImage:URL:title:archive:types:])
when opening the image in the URL in Safari and then trying to drag it out of the window.

This happens whenever the site hosting the image has sent text/html content (e.g. a 404 page) as its /
favicon.ico.

[Alexey Proskuryakov]

I cannot reproduce the assertion with ToT.

However, I have seen this assertion previously with a site that used 302 Found redirection and lied about 
content type. Perhaps, one needs to navigate to this picture through the site in order to reproduce the 
problem?

(In reply to comment #1)
> Perhaps, one needs to navigate to this picture through the site in order to reproduce the 
> problem?

My experience is that you can go straight to the picture as well. You should not drag immediately, though, 
but rather wait a couple of seconds to let WebKit fetch the favicon (you can use tcpdump or something to 
see when it's done so).

It's not just the assert that fails, you end up with the wrong resource if you're dragging into a TextEdit 
document. Instead of the image, you get a Safari HTML file icon.
The root cause is that the favicon is added as a subresource to the image if it happens not to be loaded by 
the image (i.e. if it is not already in the cache), so the situation with valid favicons is no different. Even 
though the assertion doesn't fail, if you drag such an image from Safari into a TextEdit document, you end 
up with the favicon instead of the image.

s/happens not/happens

Created attachment 4324 [details]
Prefer the main resource if it is an image

This is an ugly fix that doesn't address the root cause, which is that the icon
loader adds the favicon as a subresource. However, I see no easy way to change
that behavior or to reject it in addSubResource.

[Maciej Stachowiak]

Comment on attachment 4324 [details]
Prefer the main resource if it is an image

r=me

[Vicki Murley]

I committed this change.