Closed Bug 20542 Opened 25 years ago Closed 25 years ago

links no longer turning visited color

Categories

(Core :: DOM: Navigation, defect, P3)

Product:
Core
Component:
DOM: Navigation
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: dbaron, Assigned: waterson)

Details

(Keywords: css1, Whiteboard: [PDT+] 2/15) 

DESCRIPTION:  Links I visit now are no longer turning the visited color (when I
come back to them in the browsing session or after exiting and restarting).
However, links that I visited before are still marked visited.

STEPS TO REPRODUCE:
 * load http://www.mozilla.org/ , or a page that hase some visited links
 * visit a link that's unvisited
 * go back.
 * exit the browser and reload the page

ACTUAL RESULTS:
After the 3d and 4th steps, the link is not the visited color

EXPECTED RESULTS:
It should be the visited color.

DOES NOT WORK CORRECTLY ON:
 * Linux, mozilla, 1999-12-01-13-M12

ADDITIONAL INFORMATION:
NOTE TO SELF:  There's another bug related to marking of visited links (and
trailing '/'s) that I thought I found, but obviously I shouldn't file it until
this is fixed.  It's in ~/webtest/visit.html .
Assignee: radha → waterson
This is global history code. Giving to waterson
Status: NEW → ASSIGNED
Target Milestone: M14
I'll look at this once the webshell is rewritten. Since history hasn't changed
in months, it's probably the code that calls history to insert new entries.
The "visited" status of links just doesn't work at all for me. From other bug
reports, such as the ones asking "open in new window" to immediately update the
"visited" status of the link in the current window, it seems that link
visitation is working for some people. Am I the only one currently seeing this bug?

They don't work for me at all, since a few months ago.  (The old links that I
had visited before they stopped working still showed up as visited, but were
gradually reverted back to unvisited, I think...)
Adding 'beta1' to keywords. Beta1 should support all CSS1 styles.
Keywords: beta1
This needs to work for beta. PDT+.
Whiteboard: [PDT+]
radha, I could use some help on this if you have cycles. I believe it all has 
to do with when the link makes it into history. there also were some problems 
with style changes not forcing reflow, cc-ing pierre.
Whiteboard: [PDT+] → [PDT+] 2/15
It works for me with recent builds on Mac and Windows. Is it a Unix problem?
See related bug 19978 and bug 25189.

Woah!

I just tried deleting my history.* files in my profile. Now it appears to 
be working. Sorry folks.
OK... I'll have to try this with fresh profiles, etc., but not now...
Hmm. I'm still having problems. My history is usually not saved into 
history.dat. Sometimes it is, usually when I've visited just a few pages, then 
quit.

I can reliably reproduce the bug: run "mozilla -CreateProfile", click on the 
"Mac build instructions" link, and quit. The resulting history.dat file in the 
new profile is effectively empty:

// <!-- <mdb:mork:z v="1.4"/> -->
< <(a=c)> // (f=iso-8859-1)
  (80=ns:history:db:row:scope:history:all)
  (81=ns:history:db:table:kind:history)(82=URL)(83=Referrer)
  (84=LastVisitDate)(85=Name)>
{1:^80 {/*r=0*/ (k^81:c)(s=9u)} }
Ok, my guess is that history is only being written to disk in the case that it 
isn't leaked. A manky fix would be to just periodically do a flush to disk.
Shouldn't the data be periodically flushed anyway, to guard against "unexpected 
termination"?

I almost never quit my Netscape 4.x session; either it crashes, or NT does. 
Usually NT. Anything important and persistent that might happen on application 
exit simply never gets executed.
OK, I've added a simple fix. I'm made global-history implement
nsIRDFRemoteDataSource (so that it's flush-able), and now Shutdown() [in
navigator.js] gets a reference to it and tells it to flush.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
*** Bug 23210 has been marked as a duplicate of this bug. ***
VERIFIED Fixed in 2000021416 builds
Status: RESOLVED → VERIFIED
This didn't work for me until I deleted my old profile and started over.  It's
disturbing that Mozilla can't deal with bad/corrupt/old profile data (or
whatever it is) by either fixing it silently, asking to fix it, or notifying the
user that there's a problem.  Should I open a new bug on this?

yeah, that issue seems to come up alot with several kinds of bugs. this sort of thing will happen to a large number of users who 
follow the upgrade path through 'preview release' all the way to final versions. I'd like to see what we can do about it.

Yeah, it does suck. But I'm afraid a bug like will go into the bit bucket unless 
there are some specific symptoms.
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.