264816 - 'Save Link Target As' does not enter link into History/mark link as visited

Status: RESOLVED WORKSFORME

(Core Graveyard :: File Handling, defect)

Description

[David E. Ross]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.3) Gecko/20040910
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.3) Gecko/20040910

A link not actually viewed in the browser window is nontheless "visited" when
targeted file is saved.  However, the link is not entered into the browser
history.  Thus, the link will not be hightlighted by a color change (or other
highlighting per CSS) as visited.  

Reproducible: Always
Steps to Reproduce:
1.  Verify that <http://www.rossde.com/PGP/pgp_keysign_reg.txt> is not in the
browser history.  If it is, delete it.  
2.  Go to the indicated URL <http://www.rossde.com/PGP/pgp_keysign.html>. 
Scroll near the bottom until "(using this link)" is visible.  
3.  Right-click on "(using this link)".  Select "Save Link Target As".  Save the
file pgp_keysign_reg.txt.  
4.  Reload <http://www.rossde.com/PGP/pgp_keysign.html>.  
5.  View the history (Ctrl-h).  

Actual Results:  
At step #4, the text "(using this link)" of the target link does not change
color.  At step #5, <http://www.rossde.com/PGP/pgp_keysign_reg.txt> does not
appear in the browser history.    

Expected Results:  
At step #4, the text of the target link should change color from "Unvisited" to
"Visited".  At step #5, <http://www.rossde.com/PGP/pgp_keysign_reg.txt> should
appear in the browser history.  

The saved target does not have to be a TXT file.  I chose this example only
because I know the page <http://www.rossde.com/PGP/pgp_keysign.html> and the
target <http://www.rossde.com/PGP/pgp_keysign_reg.txt> are both rarely visited
and thus are unlikely to appear in anyone's history.  

If I open the target (to then save the file), it will indeed appear in the
browser history.

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

interesting...

note: this already works for files downloaded via the helper app dialog (it
explicitly calls nsIGLobalHistory::addURI)

Comment 2

[OstGote!]

Same thing for FF, see Bug 249257. Oh I see I missed to file a browser bug for
that. :-) Please change Hardware/OS to All/All.

(In reply to comment #1)
> note: this already works for files downloaded via the helper app dialog
see Bug 124014

Comment 3

[Boris Zbarsky [:bzbarsky]]

> A link not actually viewed in the browser window is nontheless "visited" when
> targeted file is saved. 

This part of the reasoning, I'm not sure I follow.  Why?

Comment 4

[David E. Ross]

Re comment #3:

Selecting the link results in the same request packet sent over the Internet to
the file's Web server whether it the link is selected for display or for "Save
Link Target As".  The response to the request packet is a series of packets that
are assembled as a file (or files, including CSS, graphics, etc) without regard
to whether the result will be displayed or saved.  

The only difference is whether the assembled file (or files) goes through Layout
for display or through File Handling for saving.  If the Web server is logging
requests, either case is treated at that end as a "visit" and will increment a
visit counter.  The Mozilla client should also treat either case as a "visit"
with regard to the history.dat file and highlighting the link (e.g., by a change
of color).  

As noted in comment #2, this is confirmed Bug 249257 for Firefox.  This is
merely the Mozilla Browser version of that bug.  Apparently, the code to fix
this problem differs between Mozilla and Firefox.  Thus, two separate bug
reports are needed to address the problem.  

Comment 5

[Boris Zbarsky [:bzbarsky]]

> Selecting the link results in the same request packet sent over the Internet

Yes, but we're talking about the user's point of view here, not the web
server's.  So the real question is whether user's think that a link they have
saved but never viewed is "visited".  User's don't particularly care about web
servers (or know about them, in general).  So web server logs are really not
relevant to the UI we present to users.

Comment 6

[David E. Ross]

You want a user's point of view?  Here it is.  

I am a user.  I wrote the bug report as a user.  I haven't been a serious
software developer in 35 years.  

Although I was a software test engineer, I also did a lot of user support.  I
wrote user manuals.  I did "help desk" work when that required senior
professionals instead of novices.  I interviewed users and conducted user
brain-storming sessions to determine formal software requirements for developers
to follow (and against which I later tested).  I think like a user because, for
many years, I was paid to think like a user.    

Today, I think like a user because, now that I'm retired, a user is all that I
am.  And I think that my client browser should behave as if "Save Link Target
As" visits the Web page that is saved.  

This is a user's point of view.  

By the way, my assertion about "Save Link Target As" visiting a Web page is
irrelevant.  This is a bug.  Otherwise Bug 249257 is invalid.  

Comment 7

[David E. Ross]

Still a problem: 
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.5) Gecko/20041217

Test case in original Description is still valid.  

Comment 8

[David E. Ross]

Still a problem: 
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.6) Gecko/20050319

Test case in original Description is still valid.  

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

can you stop adding those comments. there is no reason to assume that this would
be magically fixed.

Comment 10

[David E. Ross]

I enter these comments because there is a proposal to automatically close
Unconfirmed bug reports that have no action over a period of time, whether or
not they report actual bugs.  The proposal indicated that the bug authors would
be requested to re-assert that reported bugs still exist in order to prevent
closure.  

Rather than wait until that proposal becomes reality and then scramble to check
if the problems still exist, I check my Unconfirmed bugs whenever I upgrade to a
new version of Mozilla Suite.  I only submit these comments if I can indeed
confirm the problems do still exist in the new end-user release.  For
Unconfirmed bugs that are sporadic and not always reproduceable, I wait until I
actually experience the problem again before submitting comments for a new
version.  

I do not submit these comments on open bugs that are New or Assigned.  I will
stop submitting these comments for Unconfirmed bugs when I see that the proposal
for automatic closure has been dropped.  

Comment 11

[Christian :Biesinger (don't email me, ping me on IRC)]

ok, confirming this bug.

Comment 12

[David E. Ross]

This now appears to work in SeaMonkey 2.1RC1.