saving html: shouldn't TITLE or caller-provided name be used as filename when url has no explicit filename?

VERIFIED FIXED

Status

Core Graveyard
File Handling
VERIFIED FIXED
16 years ago
2 years ago

People

(Reporter: sairuh (rarely reading bugmail), Assigned: Bill Law)

Tracking

({regression})

Trunk
regression

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
tested using 2002.03.06 comm bits on linux rh7.2, mac 10.1.3 and win2k.

when i save an html page whose url doesn't specify its filename, the suggested
filename in the file picker uses the hostname instead. if the page has a <title>
--or even the caller-provided name like the link text-- shouldn't either of
those take precedence over the hostname?

here are a couple of test cases which exhibit the current behavior.

recipe A:
--------

1. go to http://mozilla.org/
2. shift-click (option-click on Mac) a link whose url doesn't end with an
explicit filename --eg, the "Testing" link on the left side.

result: the suggested filename in the file picker is "mozilla.org.html".
expected: use either the document <title> (expected for recipe B), or the link
text (actual/expected for recipe C) --methinks it's should be the latter, but am
not sure. what do people think?


recipe B:
--------

1. go to a url where the filename isn't specified but where the document *does*
have a <title>, eg, http://mozilla.org/quality/ whose title is "Mozilla QA Home
Page"
2. do a "save page as": hit accel+S, select File > Save Page from top-level
menu, or "save page as" from the context menu.

result:  the suggested filename in the file picker is "mozilla.org.html".
expected: use the document <title>, in this case "Mozilla QA Home Page.html"


recipe C: control test where link text (caller-provided name) is used.
--------
1. go to http://mozilla.org/
2. bring up the context menu for a link whose url doesn't end with an explicit
filename --eg, the "Testing" link on the left side.
3. select "save link as"

result: the suggested filename is "Testing.html", as expected.
(Reporter)

Updated

16 years ago
Keywords: nsbeta1
(Reporter)

Comment 1

16 years ago
forgot to mention: for recipes A and B, in spite of the hostname being
suggested(*), the expected document *is* saved fortunately.

(*)this was initially confusing to me, hence this bug, since it might confuse
other users. :)
This used to work.  Investigating.
Keywords: regression
(Assignee)

Comment 4

16 years ago
Boris, can you explain the patch(es), please?

It looks like the first bit (for contentAreaUtils.js) just fixes a snafu which
was the cause of this bug.

Is the other bit (changes to contentAreaClick.js) fixing up some other problem
you ran into while testing this?
The first part indeed just adds back the document arg which seems to have been
removed by accident.  The second part is a fix for Sarah's recipe A.  The reason
that recipe A fails is that we end up calling gatherTextUnder on the event
target, which is the text node inside the anchor. The semantics of
gatherTextUnder are such that it wants a container node and returns "" when
given a node with no children (which is what a text node is).

The reason recipe C works correctly is that there we are calling gatherTextUnder
on the target of the context menu, which is the <a> node, not the text (this is
handled in the code that brings up the context menu -- the menu is associated
with the first element node that's an "interesting" ancestor whatever got got
right-clicked on.

So the second patch _could_ be replaced with a change to gatherTextUnder to
handle #text nodes, but then something like:

<a href="http://www.mozilla.org"><b>bold</b> not bold</a>

would give either "bold" or "not bold" as the suggested filename depending on
where the user clicked when we want it to give "bold not bold"
(Assignee)

Comment 6

16 years ago
Comment on attachment 73121 [details] [diff] [review]
Proposed fix

r=law
Attachment #73121 - Flags: review+

Comment 7

16 years ago
Comment on attachment 73121 [details] [diff] [review]
Proposed fix

sr=alecf
Attachment #73121 - Flags: superreview+

Comment 8

16 years ago
Comment on attachment 73121 [details] [diff] [review]
Proposed fix

a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #73121 - Flags: approval+
checked in on the trunk
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
(Reporter)

Comment 10

16 years ago
recently tried to verify this, but i believe i encountered bug 150438 --see my
comments there.
(Reporter)

Comment 11

16 years ago
vrfy'd fixed, using 2002.07.22 comm branch bits on linux rh7.2, win2k, mac 10.1.5.

here are alternative tests (since bug 150438 can be site-specific).

recipe A
--------
1. go to http://kith.org/
2. bring up the context menu for the "Echo's Children" link (near the bottom of
the page), and select "save target link as"

expected (and actual) results: the suggested filename is "Echo's Children.html".


recipe B
--------
1. go to http://mozilla.org/quality/
2. save the file via either accel+S or File > Save Page As

expected (and actual) results: the suggested filename is "Mozilla QA Home
Page.html".
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.