Closed Bug 254139 Opened 20 years ago Closed 12 years ago

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

Categories

(Firefox :: File Handling, enhancement, P3)

1.0 Branch
enhancement

Tracking

()

VERIFIED FIXED
Firefox 18
Tracking Status
firefox18 --- verified

People

(Reporter: haymo_schoener, Assigned: cpeterson)

References

(Depends on 1 open bug, )

Details

Attachments

(4 files, 4 obsolete files)

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.
Dupe of bug 205458 IMO. See bug 115176 too. 
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+
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.
Summary: file name - save as → File | Save Page As should default to <title>, not filename
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.
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.
same or similar problem in MacOS X.  Should be confirmed and cross platform. 

yes, I read both bug 115176 and bug 173982.
Severity: normal → enhancement
OS: Windows XP → All
Hardware: PC → All
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?
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,  
Depends on: 173982
*** Bug 275303 has been marked as a duplicate of this bug. ***
(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??
*** Bug 275901 has been marked as a duplicate of this bug. ***
(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.
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>.

(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!
(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...).
*** Bug 288107 has been marked as a duplicate of this bug. ***
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!)
*** Bug 321992 has been marked as a duplicate of this bug. ***
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.
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.
> 

Assignee: bugs → nobody
QA Contact: aebrahim-bmo-507 → file.handling
*** Bug 333872 has been marked as a duplicate of this bug. ***
Does this bug depend on bug #299372, or the other way round?
Blocks: 164421
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"?
Flags: blocking-firefox3.1?
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.
(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.
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
(...)
Attachment #324261 - Flags: review?
Attachment #324261 - Flags: review? → review?(gavin.sharp)
(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"
(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.
(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?
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.
Attachment #324261 - Attachment is obsolete: true
Attachment #324273 - Flags: review?(gavin.sharp)
Attachment #324261 - Flags: review?(gavin.sharp)
text/html isn't the only doctype that has a custom title.  Consider checking for indexOf("html") instead, or something similar.
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 ?
Attachment #324273 - Attachment is obsolete: true
Attachment #324273 - Flags: review?(gavin.sharp)
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)?
Same as before, but regex on XML or HTML.
I think you can ask for a review, I don't see what more can be done at this point.
Attachment #324353 - Flags: review?(gavin.sharp)
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?
Nice to have,not a blocker.
Flags: wanted-firefox3.1+
Flags: blocking-firefox3.1?
Flags: blocking-firefox3.1-
Whiteboard: [has patch][needs review gavin]
My god, this bug has exist more than four years!
It is so bad!
Please kindly fix this!
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.
Keywords: uiwanted
Whiteboard: [has patch][needs review gavin]
Attachment #324353 - Flags: review?(gavin.sharp)
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.
Definitely too late for 3.5.
Flags: wanted-firefox3.5+
Priority: -- → P3
Target Milestone: --- → Future
(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 :(
(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
This appears to have been fixed in the latest nightlys
(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.
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".
Attachment #648640 - Flags: ui-review?(ux-review)
Attachment #648640 - Flags: review?(gavin.sharp)
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.
Attachment #648640 - Flags: review?(gavin.sharp) → review+
(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?
(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
Assignee: nobody → cpeterson
Status: NEW → ASSIGNED
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.
Attachment #648640 - Attachment is obsolete: true
Attachment #648640 - Flags: ui-review?(ux-review)
Attachment #649969 - Flags: ui-review?(ux-review)
Attachment #649969 - Flags: review?(gavin.sharp)
Comment on attachment 649969 [details] [diff] [review]
save-document-title-v2.patch

Madhava and Stephen, ibarlow thought you might have opinions about this bug.
Attachment #649969 - Flags: ui-review?(ux-review)
Attachment #649969 - Flags: ui-review?(madhava)
Attachment #649969 - Flags: feedback?(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.
Attachment #649969 - Flags: feedback?(shorlander) → feedback+
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 on attachment 649969 [details] [diff] [review]
save-document-title-v2.patch

Yes - this makes a lot of sense.
Attachment #649969 - Flags: ui-review?(madhava) → ui-review+
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.
Attachment #649969 - Flags: review?(gavin.sharp) → feedback+
(In reply to :Gavin Sharp (use gavin@gavinsharp.com 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
Attached patch save-document-title-v3.patch (obsolete) — Splinter Review
(In reply to :Gavin Sharp (use gavin@gavinsharp.com 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").
Attachment #657184 - Flags: review?(gavin.sharp)
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")
Attachment #657184 - Flags: review?(gavin.sharp) → feedback+
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
Attachment #657184 - Attachment is obsolete: true
Attachment #657795 - Flags: review?(gavin.sharp)
(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 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 == "..." || ...))
Attachment #657795 - Flags: review?(gavin.sharp) → review+
(In reply to :Gavin Sharp (use gavin@gavinsharp.com 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;
      }
    }
  }
(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.
https://hg.mozilla.org/integration/mozilla-inbound/rev/b901e1920284
Keywords: uiwanted
Target Milestone: Future → Firefox 18
Version: unspecified → 1.0 Branch
https://hg.mozilla.org/mozilla-central/rev/b901e1920284
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
(In reply to :Gavin Sharp (use gavin@gavinsharp.com 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.
Depends on: 830216
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.
For users who might not be enamored with the new behavior, I created https://github.com/gavinsharp/SaveAsFilename.
(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.
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
Status: RESOLVED → VERIFIED
(In reply to :Gavin Sharp (use gavin@gavinsharp.com 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?
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.
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.
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.
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.
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.
Depends on: 852431
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.
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.
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.
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
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);}})();
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. bwinton@mozilla.com :)
Depends on: 1459064
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: