254139 - File | Save Page As should default to <title>, not filename

Status: VERIFIED FIXED

(Firefox :: File Handling, enhancement, P3)

Description

[Haymo Schöner]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2

Hi
when I save a HTML page of the New York Times Windows Explorer gives me as
default a  name saying the headline of the article while firefox comes with a
not significant name. This is quite annoying as I save the pages I want  to read
on my PDA in the tube and want to know which file to open. But the browser does
a great job. :-)

good luck
Haymo
 

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1

[OstGote!]

Dupe of bug 205458 IMO. See bug 115176 too. 

Comment 2

[Peter van der Woude [:Peter6]]

WFM

I can't check for the NYT(login required) but any other page comes up fine.
Providing the title attribue is properly set.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040803
Firefox/0.9.1+

Comment 3

[Ali Ebrahim]

Relevant code is here:
http://lxr.mozilla.org/seamonkey/source/browser/base/content/contentAreaUtils.js#727

I think this makes good to use <title> instead of the document filename
(foo.html or show_bug.cgi). It's far less confusing for people who want to save
things.

Comment 4

[Ali Ebrahim]

Current behaviour is to use the <title> when there is no filename, for example
at http://www.nytimes.com/ (there is no filename), and to use the filename when
present.

Comment 5

[Ali Ebrahim]

Everyone should read bug 115176 before commenting here.

To be clear, what I'd like to see changed is *only* the behaviour for File |
Save Page As. We should *not* be doing anything different for clicking on links,
or for right-click Save Link As.

Comment 6

[:Gavin Sharp [email: [e-mail]]]

See also bug 173982.

Comment 7

[william.allen.simpson]

same or similar problem in MacOS X.  Should be confirmed and cross platform. 

yes, I read both bug 115176 and bug 173982.

Comment 8

[gw333]

Please hurry up and fix this - it is a pain the way it works currently.  You try
doing research on the net and having to save every 2nd page as index.html or
some other non-sensical/unmeaningfull name.

Please change the Severity to 'blocker' and the Priority to the highest, as this
is preventing me from changing over to Firefox and I'm sure there are many other
people in the same boat.

Did I ask if you would hurry up and fix it?

Comment 9

[WADA:World Anti-bad-Duping Agency]

I've found bug 173982, which was opened almost two years ago of this bug open.
> Bug 173982 : Allow different default file names when saving
I put it in dependency tree of this bug.

By the way, Product=Core/Component="File Handling" is appropriate for this bug
as bug 173982 is so, I think, because "default file name when save" is common
issue among Mozilla Suite, Firefox and Thunderbird,  

Comment 10

[Jo Hermans]

*** Bug 275303 has been marked as a duplicate of this bug. ***

Comment 11

[unda_dogg]

