"Open link in new window" or target=_blank should give link :visited color

VERIFIED DUPLICATE of bug 78510

Status

defect
P2
normal
VERIFIED DUPLICATE of bug 78510
20 years ago
Last year

People

(Reporter: Crysgem, Assigned: alecf)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: parity-IE)

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].
Assignee: rickg → peterl
Something for you to consider.
Status: NEW → ASSIGNED
Target Milestone: M12
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.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
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.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Target Milestone: M16 → Future
*** 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.
QA Contact: janc → bsharma
[Generalizing summary -- doesn't apply just to `Open in New Window', but to any 
time a links is opened.]
Summary: [RFE] Update link status on "Open in New Window" → [RFE] Show link as :visited if opened in another window
*** 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.
Severity: enhancement → minor
Keywords: 4xp, access
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?)
Keywords: 4xp, nsCatFood
Summary: [RFE] Show link as :visited if opened in another window → Show link as :visited if opened in another window
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.
Keywords: 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?
Keywords: mozilla0.9.2
Target Milestone: Future → ---
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. ***
QA Contact: bsharma → moied
*** 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.
Severity: minor → normal
Status: REOPENED → ASSIGNED
Keywords: mozilla0.9.2
Priority: P3 → P2
Target Milestone: --- → mozilla1.0
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.
Summary: Show link as :visited if opened in another window → "Open link in new window" or target=_blank should give link :visited color
Whiteboard: parity-IE
Whiteboard: parity-IE → [Aufbau-P1] parity-IE
Whiteboard: [Aufbau-P1] parity-IE → parity-IE
pierre@netscape.com: did you really want this bug?
Assignee: pierre → blakeross
Status: ASSIGNED → NEW
Component: Parser → History: Global
QA Contact: moied → claudius
-->alecf
Assignee: blakeross → alecf
Target Milestone: mozilla1.0 → ---
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.
Target Milestone: --- → Future
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.)
Target Milestone: Future → ---
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 ***
Status: NEW → RESOLVED
Closed: 20 years ago18 years ago
Resolution: --- → DUPLICATE
vrfy dupe
Status: RESOLVED → VERIFIED
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
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.