21565 2008-10-12 20:11:10 -0700 Don't depend on the suggested filename for image document titles 2008-11-02 20:33:43 -0800 1 1 1 Unclassified WebKit Images 528+ (Nightly build) All All RESOLVED FIXED P2 Normal --- 1 brettw brettw oldest_to_newest 95146 0 brettw 2008-10-12 20:11:10 -0700 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). 95451 1 24371 brettw 2008-10-15 14:46:45 -0700 Created attachment 24371 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. 95735 2 brettw 2008-10-17 08:58:08 -0700 Fixed in r37655. 97442 3 pkasting 2008-11-02 20:33:43 -0800 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? 24371 2008-10-15 14:46:45 -0700 2008-10-17 04:32:57 -0700 Patch image_title.diff text/plain 1694 brettw SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n CShyZXZpc2lvbiAzNzYxNSkKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA IC0xLDMgKzEsMTUgQEAKKzIwMDgtMTAtMTUgIEJyZXR0IFdpbHNvbiAgPGJyZXR0d0BjaHJvbWl1 bS5vcmc+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAg SGF2ZSBJbWFnZURvY3VtZW50IGdlbmVyYXRlIGl0cyBvd24gZmlsZW5hbWUgZm9yIHRoZSB0aXRs ZSBvZiBpbWFnZXMKKyAgICAgICAgd2l0aG91dCByZWx5aW5nIG9uIHRoZSBzdWdnZXN0ZWQgZmls ZW5hbWUgZnJvbSB0aGUgbmV0d29yayBsYXllciwgd2hpY2gKKyAgICAgICAgbWF5IGJlIG5vbmV4 aXN0YW50IG9yIG5vdCByZWxldmFudC4KKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcv c2hvd19idWcuY2dpP2lkPTIxNTY1CisKKyAgICAgICAgKiBsb2FkZXIvSW1hZ2VEb2N1bWVudC5j cHA6CisgICAgICAgIChXZWJDb3JlOjpJbWFnZVRva2VuaXplcjo6ZmluaXNoKToKKwogMjAwOC0x MC0xNSAgUGV0ZXIgS2FzdGluZyAgPHBrYXN0aW5nQGdvb2dsZS5jb20+CiAKICAgICAgICAgUmV2 aWV3ZWQgYnkgRGF2aWQgSHlhdHQuCkluZGV4OiBXZWJDb3JlL2xvYWRlci9JbWFnZURvY3VtZW50 LmNwcAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Ci0tLSBXZWJDb3JlL2xvYWRlci9JbWFnZURvY3VtZW50LmNwcAkocmV2 aXNpb24gMzc2MTUpCisrKyBXZWJDb3JlL2xvYWRlci9JbWFnZURvY3VtZW50LmNwcAkod29ya2lu ZyBjb3B5KQpAQCAtMTIwLDggKzEyMCwxNCBAQCB2b2lkIEltYWdlVG9rZW5pemVyOjpmaW5pc2go KQogICAgICAgICBjYWNoZWRJbWFnZS0+c2V0UmVzcG9uc2UobV9kb2MtPmZyYW1lKCktPmxvYWRl cigpLT5kb2N1bWVudExvYWRlcigpLT5yZXNwb25zZSgpKTsKIAogICAgICAgICBJbnRTaXplIHNp emUgPSBjYWNoZWRJbWFnZS0+aW1hZ2VTaXplKG1fZG9jLT5mcmFtZSgpLT5wYWdlWm9vbUZhY3Rv cigpKTsKLSAgICAgICAgaWYgKHNpemUud2lkdGgoKSkKLSAgICAgICAgICAgIG1fZG9jLT5zZXRU aXRsZShpbWFnZVRpdGxlKGNhY2hlZEltYWdlLT5yZXNwb25zZSgpLnN1Z2dlc3RlZEZpbGVuYW1l KCksIHNpemUpKTsKKyAgICAgICAgaWYgKHNpemUud2lkdGgoKSkgeworICAgICAgICAgICAgLy8g Q29tcHV0ZSB0aGUgdGl0bGUsIHdlIHVzZSB0aGUgZmlsZW5hbWUgb2YgdGhlIHJlc291cmNlLCBm YWxsaW5nCisgICAgICAgICAgICAvLyBiYWNrIG9uIHRoZSBob3N0bmFtZSBpZiB0aGVyZSBpcyBu byBwYXRoLgorICAgICAgICAgICAgU3RyaW5nIGZpbGVOYW1lID0gbV9kb2MtPnVybCgpLmxhc3RQ YXRoQ29tcG9uZW50KCk7CisgICAgICAgICAgICBpZiAoZmlsZU5hbWUuaXNFbXB0eSgpKQorICAg ICAgICAgICAgICAgIGZpbGVOYW1lID0gbV9kb2MtPnVybCgpLmhvc3QoKTsKKyAgICAgICAgICAg IG1fZG9jLT5zZXRUaXRsZShpbWFnZVRpdGxlKGZpbGVOYW1lLCBzaXplKSk7CisgICAgICAgIH0K IAogICAgICAgICBtX2RvYy0+aW1hZ2VDaGFuZ2VkKCk7CiAgICAgfQo=