RESOLVED FIXED 21565
Don't depend on the suggested filename for image document titles
https://bugs.webkit.org/show_bug.cgi?id=21565
Summary Don't depend on the suggested filename for image document titles
Brett Wilson (Google)
Reported 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).
Attachments
Patch (1.65 KB, patch)
2008-10-15 14:46 PDT, Brett Wilson (Google)
timothy: review+
Brett Wilson (Google)
Comment 1 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.
Brett Wilson (Google)
Comment 2 2008-10-17 08:58:08 PDT
Fixed in r37655.
Peter Kasting
Comment 3 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?
Note You need to log in before you can comment on or make changes to this bug.