If you do a search at Deja.com, 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.
After typing "Pretty Park" into the Quick Search box at http://www.deja.com/ 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> ---------- firstname.lastname@example.org, 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.
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.
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 Deja.com to help you buy with precision.", 'here' link changes colors.
Confirmed on my 98 machine too (Build 2000030516) Happens on netscape.com too. Bug 30607 is also very similar to this bug.
Status: UNCONFIRMED → NEW
Component: Browser-General → Style System
Ever confirmed: true
I dont see visited link change color on any site. example www.mozilla.org buildid 2000052313 linux 686 machine with gnome.
I see them working on 200052208 win98 on the mozilla.org 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?
Assignee: cbegle → pierre
QA Contact: asadotzler → chrisd
This does not look like a dup of 30607, which is a bug that the history is not matching http://www.foo.com with http://www.foo.com/ 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). Marking WORKSFORME
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → WORKSFORME
Rechecked. OK. Bug was gone when I removed ~/.mozilla before starting mozilla. some old config stuff had messed up in time I guess.
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.
Status: RESOLVED → VERIFIED
*** Bug 40837 has been marked as a duplicate of this bug. ***
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 <http://www.deja.com/>. Click on "Search discussions", which takes you to <http://www.deja.com/usenet/>. Click on "Power Search", which takes you to < http://www.deja.com/home_ps.shtml>. 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.
It works for me. After doing a search, I click Back twice to come back to http://www.deja.com/usenet/ and the "Power Search" link is shown as visited.
Pierre: 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.
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
Reassigning to Chris Waterson. To reproduce: - go to http://www.deja.com/home_ps.shtml - 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
Assignee: pierre → waterson
Status: REOPENED → NEW
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.
Status: NEW → ASSIGNED
Target Milestone: --- → M17
Are square brackets valid characters in URLs? http://info.internet.isi.edu/in-notes/rfc/files/rfc2396.txt makes me think not (appendix A). Should it be instead that the escaping should be done at a lower level?
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.
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...
Assignee: waterson → don
Status: ASSIGNED → NEW
Component: Style System → XP Apps
QA Contact: chrisd → sairuh
Target Milestone: M17 → ---
*** Bug 45250 has been marked as a duplicate of this bug. ***
radha, would this be yours?
Assignee: don → radha
this is an embedding issue.
Assignee: radha → valeski
Component: XP Apps → Embedding: Docshell
over to the default qa contact...
QA Contact: sairuh → adamlock
Works for me
Adam: 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.
Assignee: valeski → radha
Component: Embedding: Docshell → History
OS: Windows NT → All
QA Contact: adamlock → claudius
Hardware: PC → All
Whiteboard: The Link's Characters include  and other stuff that must be escaped
Adam: Ok, so I guess you're saying this should go to history.
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?
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.
Priority: P3 → P5
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.
http://www.kernelnotes.org/lnxlists/linux-kernel/ shows this too click a link on the page and go back or restart mozilla -> not marked as visited buildid: 2000121908 M18 0.6
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"
Whiteboard: The Link's Characters include  and other stuff that must be escaped → nsbeta1+
*** This bug has been marked as a duplicate of 12493 ***
Status: NEW → RESOLVED
Last Resolved: 19 years ago → 18 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
Component: History: Session → Document Navigation
QA Contact: claudius → docshell
You need to log in before you can comment on or make changes to this bug.