Right (context-menu) clicking a link by Ancestor 4.6 yields a menu option: "Open in New Window". Loading the linked document will not update the link's color. I would dearly love an update. I might request that the beast dynamically update links, sifting care to watch even links in other windows, so that if a link is loaded in another (Mozilla) window, that link would be updated in all windows that display the link. Know what ah mean? I might request such; but I wish the above proposal taken seriously :+). So I'll label this greater ambition [DREAM].

Something for you to consider.

Pushing off non-beta 1 issues

From previous experience, this would be _very_ useful.

Reassigning peterl's bugs to myself.

Accepting peterl's bugs that have a Target Milestone

Pushing my M15 bugs to M16

We can't update the link status before the new window has successfully loaded the page (we don't want to mark it 'visited' if the server was down, for instance) therefore this feature comes down to dynamically updating links in other windows. I'm afraid it falls under the WONTFIX category for this release.

I thought WONTFIX for this release was LATER. At least that's how it's defined in the Bugzilla help.

reopening, as we should fix this eventually. IE does it, and it's very very very nice.

*** Bug 41035 has been marked as a duplicate of this bug. ***

*** Bug 24504 has been marked as a duplicate of this bug. ***

*** Bug 61581 has been marked as a duplicate of this bug. ***

updated qa contact.

[Generalizing summary -- doesn't apply just to `Open in New Window', but to any time a links is opened.]

*** Bug 19532 has been marked as a duplicate of this bug. ***

*** Bug 48578 has been marked as a duplicate of this bug. ***

Why is this RFE? This is a bug: The link has been visited--it shows up in the history. This bug has a lot of duplicates. IE and Nav 4.6+ already do this. Adding keywords access, correctness, 4xp (see bug 61581) and suggesting for mozilla 1.0.

