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.
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.
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"
Comment on attachment 73121 [details] [diff] [review] Proposed fix r=law
Attachment #73121 - Flags: review+
Comment on attachment 73121 [details] [diff] [review] Proposed fix sr=alecf
Attachment #73121 - Flags: superreview+
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
recently tried to verify this, but i believe i encountered bug 150438 --see my comments there.
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
You need to log in before you can comment on or make changes to this bug.