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.

why is this in history? When was this working last? Changing component. Giving to Don

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.

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.

*** 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 ***

VERIFIED Dupe