116213 - URLs (links) in mail messages are always 'not visited' colour (or color, for all you Americans :-)

Status: NEW

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Russell Odom]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120
BuildID:    2001112009

The colour of links contained in e-mails do not change when I've visited them -
they always remain blue.

Not sure if this is intended behaviour, but it's counter-intuitive.

Reproducible: Always
Steps to Reproduce:
1. Send yourself an e-mail with a link in it (or just open one you've previously
received - e.g. one from bugzilla-daemon)
2. Click on the link
3. Load a different e-mail, then go back again (to refresh)

Actual Results:  Link is still blue

Expected Results:  Link should be purple to indicate I've visited it

Comment 1

[Russell Odom]

Just realized - this doesn't happen all the time - I visited this bug page
*before* I received the confirmation from bugzilla-daemon, and the link to it
does indeed appear purple in the e-mail.

However, when I click a link *after* I've opened the e-mail, it remains blue. 
It is still blue even after I've closed and reopened Mozilla.

Comment 2

[Russell Odom]

Confirming this bug - still seeing all links in blue (no longer seeing the
effect I described in comment 1 though)

Comment 3

[Aleksey Nogin]

I also see this - BuildID 2002101719 (trunk) on Red Hat Linux 8.0. In fact, I am
using mozilla since 0.7 (if not earlier) and I never saw a link displayed as
visited in MailNews.

I disagree with Severity: minor since this can be pretty annoying if you have a
bunch of links in the message and need to know which ones are new.

Comment 4

[Cliff Palmer]

This problem still exists in Mozilla 1.2b (Mozilla/5.0 (Windows; U; WinNT4.0;
en-US; rv:1.2b) Gecko/20021016).  In Netscape 4.79, links in Mail and Newsgroup
messages are always rendered the proper color.  Mozilla build 0.9.7 also
properly rendered links in MailNews messages, but none of the subsequent
releases have done so.

While the severity of the bug is listed as minor, this behavior is an annoyance,
and can cause wasted time visiting links that have already been visited.

Comment 5

[Tuukka Tolvanen (sp3000)]

by design? bug 104613 comment 19

Comment 6

[(not reading, please use [e-mail] instead)]

> by design? bug 104613 comment 19

right, this was done for performance reasons.

note, also think about stand alone mail.

we won't have browser history, even if we wanted it.

Comment 7

[Daniel B.]

(In reply to comment #6)
> > by design? bug 104613 comment 19
> 
> right, this was done for performance reasons.
> 
> note, also think about stand alone mail.
> 
> we won't have browser history, even if we wanted it.

Even if stand-alone mail can't color links, that doesn't mean links can't 
be colored in the Mozilla Suite version of mail.



Also, still a problem in Mozilla 1.7.3
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910









 

Comment 8

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 9

[Daniel B.]

(In reply to comment #8)
> we cannot determine that it's still valid for the current SeaMonkey suite.

Why not?  (Is some part of the Steps to Reproduce not longer applicable
in Seamonkey 2.x?)

Comment 10

[Martin F.]

Steps are valid and so is the bug, the issue is still existing.

Comment 11

[lenochod]

I can confirm it with  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5pre) Gecko/20091013 Lightning/1.0pre SeaMonkey/2.0pre