212904 - http://foo/bar/ default save name should be bar.html

Status: RESOLVED FIXED

(Firefox :: General, defect, P3)

Description

[Jeremy M. Dolan]

Fix for this from suite needs to be ported. Opening a seperate bug as advised by
#firebird.

Suite bug was filed by me in January of '02 and recently fixed: Bug 118621

CVS checkin:

Checking in resources/content/contentAreaUtils.js;
/cvsroot/mozilla/xpfe/communicator/resources/content/contentAreaUtils.js,v  <--
 contentAreaUtils.js
new revision: 1.83; previous revision: 1.82

Patch:

attachment 127264 [details] [diff] [review]   (possibly not final patch, inline added afterwards)

Comment 1

[Adam Roben]

Confirming bug still present on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b)
Gecko/20030804 Mozilla Firebird/0.6.1

Comment 2

[Mike Connor [:mconnor]]

-> taking

definitely a usability win

Comment 3

[Mike Connor [:mconnor]]

Attachment: ported patch

this actually only applies if there is no title, so its not a huge change.  But
its an improvement and worth taking

Comment 4

[Mike Connor [:mconnor]]

Comment on attachment 131530 [details] [diff] [review]
ported patch

straight port

Comment 5

[Jeremy M. Dolan]

Can we get this to have priority over title? Prioritizing title over this new
method is inconsistent with file save behavior on other URLs. We should always
be basing the local file name off of the remote URL, regardless of whether it
LOOKS like a file or a directory.

foo.com/bar.html saves to bar.html
foo.com/bar/     saves to "Some long dumb name with search engine keywords.html"

That's unexpected behavior, if you ask me. Users won't really realize when one
behavior is being triggered instead of another.

Also, does this change the save name for "http://host/" to be host.html, or is
that a seperate bug?

Comment 6

[Mike Connor [:mconnor]]

actually, on many news sites the inverse behaviour will apply, sane title,
terrible URI, its relatively rare that the title is less useful than the URI,
despite some people's efforts.

Comment 7

[Jeremy M. Dolan]

Mike, while I do agree that often the <title> can make a better file name for
saving, this is a matter of very grave inconsistency. I would have no problem
with the current behavior provided saving foo.com/bar.html also used the
<title>. But to have the relatively equivilent foo.com/bar/ and foo.com/bar.html
use completly different naming mechanisms is ghastly.

I urge you to reconsider, and either make <title> or the URL the default for
both. (I suspect less users, at least on UNIX, would be upset with the latter).

Comment 8

[Mike Connor [:mconnor]]

Attachment: port of patch from seamonkey (right diff this time)

Comment 9

[Jeremy M. Dolan]

This is also a matter of using something that is not meant to be a file name
(<title>) over something that already *is* a file name (by the UNIX definition
of file).

"report.html" or "This is Jimmy's Report About Monkeys --- (c) 2003 Jimmy.html"

Again, even beyond the simple fact that if it had been "foo.com/report.html"
rather than "foo.com/report/" it would have used a normal file name, the later
filename in the example above is quite a pain to work with. Especially for UNIX
users. And it's certainly not an overblown example. Many pages have <title>'s
that are even longer, include many weird characters that a filesystem may not
support, or include characters that need to be quoted and/or escaped when
working from the command line.

Comment 10

[Mike Connor [:mconnor]]

I'd rather not break what exists in Seamonkey AND IE based on the UNIX
definition of a file.  You have a point, but its nowhere near strong enough to
override existing and expected behaviour in the browser realm.  In a number of
cases, the title value is more useful than what your proposal would provide. 

http://www.mozilla.org/hacking/ yields Mozilla Hacking In A Nutshell.html
instead of the highly generic hacking.html.  Which is more useful in six months?
 If anything, I'd rather see title override the filename (try saving three
stories from CNN.com, for an example of why).  Breaking expected (by 90+% of the
marketplace) behaviour based on an concept that has equal pro/con arguments is a
terrible idea.

Comment 11

[Ben Goodger (use ben at mozilla dot org for email)]

-> 0.9

Comment 12

[Jeremy M. Dolan]

Is this just waiting on reviews? It's been sitting for months. p_ch can you take
a look?

Comment 13

[Mike Connor [:mconnor]]

non-critical, if it makes it before 1.0, great, its pretty much a zero-risk
patch, but limited value as well.

Comment 14

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 135221 [details] [diff] [review]
port of patch from seamonkey (right diff this time)

r=[e-mail]

Comment 15

[Mike Connor [:mconnor]]

Fixed, branch and trunk.

Comment 16

[Ryan Polk (Quark)]

fixed-aviary1.0 is now a keyword, switching for searches