Last Comment Bug 29080 - Visited links @ don't change color
: Visited links @ don't change color
Status: VERIFIED DUPLICATE of bug 12493
: embed
Product: Core
Classification: Components
Component: Document Navigation (show other bugs)
: Trunk
: All All
P5 normal with 2 votes (vote)
: ---
Assigned To: Radha on family leave (not reading bugmail)
: Andrew Overholt [:overholt]
: 40837 45250 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2000-02-24 09:15 PST by scott
Modified: 2008-07-31 02:32 PDT (History)
14 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image scott 2000-02-24 09:15:53 PST
If you do a search at, click on one of the results, then click the back
button, the followed link does not change color.

Nor does it do so in Commmunicator 4.72.  Works fine in IE5.  This is probably a
dupe but I couldn't find anything.
Comment 1 User image Sean Richardson 2000-02-25 14:39:33 PST
After typing "Pretty Park" into the Quick Search box at
the links turned to the visited colour after visiting a page and going back,
using the 2000-02-24-08-M14 nightly binary.

Code snippet from that page:
<b>gt;gt; <a href="rate/item.xp?CID=11675&PDID=16009">Dorney Park & Wildwater 
Kingdom</a></b> <span class="small">in <a 
href="rate/list_items.xp?CID=11675&PCID=11524">U.S. Amusement Parks</a></span>
----------, what build of Mozilla were you using? M13 or a later
binary (the build ID appears at the right-hand end of the status bar at the
bottom of the browser window)

A similar bug about the same issue on a cnet page was marked WONTFIX due to
4.x not doing any better with bad nesting of tags, but that does not seem
to be the case here.
Comment 2 User image scott 2000-02-28 07:52:32 PST
I was using a post-M13 nightly.  Still happening as of build 2000022716.  I'm on
NT4 (SP6) with a 3Dfx Velocity 100 AGP video card.

Visited links on other sites changing color just fine.
Comment 3 User image Doron Rosenberg (IBM) 2000-03-07 13:06:22 PST
i'm seeing a link color change only where css is not defined - example, where it
says "Click here to see how you can use the new and improved to help
you buy with precision.", 'here' link changes colors.
Comment 4 User image Ryan Massie 2000-03-07 17:38:58 PST
Confirmed on my 98 machine too (Build 2000030516)
Happens on too.

Bug 30607 is also very similar to this bug.
Comment 5 User image harm 2000-05-23 15:37:02 PDT
I dont see visited link change color on any site. example
buildid 2000052313
linux 686 machine with gnome.
Comment 6 User image Doron Rosenberg (IBM) 2000-05-23 23:21:14 PDT
I see them working on 200052208 win98 on the menu for example.

This smells like a dupe of 30607, unless this should be turned to a linux bug?
Assigning bug to owners of style system, not the browser-general people.

Can anyone on win98 reproduce this?
Comment 7 User image Marc Attinasi 2000-05-24 15:09:03 PDT
This does not look like a dup of 30607, which is a bug that the history is not 
matching with

Anyway, this is working on a fresh build for the Deja site - I tested a bunch of 
links and they are fine (Linux and WinNT).

Comment 8 User image harm 2000-05-24 17:00:35 PDT
Rechecked. OK.
Bug was gone when I removed ~/.mozilla before starting mozilla.
some old config stuff had messed up in time I guess.
Comment 9 User image Doron Rosenberg (IBM) 2000-05-24 22:42:53 PDT
30607 is about 'Visited links in targets/anchors don't change colors'...anyways 

Marking verified on win98. Reporter - deleting profile often does get rid of 
bugs. You should always do that before reporting.

Comment 10 User image Blake Ross 2000-05-27 14:32:44 PDT
*** Bug 40837 has been marked as a duplicate of this bug. ***
Comment 11 User image scott 2000-06-02 15:00:37 PDT
No wonder no one responded to my new comments... Bugzilla ate them :)
Ok I'll try this again:

This is still broken, but I have more info for you.  It only happens (links
don't change color) if you do a Power Search.  If you do a normal search, they
change.  Here's the exact steps:

Go to <>.  Click on "Search discussions", which takes you to
<>.  Click on "Power Search", which takes you to <>.  Search on anything and get the results
page.  Click the back button.  Link hasn't changed color.

Works fine in Communicator 4.73 and IE5.  Still not working as of build
2000060120.  I think this should be reopened (I'd do it myself but I'm not sure
if that's kosher).

PS: I always delete my profile info, along with the entire Mozilla directory
structure and moz*.dat in the Windows directory, before I install a new build.
Comment 12 User image Pierre Saslawsky 2000-06-02 21:06:02 PDT
It works for me. After doing a search, I click Back twice to come back to and the "Power Search" link is shown as visited.
Comment 13 User image scott 2000-06-12 17:41:07 PDT

Yes, THAT link works.  That's not what I'm talking about though.  I'm talking
about the links for the individual results for the search.  To reiterate:

Go to the Power Search page.  Type in "test" (or anything) and click on the
[Search] button.  You'll get a bunch of search results.  Click on any result.
Once the selected usenet post is up, click the [Back] button ONCE to return to
the list of search result.  The search result you followed will not have changed
to the followed-link color.
Comment 14 User image Pierre Saslawsky 2000-06-13 03:36:52 PDT
Correct. Reopening.
Comment 15 User image Pierre Saslawsky 2000-06-13 03:38:07 PDT
Reassigning to Chris Waterson. To reproduce:
- go to
- enter "test" and click Search
- click on the Subject of any article
- when the page is loaded, click the Back button
==> the link you clicked on to display the article is not shown as visited
Comment 16 User image Chris Waterson 2000-06-13 20:34:41 PDT
I think that the code in the anchor element is computing the correct URL, but it
looks like somebody in the front-end is URL escaping it. If you mouse over the
link, you'll see that the sqare brackets in the URL are maintained; however,
once you click on the URL, it escapes them to %5B. Somebody shouldn't be
escaping, here.
Comment 17 User image David Baron :dbaron: ⌚️UTC-8 2000-07-16 10:29:36 PDT
Are square brackets valid characters in URLs? makes me think not
(appendix A).  Should it be instead that the escaping should be done at a lower
Comment 18 User image Andreas Otte 2000-07-16 14:12:04 PDT
Currently we only allow them as part of the param, query and ref component when
the netwerk/base/src/nsURLHelper escaping code is used. With the old escaping
code in xpcom/io/nsEscape we escape it every time. [ and ] are also part of the
new ipv6 adresses but they are stripped out during parsing and put back in when
calling GetSpec or something similar. 
Comment 19 User image Chris Waterson 2000-07-20 21:24:31 PDT
See my previous comment. Layout is computing the correct URL, but the front-end 
is munging it because it's "over escaping". This is either an embedding issue 
or an XPApps issue; I'll try XPApps first...
Comment 20 User image Chris Waterson 2000-07-21 13:33:17 PDT
*** Bug 45250 has been marked as a duplicate of this bug. ***
Comment 21 User image sairuh (rarely reading bugmail) 2000-07-21 16:35:01 PDT
radha, would this be yours?
Comment 22 User image Radha on family leave (not reading bugmail) 2000-08-16 14:53:26 PDT
this is an embedding issue. 
Comment 23 User image sairuh (rarely reading bugmail) 2000-08-16 19:57:12 PDT
over to the default qa contact...
Comment 24 User image Adam Lock 2000-09-12 09:08:33 PDT
Works for me
Comment 25 User image scott 2000-10-23 11:29:34 PDT

Other people are seeing the behavior I'm describing, and I'm still seeing it as
of 2000102304.  Can you double-check your steps in recreating the problem?  Make
sure you're doing an ADVANCED search, and note my other comments since the
initial posting of the bug.  Thanks.
Comment 26 User image Adam Lock 2000-10-23 13:51:51 PDT
Apologies, I see the problem now.

The RFC says that square brackets should be escaped:

2.4. Escape Sequences

Data must be escaped if it does not have a representation using an
unreserved character; this includes data that does not correspond to
a printable character of the US-ASCII coded character set, or that
corresponds to any US-ASCII character that is disallowed, as
explained below.

So any character which is not unreserved (alphanum | "-" | "_" | "." | "!" | "~" 
| "*" | "'" | "(" | ")") or reserved (";" | "/" | "?" | ":" | "@" | "&" | "=" | 
"+" | "$" | ",") must be escaped. 

Therefore, it is legal that Mozilla escapes the URL in the address field. 
Probably it should escape the link too but that might break javascript (see bug 
56529). The visited link history should also do unescaped string comparison so 
link colouring and caching is correct.
Comment 27 User image timeless 2000-11-06 21:14:19 PST
Adam: Ok, so I guess you're saying this should go to history.
Comment 28 User image Jesse Ruderman 2000-11-06 21:40:28 PST
Based on adam's and timless's comments, I'd say this is a dup of bug 
12493, "layout does not canonicalize URIs for global history lookup".  Waterson 
(or others), any objections?
Comment 29 User image Viswanath Ramachandran 2000-12-21 11:40:24 PST
nav triage team: how widespread/common is this. does it only happen in some edge 
cases? it has to be common to be a beta stopper. lowerign priority. will raise 
only if common. thanks. 
Comment 30 User image scott 2000-12-21 11:58:23 PST
This is fairly widespread... I'm surprised that no one complains but me :)

I see it also at Yahoo, AltaVista, Google, Excite, Lycos...  I'm not sure if
it's because of the same reasons as Deja (I'll leave that to those more adept
than I), but using search engines is VERY difficult when you can't keep track of
which results you've visited and which you haven't.
Comment 31 User image harm 2000-12-21 13:35:16 PST
shows this too
click a link on the page and go back or restart mozilla -> not marked as visited
buildid: 2000121908 M18 0.6
Comment 32 User image Paul Chen 2001-01-26 15:07:58 PST
nav triage team:

Marking nsbeta1+

And why is this stuff previously in the status whiteboard?

"The Link's Characters include [] and other stuff that must be escaped"
Comment 33 User image Jesse Ruderman 2001-01-28 00:55:40 PST

*** This bug has been marked as a duplicate of 12493 ***
Comment 34 User image stephen.donner 2001-07-18 23:58:03 PDT
verified dup.

Note You need to log in before you can comment on or make changes to this bug.