tpowell, you're right about it being a bug rather than an enhancement. However, it's not `access' because it doesn't materially worsen the user experience for disabled users in particular; it's not `4xp', because the desired behavior doesn't happen with 4.77 for Mac OS, and I'm pretty sure it didn't work in 4.7 for Windows either (feel free to correct me with specific version numbers if I'm wrong); and while it is `correctness', that keyword tends to be rather meaningless. Finally, note that decorating a bug report with keywords generally doesn't make it get fixed any faster.

It is 4xp as it works as desired with Communicator 4.61 on Windows. I can easily reproduce this from a bugzilla page with right-click Open in New Window. Janne Hayrynen in the bug I mentioned before also suggests this works with recent 4.7x releases, but I haven't tried to reproduce this. So restoring the keyword. Sad to hear that it's failing on Mac, but we can get it right in Mozilla, right? As for access, I'd say it's more confusing and timewasting to those with disabilities (limited motion for example) to not easily tell which links have been visited than for regular users. It isn't specifically a problem for disabled/special needs users, but something that confuses everyone. The nice thing about access work is that it generally helps everyone. My point isn't to decorate the bug, but to make it easier to track from keywords. I find it helpful to be able to quickly view the places where Mozilla falls short of 4.x. I hope that's zero by 1.0. I wish this bug would get marked nsCatFood+, since I use open in new window all the time and not having those links marked visited is frustrating. The duplicates seem to indicate that others feel the same way. Are we allowed to use the nsCatFood keyword or is it for netscape product management use only? Since I'm in keyword adding mode, I'm adding nsCatFood. Hopefully that's cool. Removing [RFE] from summary since the bug was converted from Enhancement to minor severity (I assume by mpt?)

Hmm.. I don't see this in Communicator 4.75 or 4.77. If I right-click on a link and open in a new window, the link stays the same color.

It's true; Communicator doesn't do it either. But Communicator is not the standard or what's desirable in all cases. In fact, IE doesn't do it. The only browser I can think of that does this is Opera. I'd say Opera has it right. If I'm launching new windows from a frameset, I want to be able to know which links I've visited so far.

I suggest 4xp on some platforms should mean the 4xp keyword. I filed bug #76443 to clarify the issue. I don't recall this working on 4.76/Linux, but I'm pretty sure I've seen it working somewhere sometime in 4.X.

To clarify the 4xp, it seems to work pretty consistently on bugzilla pages with NS 4.61 WinNT, but not 100% of the time across the web. I'm not sure what's different. I agree with Matthew (matty) that 4xp on a platform should mean 4xp, since it seems the point of the 4xp keyword is to show when Mozilla lacks compared to the previous browser. (Thanks for filing bug 76443.)

mostfreq: direct dups: 19532,24504,41035,48578,61581 from 19532: 22893,23876,50716 from 48578: 49077,51687 IE 5.5 makes a link appear as visited as soon as you shift+click on it, but only in the window you opened the link from. If the linked-to page fails to load, the link remains purple until you reload the linking page. I think that's a reasonable solution in terms of the perf-usefulness tradeoff.

In my IE 5.5, it doesn't mark the link as visited until I reload the page. What it does do that's nice is leave it colored active. So if I view today's bugs I can open one in a new window and that link stays red until I open another link in a new window (or click elsewhere to kill the active state or refresh). At that time, the previous active link goes back to unvisited and the next one is now active.

Sean, I don't think IE has the optimal behavior here. Like I mentioned when filing bug 78510, Opera has the best treatment of visited links, and Mozilla should emulate it. I would say that if a link has been visited, it should always show as visited. IE doesn't do it, Mozilla doesn't do it, Netscape doesn't do it. Opera does it however.

I just noticed that IE 5.5 Win98 will immediately color a link as visited if you shift+click on the link or if the link has target=_blank (open in new window), but it won't color the link if you select "open in new window" from the context menu. That's probably why some people said IE has this feature and some people said it doesn't.

10 bugs according to http://bugzilla.mozilla.org/duplicates.cgi. Marking mostfreq.

pierre is out of the office, but we should try to fix this. Clearing MFuture and nominating mozilla0.9.2. cc karnaze -- Chris who could look at this?

This shouldn't be too hard to do, actually -- it's "just" a matter of telling all frames in all windows to reresolve style on all their links. This should be done AFTER the onload handler of the new page has fired, and should be done asynchronously. This is important otherwise it will have an adverse effect on page loading times.

> This should be done AFTER the onload handler of the new page has fired I certainly hope not. What Internet Explorer for Mac OS does (and what I think Mozilla should do) is change the link color as soon as the page *begins* to load. If you waited until onLoad, a link could be left uncolored solely because a stray graphic in the new page was taking forever to load. `I have visited this page' is true several seconds before `I have loaded this page' is.

This should also happen if the link is drag-dropped to another mozilla window.

BTW is 'mozilla0.9.2' still relevant?

*** Bug 100348 has been marked as a duplicate of this bug. ***

*** Bug 102430 has been marked as a duplicate of this bug. ***

I think this bug should be resummarized as "'Open link in new window' should give link :visited color" in order to avoid confusion with bug 78510. By the way, this bug directly impacts my porn surfing, especially on link pages where the focus outline is invisible (bug 100203) or hard to see due to a dark background color (bug 55676). I often end up reloading a list of links when I lose my place.

Does this have any priority with the NS team? IMHO, the whole link color changing feature is practically broken if it only works when it's opened in the same window. I agree with some of the later comments--why worry if the page finished loading or not? The new window with the page not loaded is enough to remind you it didn't go.

This is really a bad usability bug.

pierre@netscape.com: did you really want this bug?

-->alecf

oh, this is such a layout bug. We need to somehow reflow the frame AFTER the entry has arrived in global history. My only thought is that history could broadcast the fact that a link is visited every time it is visited, and then somehow every <link> frame could look and see if that's the url they're displaying However, we don't have a way to do this easily without bloating or being very slow. Futuring.

Alecf: bug 78510 covers broadcasting "I just loaded http://mozilla.org/" to all windows or to all link frames, like Opera does. This bug is about making a link become "visited" immediately after you middle-click (etc) on them, like IE does, which should be considerably easier. (IE's behavior also has the advantage that a link becomes visited right after you click on it, rather than several seconds later, making it easier to open a series of links.)

ah. it is not "considerably easier", nor worth the time for us to fix ONLY this case... that said, this is a dupe. there's no "easy" way to do this aside from fixing the real bug... *** This bug has been marked as a duplicate of 78510 ***

vrfy dupe

BTW this bug has 33 votes, bug 78510 only 8. Could you - voters - move your votes?

I still think bug 10491 (IE's way) is the best way to solve the problem, because it would take less memory/cpu time and would make the UI more stable (links would change color when you click on them, not several seconds later).

jruderman: please explain how fixing just this case "would take less memory/cpu time and would make the UI more stable"... because I don't know of a simple way, given our architecture, to implement this feature. Given MY knowledge of the codebase, I think that it would actually take MORE code to implement this feature than it would to implement bug 78510. If you know differently, I welcome a description of how we would solve this, given our current architecture.

FWIW, I think this bug (but not bug 78510) was fixed in firefox by simply making open in new window / tab cause a restyle of the link that was clicked. See http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/browser/base/content/contentAreaUtils.js&rev=1.57&mark=41,61,64-84