Bug 21565

Summary: Don't depend on the suggested filename for image document titles
Product: WebKit Reporter: Brett Wilson (Google) <brettw>
Component: ImagesAssignee: Brett Wilson (Google) <brettw>
Status: RESOLVED FIXED    
Severity: Normal    
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Attachments:
Description Flags
Patch timothy: review+

Description Brett Wilson (Google) 2008-10-12 20:11:10 PDT
The title for image documents is currently computed based on the "suggested filename" of the resource response.

Apparently, the Mac networking library always gives a "suggested filename" for all loads, regardless of whether there was actually a filename header in the response (typically, there is not). This seems to fall back on using the URL.

Chromium's networking code doesn't do this, and computing a fallback suggested filename for each load would be a waste of time, since it is almost never used. The current behavior is also not that great for Safari, since the fill URL isn't always a very good title for image documents.

After chatting with andersca on #webkit, we both think the best solution is to modify ImageDocument to just use the lastPathComponent of the URL (possibly with some fallback if that's empty) instead of the suggested filename. This will work better for different platforms, and doesn't require us to compute a suggested filename for every single load. It will also give better image document titles in many cases. This is what Firefox does.

For comparison, IE seems to use the entire URL as the title. I don't think this is as good, but if we want that, a better solution is to just use the URL rather than relying on the networking library to give a suggested filename equal to the URL of the image (and have this randomly be different depending on response headers).
Comment 1 Brett Wilson (Google) 2008-10-15 14:46:45 PDT
Created attachment 24371 [details]
Patch

Use the fiename of the image URL as the title, which matches Firefox.

This uses the hostname as the fallback when there is no path component to use as the title. We can also fall back to the full URL, but that seemed like it would be longer and is not likely to contain more information.
Comment 2 Brett Wilson (Google) 2008-10-17 08:58:08 PDT
Fixed in r37655.
Comment 3 Peter Kasting 2008-11-02 20:33:43 PST
I'm not sure this was the right fix.  Chromium has issues with other cases besides image documents, such as HTML documents with no <title> and files handled by plugins.  The Chromium code is being fixed to handle all these in one change.

It may be reasonable for images to do something special anyway, e.g. "foo.gif (GIF image, 200x192)", but just setting a title to the filename seems like something the port can do automatically when the document has no title (or else that can happen somewhere less low-level than here).

Thoughts?