Some examples:
1) http://www.bbc.co.uk/
-> "BBC - Homepage"
2) http://news.bbc.co.uk/2/hi/south_asia/8191988.stm
-> "8191988.stm"
When URL contains some filename Firefox use this filename as default
filename. I would like to change this way how Firefox handles this. If
you have a look at different browsers they generate default filename
like 1) in every situation where they can.
Bug 254139 [1] is about this change in Firefox and contains patch. But
patch was rejected because it isn't clear if we want to have this behaviour.
What to do with it? Need ui-review or some general discussion?
Thanks
Pavel Cvrcek
From an end-user perspective, I would strongly support this feature.
Especially my parents save quite a lot of pages from the web, and many
of them are simple titled index.html, which is not very convenient and
leaves you unclear about the content until you open it.
Advocating 2:
- When saving pages, it may preserve relative link between
the saved page.
- It preserve more information since the title is still in the saved
file.
- Many web site make a poor usage of the page title.
Advocating 1:
- When saving pages, you may find them more easily
later on on the basis of the file name. (That is if you have a poor OS
without a decent indexing capability).
- Having a page getArticle.php?id=xxx saved as
getArticle.php.html is a frequent usage issue.
Other Better solutions:
A It is possible to push both name to the
Save As trough the MRU List and let the user choose!
B Take the more sensible one on a case by case basis.
(avoid default file name)
C (B may not be practical to code) A lesser evil would be:
If the file name extension match the MIME type:
Save with the file name as it is now done. (it will preserve relative
URL on save)
Otherwise: use the title if one is present.
D let a config parameter control this.
E if the user changed the suggested file name, switch approach.
Anyway, change this only if FF finally gain a decent file save
capability:
- Support for MHT or some other single file packaging.
- Add meta information such as saved from url: on :date/time
This seems like a no-brainer to me. Firefox should save web pages
using the <title> name and not the filename of the web page (e.g.,
"Save Page As should default to <title>" vs. "show_bug.cgi.htm").
No.Brainer.
That makes sense to me, and seems to be what Ben Goodger indicated his patch does in bug 115176 where in comment 112 he says:
> a) this makes content-disposition win over everything, if its specified
> b) for Save Page As, this continues to use the document title
> c) for links, it uses the file name
So when did that change?
cheers,
mike
> ----- "Peter Lairo" <peter...@googlemail.com> wrote:
>
> That makes sense to me, and seems to be what Ben Goodger indicated his
> patch does in bug 115176 where in comment 112 he says:
>
> > a) this makes content-disposition win over everything, if its specified
> > b) for Save Page As, this continues to use the document title
> > c) for links, it uses the file name
>
> So when did that change?
>
This has changed before the cvs was imported into hg. This blame [1] seems
to suggest that the changes were ported from xpfe in bug 294759. Looking at
the xpfe blame [2], this seems to have changed as part of bug 120174 in this
cvs change: [3]. The comments in that bug seem to refer this change to bug
115176 which is strange...
[1] <
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/content/contentAreaUtils.js&rev=1.103&mark=744#744
>
[2] <
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/xpfe/communicator/resources/content/contentAreaUtils.js&rev=1.142&mark=822#822
>
[3] <
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/xpfe/communicator/resources/content&command=DIFF_FRAMESET&file=contentAreaUtils.js&rev2=1.30&rev1=1.29
>
--
Ehsan
<http://ehsanakhgari.org/>
I'm not sure what's strange about it. Bug 115176 is "<title> [or link
text] is used as default filename when doing Save Page [or Save Link]"
(as opposed to using the filename), which is precisely what people are
suggesting we do.
Anyone proposing changes to this code should read that bug carefully.
Yes, all 159 comments. Sorry, that's just life for this sort of thing;
this bug actually has a relatively high signal-to-noise ratio for the
sort of bug it is.
We could probably save using the title if we decoupled the "save link"
codepath from that behavior, if my current skim of the bug recalls
things correctly, but someone really should read carefully to check.
-Boris