(In reply to comment #10)
> *** Bug 275303 has been marked as a duplicate of this bug. ***

it is not really.  I am asking to save as the number, they are asking for the
name.  i was thinking to modify the save as box, but that is prolly beyond the
scope/intent of the products??

Comment 12

[Phil Ringnalda (:philor)]

*** Bug 275901 has been marked as a duplicate of this bug. ***

Comment 13

[conversecorollary]

(In reply to comment #12)
> *** Bug 275901 has been marked as a duplicate of this bug. ***

In either case is this "bug" going to be fixed? If so ETA? Thanks.

Comment 14

[Pavel Cvrcek [:JasnaPaka]]

I modified extension File Title which i found on MozillaZine. 

http://www.jasnapaka.com/download/mozilla/filetitle/file_title-0.2-fx.xpi

This extension "fixed" this bug but i think that better solution is to create a
patch for all users (if developers agree with this change).

My solution:
- save document according to filename but there is one exception. When document
is "text/html" extension saves this document according to <title>.

Comment 15

[conversecorollary]

(In reply to comment #14)
> I modified extension File Title which i found on MozillaZine. 
> 
> http://www.jasnapaka.com/download/mozilla/filetitle/file_title-0.2-fx.xpi
> 
> This extension "fixed" this bug but i think that better solution is to create a
> patch for all users (if developers agree with this change).
> 
> My solution:
> - save document according to filename but there is one exception. When document
> is "text/html" extension saves this document according to <title>.

(In reply to comment #14)
> I modified extension File Title which i found on MozillaZine. 
> 
> http://www.jasnapaka.com/download/mozilla/filetitle/file_title-0.2-fx.xpi
> 
> This extension "fixed" this bug but i think that better solution is to create a
> patch for all users (if developers agree with this change).
> 
> My solution:
> - save document according to filename but there is one exception. When document
> is "text/html" extension saves this document according to <title>.

Pavel,

Is this extension available for installation? If so, how do I install this
extension?

Thanks!

Comment 16

[Pavel Cvrcek [:JasnaPaka]]

(In reply to comment #15)
> Is this extension available for installation? If so, how do I install this
> extension?

Yes, it is but download new version please (same URL). There was a small bug in
last version. You can install this extension like the other extensions (File ->
Open...).

Comment 17

[Kevin Brosnan]

*** Bug 288107 has been marked as a duplicate of this bug. ***

Comment 18

[Charles Evans]

This is a major, continual nuisance. 
(Enhancement does not come close to being an appropriate category.
 Please add a category between normal bug and minor bug called major nuisance. 
 Thanks)
Ideally, one could choose filename or title by one click.
(A thousand thanks to all the active maintainers!)

Comment 19

[Dave Townsend [:mossop]]

*** Bug 321992 has been marked as a duplicate of this bug. ***

Comment 20

[u197037]

One more comment:

In order to properly handle filenames (expected behaviour) in "Save Link As..." IMHO firefox MUST honour "filename" parameter in HTTP header. If it IS set, that's should be default. Not the basename of URL.

Currently, there is an inconsistency: if you just left-click on an URL to say "application/x-zip-compressed" file, "filename" parameter is handled properly. But if you try to "Save Link As..." - URL basename() is proposed.

This thing is especialy annoing for "text/plain" files (sources, diffs, etc), which are just viewed in browser on left-click.

Comment 21

[u197037]

Hmm... Looks like a regression from Mozilla at least. So, it's not an enhancement. It's a bug.
See https://bugzilla.mozilla.org/show_bug.cgi?id=323888

(In reply to comment #20)
> One more comment:
> 
> In order to properly handle filenames (expected behaviour) in "Save Link As..."
> IMHO firefox MUST honour "filename" parameter in HTTP header. If it IS set,
> that's should be default. Not the basename of URL.
> 
> Currently, there is an inconsistency: if you just left-click on an URL to say
> "application/x-zip-compressed" file, "filename" parameter is handled properly.
> But if you try to "Save Link As..." - URL basename() is proposed.
> 
> This thing is especialy annoing for "text/plain" files (sources, diffs, etc),
> which are just viewed in browser on left-click.
> 

Comment 22

[Phil Ringnalda (:philor)]

*** Bug 333872 has been marked as a duplicate of this bug. ***

Comment 23

[BoffinBrain]

Does this bug depend on bug #299372, or the other way round?

Comment 25

[Peter Lairo]

I *almost* convinced someone to use Firefox yesterday (instead of IE). He frequently saves recipes from http://www.verybestbaking.com to his hard drive. There are two things he does in IE that Firefox still cannot:

1. Save a complete web page as *one* file (MHTML). Yes, PDF is an *almost* as good workaround. (bug 40873)

And the more important problem:

2. In Firefox, the "Save Page As" dialog doesn't always auto-suggest the "title" of the page as the default filename on this web site's recipe pages (e.g., http://www.verybestbaking.com/recipes/detail.aspx?ID=18476 - it yields "detail.aspx.htm"). Having to type-in the (often lengthy) filename (while IE does this correctly) is a *dealbreaker*.

"Enhancement" is OK, but how about a (much) higher "Priority"?

Comment 26

[Ivan Ičin]

It is much more elegant to store files with Scrapbook extension than any other way, so I am unvoting this bug.

Personally, I can't find any value in making this fixed. On the other hand, some rudimentary scrapbook built into Firefox would be interesting.

Comment 27

[Peter Lairo]

(In reply to comment #25)
> 2. In Firefox, the "Save Page As" dialog doesn't always auto-suggest the
> "title" of the page as the default filename on this web site's recipe pages
> (e.g., http://www.verybestbaking.com/recipes/detail.aspx?ID=18476 - it yields
> "detail.aspx.htm"). Having to type-in the (often lengthy) filename (while IE
> does this correctly) is a *dealbreaker*.

This add-on fixes this bug: https://addons.mozilla.org/en-US/firefox/addon/834

Please see is the code can be used in the default Firefox builds. Thanks.

Comment 28

[Thomas Bertels]

Attachment: Use the page title if available, and the file name if not

Pretty easy, nothing added, nothing removed, just code blocks swap.

The current way it works is :
1. Look content-disposition header
2. Use the actual file name
3. Use the document title
(...)

This patch changes it to :
1. Look content-disposition header
2. Use the document title
3. Use the actual file name
(...)

Comment 29

[Peter Lairo]

(In reply to comment #28)
> This patch changes it to :
> 1. Look content-disposition header
> 2. Use the document title
> 3. Use the actual file name

Sounds great! But does this use the title when there is an actual file to be downloaded? (PDF, ZIP, ...) 

I'm sure users would prefer downloading a file called "Firefox.exe" instead of "Mozilla Firefox - Select your Download Language.exe"

Comment 30

[Thomas Bertels]

(In reply to comment #29)
> Sounds great! But does this use the title when there is an actual file to be
> downloaded? (PDF, ZIP, ...) 
> 
> I'm sure users would prefer downloading a file called "Firefox.exe" instead of
> "Mozilla Firefox - Select your Download Language.exe"

No, the title is only used when we save a page.
The "Mozilla Firefox - Select your Download Language.exe" kind of title is only #4, when there is no file name.

Comment 31

[Pavel Cvrcek [:JasnaPaka]]

(In reply to comment #30)
> No, the title is only used when we save a page.
> The "Mozilla Firefox - Select your Download Language.exe" kind of title is only
> #4, when there is no file name.

I don't think. When you try to save URL http://www.mozilla.com/img/firefox-title.png, you get filename "firefox-title.png (PNG image, 252x52 pixels).png" with your patch. That's a reason why I test MIME type of saved page in my extension (File Title).

Did you try your patch if works correctly?

Comment 32

[Thomas Bertels]

Attachment: Use the page title if available, and the file name if not (2)

I did test it, but not as thoroughly as you did for your extension. I actually forgot images were being given a custom title.
So this patch checks if the MIME type is text/html, just like your extension.

Comment 33

[BoffinBrain]

text/html isn't the only doctype that has a custom title.  Consider checking for indexOf("html") instead, or something similar.

Comment 34

[Thomas Bertels]

Comment on attachment 324273 [details] [diff] [review]
Use the page title if available, and the file name if not (2)

From http://www.w3.org/TR/xhtml-media-types/, it seems that xml should also be looked for.
This will include RSS and Atom feeds, but is it a bad thing ?

Comment 35

[BoffinBrain]

I would imagine very few people would be downloading RSS for keeps anyway, due to their live nature.  Still, I don't see any reason why not.

Another thought: Could we simply parse the document tree if there is one, and look for a <title> tag, or is it too early (in the case of Save Link As)?

Comment 36

[BoffinBrain]

Attachment: Use the page title if available, and the file name if not (3)

Same as before, but regex on XML or HTML.

Comment 37

[Thomas Bertels]

I think you can ask for a review, I don't see what more can be done at this point.

Comment 38

[Jabe]

It would be great to add this feature to next Firefox update, I'm using File Title extension https://addons.mozilla.org/en-US/firefox/addon/834 since Firefox 1.5 and I thought it will be fixed on Firefox 3, it appears that it doesn't :-(
JasnaPaka's extension works very will why not simply including it?

Comment 39

[Mike Connor [:mconnor]]

Nice to have,not a blocker.

Comment 40

[liuqiang]

My god, this bug has exist more than four years!
It is so bad!
Please kindly fix this!

Comment 41

[:Gavin Sharp [email: [e-mail]]]

This was hotly debated in bug 115176 and bug 205458. It's not clear to me what the best way forward here is.

The patch is fine technically, but we need to make sure we're prepared to make this change, and that it's best for most users. One way to do that might be to start a thread about this on the mozilla.dev.apps.firefox newsgroup/mailing list.

Comment 42

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 324353 [details] [diff] [review]
Use the page title if available, and the file name if not (3)

I'd be happy to review this patch once it gets ui-review.

Comment 43

[Mike Connor [:mconnor]]

Definitely too late for 3.5.

Comment 44

[CJ de Bruyn]

Attachment: This is a fix to the required Save Page As

Comment 45

[Jabe]

(In reply to comment #44)
> Created an attachment (id=393003) [details]
> This is a fix to the required Save Page As

I hope your fix will be part of 3.5.3, it's just a few lines to add to the code and I'm waiting for this fix to be official for years.
It'm still using File Title extension for now :(

Comment 46

[Pavel Cvrcek [:JasnaPaka]]

(In reply to comment #41)
> The patch is fine technically, but we need to make sure we're prepared to make
> this change, and that it's best for most users. One way to do that might be to
> start a thread about this on the mozilla.dev.apps.firefox newsgroup/mailing
> list.

Thread started but with no response.
http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/194150411f0e5728/acddde799a5090d4?lnk=gst&q=cvrcek#acddde799a5090d4

Comment 47

[Angel Blue]

This appears to have been fixed in the latest nightlys

Comment 48

[Mike]

(In reply to comment #47)
No. Mozilla/5.0 (X11; ; Linux i686; rv:1.9.3a4pre) Gecko/20100403 Minefield/3.7a4pre still have this bug.

Comment 49

[Chris Peterson [:cpeterson]]

Attachment: save-page-as-document-title.patch

This is an ancient bug with many votes and dupes. Chrome, Safari, and IE all save pages using the document title. Firefox is the outlier, wanting to save with unhelpful filenames like "index.html".

This patch simply reorders the places "Save Page As" looks for a reasonable default filename.

Without this patch, "Save Page As" would give this bug page the default filename "show_bug.cgi.html". With this patch, the default filename would be "254139 – File | Save Page As should default to <title>, not filename.html".

Comment 50

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 648640 [details] [diff] [review]
save-page-as-document-title.patch

>diff --git a/toolkit/content/contentAreaUtils.js b/toolkit/content/contentAreaUtils.js

>+    var docTitle = validateFileName(aDocument.title).replace(/^\s+|\s+$/g, "");

This can just be validateFileName(aDocument.title).trim() now.

Comment 51

[Pavel Cvrcek [:JasnaPaka]]

(In reply to Chris Peterson (:cpeterson) from comment #49)
> This patch simply reorders the places "Save Page As" looks for a reasonable
> default filename.
> 
> Without this patch, "Save Page As" would give this bug page the default
> filename "show_bug.cgi.html". With this patch, the default filename would be
> "254139 – File | Save Page As should default to <title>, not filename.html".

I'm not sure about your patch. I didn't test your patch but I think this behavior should be limited to HTML pages. How it works when just image is opened?

Comment 52

[Chris Peterson [:cpeterson]]

(In reply to Pavel Cvrcek (Mozilla.cz) [:JasnaPaka] from comment #51)
> I'm not sure about your patch. I didn't test your patch but I think this
> behavior should be limited to HTML pages. How it works when just image is
> opened?

Pavel, you are correct. My patch is broken for image saving images. As it is, my patch would save an "example.jpg" image document as "example.jpg (JPEG Image, 100x100 pixels).jpg".

A little less clear is how to handle non-HTML documents like RSS XML.

For example, Netflix's "Top 100" RSS feed [1] has a <title> tag, so my patch saves the file as "Netflix Top 100.xhtml", not "Top100RSS.xhtml" (Firefox's current behavior). Which filename is more appropriate? I'm not sure, but I think "Netflix Top 100.xhtml" is because the document declared its <title>. I can't compare Chrome's and Safari's behavior because they insist on opening Netflix's feed in an external RSS reader.

Another example is Dave Winer's Scripting News RSS feed [2]. This feed has a "<title>Dave Winer</title>" tag, so my patch saves the file as "Dave Winer.xhtml". Safari insists on opening an external RSS reader, but Chrome does not recognize this feed as RSS and displays the feed as XML. Chrome will then save the document as "rss.xml".

[1] http://dvd.netflix.com/Top100RSS
[2] http://static.scripting.com/rss.xml

Comment 53

[Chris Peterson [:cpeterson]]

Attachment: save-document-title-v2.patch

Patch v2 addresses the image file bug that Pavel pointed out.

If the document's Content-Type looks like a HTML or XML, then I try to use the document's original title. This avoids the problem where an image document is saved using the window's title (such as "example.jpg (JPEG Image, 100x100 pixels).jpg"). I have tested saving HTML, XHTML, .xml, and .svg files (all with and without a <title> tag).

Is there a better method to check whether a document is HTML or XML? Sniffing the Content-Type does not seem very robust, but other functions in contentAreaUtils.js already do so.

Comment 54

[Chris Peterson [:cpeterson]]

Comment on attachment 649969 [details] [diff] [review]
save-document-title-v2.patch

Madhava and Stephen, ibarlow thought you might have opinions about this bug.

Comment 55

[Stephen Horlander [:shorlander]]

Comment on attachment 649969 [details] [diff] [review]
save-document-title-v2.patch

Review of attachment 649969 [details] [diff] [review]:
-----------------------------------------------------------------

This is a nice improvement. It is a much more meaningful name in most cases.

Comment 56

[Chris Peterson [:cpeterson]]

btw, I created a test page with a <title> containing reserved characters that are not allowed in filenames. I wanted to ensure that Firefox did not suggested a filename containing reserved characters when saving a page. The good news is that Firefox safely replaces reserved characters with underscores.

My test page's title was:
  <title>Slash / Backslash \ Question ? Percent % Asterisk * Colon : Pipe | Quote " LT &lt; GT &gt; Dot . Test</title>

With my patch, Firefox replaces '/' and ':' with '_' and saves the file as:
  Slash _ Backslash \ Question ? Percent % Asterisk * Colon _ Pipe | Quote " LT < GT > Dot . Test.html

Without my patch, Firefox saves the file as:
  reserved-character-test.html

Chrome replaces '/', '?', '*', ':', '|', '"', '<', and '>' with ' ' and saves the file as:
  Slash   Backslash \ Question   Percent % Asterisk   Colon   Pipe   Quote   LT   GT   Dot . Test.html

Safari replaces '/' with ':' and saves the file as:
  Slash : Backslash \ Question ? Percent % Asterisk * Colon : Pipe | Quote " LT < GT > Dot . Test.html

Comment 57

[Madhava Enros [:madhava]]

Comment on attachment 649969 [details] [diff] [review]
save-document-title-v2.patch

Yes - this makes a lot of sense.

Comment 58

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 649969 [details] [diff] [review]
save-document-title-v2.patch

(Sorry for the unreasonable review delay here.)

Hmm, do we want to keep the fallback of using the title for non-XML/HTML documents if getting the filename somehow fails? I'm not sure how likely that is to occur in practice. One case I can think of is saving data: URIs that represent images, where we probably should prefer using the title.

Comment 59

[Chris Peterson [:cpeterson]]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #58)
> that is to occur in practice. One case I can think of is saving data: URIs
> that represent images, where we probably should prefer using the title.

I compared the current behavior of Firefox, Chrome, and Safari when saving a data: URI of a .gif image:

 * Firefox 16 saves the image as "(GIF Image, 16 × 14 pixels).gif"
 * Firefox with my patch saves the image as "index.gif"
 * Chrome saves the image as "download.gif"
 * Safari saves the image as "Unknown.gif"

None of these filenames is very good, but I think your suggestion to use the title like "(GIF Image, 16 × 14 pixels).gif" is the least worst option.


Here is the data: URI of the .gif image I tested:

data:image/gif;base64,R0lGODlhEAAOALMAAOazToeHh0tLS/7LZv/0jvb29t/f3//Ub//ge8WSLf/rhf/3kdbW1mxsbP//mf///yH5BAAAAAAALAAAAAAQAA4AAARe8L1Ekyky67QZ1hLnjM5UUde0ECwLJoExKcppV0aCcGCmTIHEIUEqjgaORCMxIC6e0CcguWw6aFjsVMkkIr7g77ZKPJjPZqIyd7sJAgVGoEGv2xsBxqNgYPj/gAwXEQA7

Comment 60

[Chris Peterson [:cpeterson]]

Attachment: save-document-title-v3.patch

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #58)
> Hmm, do we want to keep the fallback of using the title for non-XML/HTML
> documents if getting the filename somehow fails? I'm not sure how likely
> that is to occur in practice. One case I can think of is saving data: URIs
> that represent images, where we probably should prefer using the title.

Gavin, are you suggesting something like this patch v3? If the page does not look like HTML/XML and does not have a filename, then return a non-empty document title.

Do you know what document types would fail those conditions and fall through to return directory name, hostname, or simply "index"? I can't think of any good examples. Even a local directory listings with file:/// has a document title (such as "Index of file_Users_.html").

Comment 61

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 657184 [details] [diff] [review]
save-document-title-v3.patch

Something like this, except that I would leave the fallback to the title before the fallback to aDefaultFileName, to match previous behavior. And get rid of that commented-out line :)

http://gavinsharp.com/tmp/ is an example of a page that would fall back to the "use the directory name" case (no title, no filename).

https://g4v.org/ is an example of a page that falls back to the "use the host" case.

javascript:1+1 is an example that falls back to the "default file name" case.

(and if DefaultSaveFileName is unlocalized, we fall back to the very last resort, using a hardcoded "index")

Comment 62

[Chris Peterson [:cpeterson]]

Attachment: save-document-title-v4.patch

Gavin, I think this patch does what you describe. One tiny inconsistency with the patch (that I think is such a corner case that it doesn't really matter):

STR:
1. View a data:image URI
2. `Save Page As` will save a file called something like "(GIF Image, 16 × 14 pixels).gif" (because the page has a document title).
3. But right-clicking on the image and `Save Image As` will save a file called "index.gif" (because the image does not have its own name or title).

In contrast, Chrome will save both files as "download.gif" and Safari will save them as "Unknown.gif".


!!! REGRESSION: Note that starting with Nightly 18.0a1 (2012-09-01), step #3 above will save the data:image as simply "index" (with no ".gif" filename extension), with or without my patch. You can repro this with the Nightly builds.

Should I open a bug for that "index" issue? I don't see an obviously suspect changeset in regression range from Nightly 08-31 to 09-01:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fcc533f691e9&tochange=a21fd4d085ad

Comment 63

[:Gavin Sharp [email: [e-mail]]]

(In reply to Chris Peterson (:cpeterson) from comment #62)
> STR:
> 1. View a data:image URI
> 2. `Save Page As` will save a file called something like "(GIF Image, 16 ×
> 14 pixels).gif" (because the page has a document title).
> 3. But right-clicking on the image and `Save Image As` will save a file
> called "index.gif" (because the image does not have its own name or title).

You should just file this separately, should be relatively easy to fix.

> Should I open a bug for that "index" issue?

Yeah.

Comment 64

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 657795 [details] [diff] [review]
save-document-title-v4.patch

>diff --git a/toolkit/content/contentAreaUtils.js b/toolkit/content/contentAreaUtils.js

>+    if (contentType == "application/xhtml+xml" ||

>+      if (docTitle) {

nit: You could combine these:

if (docTitle && (contentType == "..." || ...))

Comment 65

[Chris Peterson [:cpeterson]]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #64)
> nit: You could combine these:
> 
> if (docTitle && (contentType == "..." || ...))

Alternately, if I move the docTitle check above the contentType check, then I can avoid initializing `contentType = aDocument.contentType` when there is no docTitle:

  let docTitle;
  if (aDocument) {
    // If the document looks like HTML or XML, try to use its original title.
    docTitle = validateFileName(aDocument.title).trim();
    if (docTitle) {
      let contentType = aDocument.contentType;
      if (contentType == "application/xhtml+xml" ||
          contentType == "application/xml" ||
          contentType == "image/svg+xml" ||
          contentType == "text/html" ||
          contentType == "text/xml") {
        // 2) Use the document title
        return docTitle;
      }
    }
  }

Comment 66

[:Gavin Sharp [email: [e-mail]]]

(In reply to Chris Peterson (:cpeterson) from comment #65)
> I can avoid initializing `contentType = aDocument.contentType` when there is
> no docTitle:

That kind of micro-optimization usually isn't worth it - the contentType getter is trivial, and this isn't a hot path, so there's no need to jump through hoops to avoid it.

But in this case the impact to code readability is also negligible, so you can do that if you want.

Comment 67

[Chris Peterson [:cpeterson]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/b901e1920284

Comment 68

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/b901e1920284

Comment 69

[Chris Peterson [:cpeterson]]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #63)
> > 2. `Save Page As` will save a file called something like "(GIF Image, 16 ×
> > 14 pixels).gif" (because the page has a document title).
> > 3. But right-clicking on the image and `Save Image As` will save a file
> > called "index.gif" (because the image does not have its own name or title).
> 
> You should just file this separately, should be relatively easy to fix.

I opened bug 789550.


> > Should I open a bug for that "index" issue?
> 
> Yeah.

I opened bug 789546.

Comment 70

[william.allen.simpson]

I was so happy that this works now! We waited 8 and 1/2 friggin' years for this regression from Netscape to be fixed. Please don't bollux it again.

Comment 71

[:Gavin Sharp [email: [e-mail]]]

For users who might not be enamored with the new behavior, I created https://github.com/gavinsharp/SaveAsFilename.

Comment 72

[david.ecs]

(In reply to :Gavin Sharp (away Jan 16-23) from comment #71)
> For users who might not be enamored with the new behavior, I created
> https://github.com/gavinsharp/SaveAsFilename.

Thanks! Now I can update to 18.

Comment 73

[Manuela Muntean [Away]]

Verified fixed on Firefox 18.0.1.

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Build ID: 20130116073211

Comment 74

[u76985]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #71)
> For users who might not be enamored with the new behavior, I created
> https://github.com/gavinsharp/SaveAsFilename.

Thanks! Another extension to fix something which was not broken in the first place but got broken by a new Firefox version, in the line with Add-on compatibility reporter 1.1 (not 2!), Back/forward dropmarker, British English Dictionary, bug449729(Disable detach and tear off tab), check Compatibility, Locationbar², Padlock, RSS Icon, Skip Addon compatibility check, Status-4-Evar, Firefox 3 theme for Firefox 4+, ... - wouldn't it be a lot more easier to keep good behaviour instead of changing it and requiring add-ons to fix it again?

Comment 75

[pawright]

I have to add my thanks too. I have a number of routines to process saved pages which depended on the filenames.

There is no way of ever getting universal agreement on how these pages should be saved - what suits some doesn't suit others.

HOWEVER, where there is long-established behaviour being changed, a CONFIG should be published to revert to original methodology - the "You VILL do it zis vay now" is characteristic of Uncle Bill's broken software company.

And preferably the CHANGED characteristic should be INVOKED by a deliberate choice.

Comment 76

[Bill Dee]

This is STUPID!!!

If you are going to do this, you need to make it an OPTION in about:config so we can easily change it back to the "correct" operation of using the document's ACTUAL FILENAME.

AND you need to make it easier to find out what the hell is going on, so people can understand what is happening and how to change the behavior. ESPECIALLY with something so fundamentally different in operation. (I shouldn't have to find out about something like this by finding and reading the release notes)

You programmers need to start taking the average user's use of Firefox into consideration. Not all people are "power users" or programmer-types or anything like that.

If this was this hard for me to suss out, I can only imagine how difficult, irritating, and frustrating it is for the average Firefox user. It is uncalled for and a very poor development and implementation model.

Thanks to the person who made an extension to "fix" this behavior, but I shouldn't have to install an extension to "correct" (/revert) an issue like this.

Comment 77

[Tom Brennan]

Very annoying to find existing functionality broken by a bug "fix". I'd raise a bug to fix it back if it wasn't farcical. Maybe I should reopen 115176! As others have mentioned, this sort of change should really be a config option. It's not a bug, it's a design decision. It's been the subject of ongoing discussion for 10+ years, so it's pretty clear you're going to **** people off by changing it.

Comment 78

[MOW]

Yes, this should be a config option. Preferrably, with the option to pick one of the three candidates (url, title, header) each time. If the file selector doesn't support passing multiple alternative filenames, then with an extra popup, but please don't force the user to input things the browser already has.

Comment 79

[johanns]

I understand the arguments in favor of making this change:
1) Microsoft does it this way.  They uses the title so some users will expect the same behavior.
2) Average users will wonder why the title for a web page is not used as a "common sense", "easy" file name, though it frequently includes spaces and maybe be both confusingly generic and conflict with other "simple" file names.

The key point here is that well over a decade of precedence and strong practical considerations have been ignored.  Numerous people who regularly store web pages and want them stored with recognizable and non-generic file names now face having dumb-down behavior imposed unless they both track down the source of the problem in a little publicized, deliberate behavior change and locate the fix plugin.  In my experience the compatibility fix plugin was not prominently advertized and I needed to go through a partially manual installation process after downloading it from github.com.

I feel that a feature as important as saving web pages deserves to provide easy user flexibility for selecting a practical file name.  This is particularly true when long established and useful behavior is being systematically withdrawn.

I worry this compatibility fix plugin will vanish or stop working properly in later releases of Firefox.  By that time there may be an ingrained attitude that the new behavior is established and better and that any users who still feel inconvenienced or now have broken web application behavior have been given a suitable period of time to abandon their old work habits.  This represents a complete misuse of the feature deprecation process.  I personally rate this change as tantamount to feature rot.

I strongly advise reconsidering this approach by adding a configuration option to allow control of the file name default behavior.  I hope serious consideration will be given and that comments made on this issue are not simply being ignored.

Comment 80

[robin.wh]

I agree this should be option included in about:config.
For now I´ve used Save-as-Filename add-on (https://github.com/gavinsharp/SaveAsFilename), but it broke once firefox 20 was released.

Comment 81

[Kevin Brosnan [Ex-Mozilla]]

Open an issue on Github https://github.com/gavinsharp/SaveAsFilename/issues

Comment 82

[johanns]

I followed the recommendation and opened an issue on Github.

I strongly suggest that the proposed browser.download.savePageAsDocumentTitle preference should be added after all.  The fact it only took until Firefox 20 for the compatibility add-in to break strongly suggests that official support is needed in the browser for this feature to remain functional for the long term.

Comment 83

[johanns]

Update, I spoke too soon.  Earlier, I got an error trying to install SaveAsFilename from github that told me my download was corrupt.  Later, I tried again installing this time through the normal addon repository and this method did work:
https://addons.mozilla.org/en-US/firefox/addon/saveasfilename/?src=search
now the save as feature is using the filename, though it does seem to be missing the .htm file extension.

Mea culpa.

Comment 84

[nwse]

I want to indicate my total agreement with #75-#80 above. Because of the nature of the internet as presently implemented, if one wishes to, with certainty, be able to refer to a page tomorrow which you examine today, you better save a copy of it yourself offline.  So I save a lot of pages.  And I generally attempt to replicate the directory structure of the host.  So, while there were often issues, 
I really did want the original filename, not the title of the page.  When the mod was introduced which went from filename to title (years ago) I searched a bit for a config parameter to restore the original functionality.  I didn't find one, so I accepted the title mod effect, and began saving the original URL in a .url file, for many of the pages I saved offline.  There were a number of mods made in the update last month which I might have liked to have had a config param to un-mod, as well.  

You have a wonderful, sophisticated configuration editor and I think it would be wise to think "Is there some compelling reason one cannot make this mod we think of as an enhancement a configurable mod, allowing those who might disagree about its desirability, to easily choose not to have it?" I tended to write code that seemed sometimes to end up having more configuration options than executable code lines, most of which was untouched by most users.  So I tend to view things a bit extremely in that way, but I plead here for more of this attitude than I think is being practiced now.

This may not be the best place to make this plea.  If not, please point me to a better place.  I am a true believer in the mozilla project, and I sincerely thank you very very much.

Walt Biggs
NWSE

Comment 85

[Tom Brennan]

Unfortunately since Quantum/FF57, Save As Filename (https://github.com/gavinsharp/SaveAsFilename/) will no longer work as it doesn't use the WebExtension API. I don't have the skills/knowledge to update it. 

While not ideal, the only workaround I could come up with was to pin the following as a bookmarklet on the Bookmarks toolbar. It probably doesn't work in all circumstances, but it seems to cover the sorts of pages I want to save. Could probably be improved, since it was just hacking something else I found online. Hope it's useful to someone else.

javascript:(function(){ var link = document.createElement('a'); if (typeof link.download === 'string') { document.body.appendChild(link); link.download = document.baseURI.split('/').pop().split('#')[0].split('?')[0]; link.href = document.baseURI; link.click(); document.body.removeChild(link);} else { location.replace(uri);}})();

Comment 86

[Blake Winton (:bwinton) (:☕️)]

Tom: Have you filed a bug against the SaveAsFilename extension, asking Gavin to update it? It looks like it should be possible with https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/menus and https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/downloads/download to add a new context-menu item that saves as the filename instead of as the title…

I know you say you don't have the skills to update it, but it won't be much harder than the bookmarklet you've created, and if you wanted to give it a try, I'd be happy to help you! (Maybe we should take it to email, though, so as not to bother the other people on this bug. [e-mail] :)