Closed Bug 48578 Opened 24 years ago Closed 23 years ago

visited links don´t change color after opening in new window

Categories

(SeaMonkey :: General, defect, P3)

Product:
SeaMonkey
Component:
General
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 10491

People

(Reporter: pat, Assigned: law)

References

Details

(Whiteboard: [nsbeta3-]) 

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.13 i686; en-US; m17) Gecko/20000807
BuildID:    20000810

After right-clicking on a link and choosing "open link in new window", the link
doesn´t change it´s color on the original page

Reproducible: Always
Steps to Reproduce:
1. go to a page with a lot of links e.g. a bugzilla query
2. right click on a link and choose "open link in new window"
3. switch back to the original window (the bugzilla query)

Actual Results:  the just openend link has the same color (blue)

Expected Results:  it changes it´s color to the visited link color (purple)

This works fine with M17 builds, stopped working for me with M18 builds.
Yes it's true.  We have regressed.  Linux 2000-08-11-08.
Status: UNCONFIRMED → NEW
Ever confirmed: true
why is this in history? When was this working last? Changing component. Giving 
to Don
Assignee: radha → don
Component: History → Browser-General
Is this only when opening a new window? If you just surf the link and go back does the link get colored? Is your Global 
History(Tasks menu|Tools|History) file getting populated or is it empty? Enquiring minds want to know.

> Is this only when opening a new window?
Yes, looks like it.
> If you just surf the link and go back does the link get colored?
Yes, that works fine. After going back even the links I previously visited via
"open in new window" are also purple as expected.
> Is your Global
> History(Tasks menu|Tools|History) file getting populated or is it empty?
No, the history window itself works fine, URL are added as I visit them.

adding nsbeta3 keyword. thanks for the quick response. Based on those answers, I'm now stumped for what component, this bug 
should be in.
Keywords: nsbeta3
I'm taking this, since Radha doesn't want it.  It is a history thing, I think 
(but global history).

Not beta3+, though (sorry).  I never trust those link colors anyway.
Assignee: don → law
Whiteboard: [nsbeta3-]
*** Bug 49077 has been marked as a duplicate of this bug. ***
*** Bug 51687 has been marked as a duplicate of this bug. ***
> Not beta3+, though (sorry).  I never trust those link colors anyway.

So because it doesn't work it shouldn't be fixed? great reasoning!
(sorry, I just had to remark that :) )

Probably not a xpapps bug.  It seems that reloading the page causes the links to
redraw the proper color.  Somehow we need to be able to alert Gecko that the
link status might have changed.  Not sure how that would be done.  Maybe just
set some bogus attribute on the link to trigger a reflow?
The link doesn't change not only after opening a new window, but also after
simply clicking on ANY link on the page (or is that a different bug?). The page
shouldn't have to be reloaded for the link to show as visited (especially in a
frameset). I suggest changing the summary to the more general "visited links
don't change color after being clicked on" - the new window part is almost
irrelevant.
based on the history of this bug (the behavior was very specific) I would think what the last
commentor was seeing is a different bug. I would love if you could point to an example of
this happening though.

Responding to Claudius' last comment:
What I have in mind might be a separate issue from this bug, but I believe them
to be linked. Let me know whether you believe I should spin off a separate bug
after you hear what I have to say, or whether you agree with me that this bug's
summary should be changed as a I suggested in my last comment.
If I right-click on a link, and open in a new window, the link color in the
original window should change. That is what this bug was originally about. But I
point out that if I click a link in a frameset that loads a page in a different
frame, the link I clicked to cause this should now show visited status, without
requiring a reload. But it does not show as displayed. As an example, go to
http://java.sun.com/j2se/1.3/docs/api/index.html (the place I most often notice
this bug while browsing) and click some of the links in the lower left hand
frame. The link colors do not change.
What I believe to be the ideal behavior for visited links is that which Opera
(not exactly my favorite browser) manifests: If a link is opened in a new
window, the original link shows visited (IE also does this). If a link in a
frameset is clicked, that link shows visited (IE also). If there are two links
in different frames of a frameset pointing to the same place, the activation of
one causes the other to show as visited (Opera exhibits this behavior, though IE
doesn't). Lastly, if two separate windows have links that points to the same
place, activating one notifies the other window, which paints its link as
visited (IE doesn't do this either).
In this manner the user never has to say "I never trust those link colors
anyway." ;-)
This bug has been around since the beginning of time in terms of Netscape; I
checked 3.x and 4.x, and they do the same thing Mozilla does. That, of course,
doesn't make Mozilla's behavior right!
I prefer a new bug. In order to get this fixed right it will take a lot of work and clear statement
of the problematic scenarios with comparisons to other relevant browsers (exactly what you
have done) without any other noise will help a lot. This bug would depend on the new one I
imagine.


*** This bug has been marked as a duplicate of 10491 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
VERIFIED Dupe
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.