327523 - request for Save with page title instead of filename

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: General, enhancement)

Description

[gingold]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060214 Camino/1.0
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060214 Camino/1.0

From the forums <http://forums.mozillazine.org/viewtopic.php?t=382316>:

[by88]
Hi,
One feature that Safari has, but not Camino:
When you save a page (to disk), Safari takes the <title> attribute name, which is usually pretty useful.
Whereas Camino takes the last node of the page name (path), usually not as helpful.

The problem with the last node of the page path, is that it is often just a bunch of numbers and letters, forcing me to remember what I want the page to be saved as.
Much better in Safari where it pops in the (most often) very useful page Title tag attribute.

Could Camino be adjusted to use the Title tag attribute first (if it exists), and only if that was empty to use the page name path last node?

Thx. Love the Camino.


[Uncle Asad]
Actually, we seem to use one sometimes and the other other times; it's odd. I saved a page this afternoon that came out with the page title, but trying to save a page now results in the filename. I actually prefer the latter (especially in the spirit of not changing filenames, which we've worked hard to root out), but you make a decent argument for using the title.

At the very least, it shouldn't be random which method is used. Could you please file a bug?

Reproducible: Always

Steps to Reproduce:
1. Go to a web site, for example www.nytimes.com.
2. Open any article.
3. Choose "Save" from the File menu (useless!).

Actual Results:  
Camino's suggested filename was the trailing portion of the URL (after the last slash).

Expected Results:  
Camino should have used the <title> tag, if it existed.  At the least Camino should have a preference to choose its behavior.

Comment 1

[Chris Lawson (gone)]

This is particularly bad in the case of pages being generated from CGI scripts, like bugzilla pages. Trying to save this page results in a proposed title of "show_bug.cgi.html", which is less than useful.

See also bug 312018, which is similar.

I think a lot of the filename suggestion logic is in Core, so it's possible this should be kicked over there, but I don't remember for sure.

cl

Comment 2

[Chris Lawson (gone)]

BTW, it would help a LOT if we could get some good testcases in this bug. As both Smokey and the reporter mentioned on the forum, it's sort of random and unpredictable.

cl

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

The page I tried the other day that "worked" was http://www.apple.com/itunes/1billion/entryform/

I wonder if this is somehow related to "generated" pages (bugzilla, mZ forum, etc.) and our sniffer is unable to get the <title> info from them--or, conversely, that some of them are sending a content-type header with a filename, and we're preferring that?

Comment 4

[philippe (part-time)]

If the url contains a query string (like here on bugzilla: show_bug.cgi?id=327523, or on many forums: xxx.php?f=xxx) then Gecko doesn't fetch the page title. That happens consistently on my side

It is a core issue, btw, the problem happens on both Firefox and Camino, trunk and release builds; it also happens with the older Firefox 1.07.

Comment 5

[gingold]

It's much much simpler; it has only to do with whether there is a trailing slash in the URL.

For example, saving the page
    <http://www.google.com/>           suggests the filename "Google.html"
while
    <http://www.google.com/index.html> suggests the filename "index.html"
.

This behavior is reproducible on every site I visit.

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Indeed, comment 5 seems to be the case; we prefer the actual filename whenever we have it.  

I think this is the proper thing to do (it's bad to go around changing filenames of things we save), but I can certainly see the argument for an option to use the title instead when we can get it.

Comment 7

[Chris Lawson (gone)]

Yep, this is a dupe of bug 173983, which, for the record, I *also* believe was incorrectly duped itself.

cl

*** This bug has been marked as a duplicate of 173983 ***

Comment 8

[Chris Lawson (gone)]

To save people the trouble, I'm reopening this to dupe it to a more appropriate bug: bug 173982.

Comment 9

[Chris Lawson (gone)]

*** This bug has been marked as a duplicate of 173982 ***

Comment 10

[Simon Fraser [no longer active]]

Bug 173982 is about adding UI to let the user pick the filename, page title or whatever. Doesn't smell like this bug.

Comment 11

[Chris Lawson (gone)]

(In reply to comment #10)
> Bug 173982 is about adding UI to let the user pick the filename, page title or
> whatever.

Seems to me like that's exactly what the reporter asked for.

Reporter, is that OK by you?

cl

Comment 12

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Well, bug 173982 is about adding UI, but I understood from bz's comments that some Core changes would be needed to supply the info that the UI/saving would need.  Maybe that's not the case, not the case any more, or not the case in Camino?

Come to think of it, since we use the title for print jobs and PDFs (most of the time, at least), it must be stored somewhere we have access to it already.  So that sounds like we could conceivably provide these options without any Core changes; just change the Camino save dialogue UI like we did for bug 259903, or some other gross hack?

Comment 13

[gingold]

The Core bug is indeed exactly the same, but I don't see why Camino's UI decision should be tied to a Core UI decision.  Camino makes many independent UI decisions, and this doesn't require a Core change; Camino already has access to the title tag.  It's displayed in the "Page Info" window (accessible via "Get Info" in the "Edit" menu).

Comment 16

[Angel Blue]

This appears to be a duplicate of this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=254139

Comment 17

[philippe (part-time)]

(In reply to comment #16)
> This appears to be a duplicate of this bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=254139
Nope, this is a Camino specific bug.

Comment 18

[Chris Lawson (gone)]

Straight out of SaveHeaderSniffer.mm, here's our priority:

(1) Use the HTTP header suggestion [from the content-disposition header, if present].
(2) For file:/// URLs, use the filename.
(3) Use the title of the document.
(4) Use the caller-provided name.
(5) Use the host.
(6) If none of the above exist, use "untitled".

IMO, our Save dialog box (and save code in general) is complicated enough without having to worry about giving users the option to choose the relative priority of <title> versus <filename>.

While I sympathise with the idea of not renaming files when we have that information, I think the overarching principle of "providing the best possible experience for Mac OS X users" dictates that we follow Safari's lead and default to using page title here. Users like my mom and Pink's fiancee don't care about "index.html"; they want to call the file "Google" since that's what it is.

Note that Safari doesn't bother suggesting a different filename if you choose the "Page Source" option; we might consider changing the suggested filename based on the format being chosen. Users who save as "HTML Complete" or "Plain Text" probably won't find existing filenames to be too terribly useful, but users who are saving as "HTML Source Only" might find the filename helpful.

Discuss.