I have my setting for history the default 90 days.
This evening I noticed links I clicked yesterday were already flipped back to the non-visited color. NEXT DAY!?!?!
Previously someone suspected that the HTML of the page might be specifying a shorter history span. I know of nothing in HTML that can specify a length of time to display the visited color. However,
here is the body tag from the site in question:
<body bgcolor="#808000" text="#FFFFFF" link="#99FF99" vlink="#FFFF00" onload="prefill();">
This trouble with visited links not staying the visited color started when I migrated my FF2 profile to FF3.
Via the GUI interface, the settings all appear to be correct.
Any ideas?
Thanks,
--
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/
> Previously someone suspected that the HTML of the page might be
> specifying a shorter history span. I know of nothing in HTML that can
> specify a length of time to display the visited color. However, here
> is the body tag from the site in question:
Need URL, not just body tag.
Visited links usually only stay that way for a day on my workstation. Of
course I shut it down every day. I'm not aware of any HTML code to
cause a reset like you experienced.
I would think that just because you visited it once during a day, it
should remain that way for the day, but not for any longer.
--
Terry R.
Anti-spam measures are included in my email address.
Delete NOSPAM from the email address after clicking Reply.
Does anyone happen to know which file keeps track of what URL's have been clicked when, and I will try deleting it and see if that fixes it.
Aaahhh, bbooo hhoooo to the FF3 designers...
http://kb.mozillazine.org/History.dat
"(Starting in Firefox 3, browsing history and bookmarks are both stored in the file places.sqlite.)"
That makes no sense at all! Should have been kept separate so the history could be blown away!
I have subscribed to this bug report against the design...
https://bugzilla.mozilla.org/show_bug.cgi?id=384420
I expect that bug is going to be rejected as written,
removing history makes no difference if it is same file as
bookmarks or not. It is a software implementation interface
that you are looking for a physical separation is not needed.
You can remove all the bookmarks you
want without touching other bookmarks. You can remove
all history or selectively yourself, so what you would actually
be looking for is some way to quickly delete history, which
as already stated in thread destroys the AwesomeBar features.
Search in History (Ctrl+H) for a string like "timefeed" and then
use Ctrl+A to select all such entries and delete (from history).
To select several entries to delete you can select
an entry by clicking to left of icon and add additional to the
selection with Ctrl+click also to the left of the icon. You can
extend a selection with Shift+click. There are several view
options with the "view" button there that might help with
your methods of selections.
--
HTH,
David McRitchie, extensions I use are briefly documented on my site
Firefox Custom: http://www.mvps.org/dmcritchie/firefox/firefox.htm
> »Q« wrote:
> > Need URL, not just body tag.
>
> http://members4.boardhost.com/RRHXHistory/
Thanks. Sorry, but I can't find anything on the page or in the http
headers that should cause what you're seeing, so I can only wish you
luck.
Well I delelted just the history though the user inteface... already links I tested on that page have changed back!
Perhaps I will test renaming my places.sqlite file and see if that doesn't fix it. Then I would have done your suggested method and that did not fix it, but my idea would have worked... We shall see.
The part quoted just refers to the bug which asks for a physically separated file,
and that is really not necessary as a database can be used for different purposes.
The history and the bookmarks are actually very similar. So if it is read as written
for a physical separation it is probably going to be rejected without regard to the
problem you want solved.
Did you by any chance change any places.frecency. settings in your about:config
from defaults. Actually would not affect links, only AwesomeBar.
Does the history in Ctrl+H actually disappear after one day.
There are bookmarklets that make all visited links on a page become not visited.
Do you have any of the extensions that show up in this Google search
site:addons.mozilla.org inurl:en-US/firefox/addon visited unvisited
like LinkVistor 2 or QuietURL
But history could be completely deleted if it were to become corrupted, bookmarks are a little more important... no?
> for a physical separation it is probably going to be rejected without
> regard to the problem you want solved.
Ah well...
And if this does solve the problem, gggggrrrr....
> Did you by any chance change any places.frecency. settings in your
> about:config
places.* are all non-bold, thus defaults
> Does the history in Ctrl+H actually disappear after one day.
I will watch. I just clicked various links on that page, and now I will not click them again.
> Do you have any of the extensions that show up in this Google search
> site:addons.mozilla.org inurl:en-US/firefox/addon visited unvisited
> like LinkVistor 2 or QuietURL
I do not think so:
AdBlock Plus
Chatzilla
FireBug
FireFTP
Web Developer
--
Ron Hunter rphu...@charter.net
Bookmarks are automatically backed up in json files, and you can restore
a backup via the Library window. Has your browsing history ever become
corrupt in Firefox 3?
--
Chris Ilias <http://ilias.ca>
List-owner: support-firefox, support-thunderbird, test-multimedia
Indeed, my idea seems correct. Steps I did:
1) I renamed off the places.sqlite file, start FF, and clicked several links on the test page. (URL above in this thread).
2) I exited FF, renamed that file as places.sqlite.TEST
3) Renamed back my production places.sqlite file
All of this was on the 30th.
Now I tested that fresh places.sqlite file I had created.
1) Renamed the test file, those links still show the visited color.
2) Renamed the production places.sqlite and the same links do not show up as the visited color.
Clearly, there is some sort of corruption in the history table. Since history and bookmarks are in the same file now, I can not solve this corruption by merely deleting the history file.
90, which I believe is the default.
> In about:config that would be browser.history_expire_days_min
Non-bold 90
> check out other browser.history_expire_ variables as well,
browser.history_expire_days;180
browser.history_expire_days.mirror;180
> such as browser.history_expire_sites which has default of 40000
> which if really low could mess things up.
> More info: site:kb.mozillazine.org -intitle:talk can't add bookmarks
browser.history_expire_sites;40000
I do not visit 40000 sites within the time period this trouble occurs in.
I am suspecting it has been corrupt since I upgraded my profile from FF2 to FF3.
I wish now that I had deleted the history file all together when upgrading my profile!
But I do not have it set that way.
So how hard would it be to harvest the bookmarks from the "production" file that has the history problem and insert just the bookmarks into a brand new places.sqlite file?
If I rename off the places.sqlite file, FF creates a new/clean one next time I fire FF up. So, how would I import the bookmarks from the broken places.sqlite into the clean/new one?
Found my answer...
"Unable to change bookmarks in FF3"
http://support.mozilla.com/tiki-view_forum_thread.php?comments_parentId=63721&forumId=1#threadId63788
I exported my bookmarks, exited FF, renamed my production places.sqlite, copied in the bookmarks.html I had exported, started FF, and it created a fresh places.sqlite from the bookmarks.html file.
Works for me!!!
And the size shrunk GREATLY! 6463488 was the old one, and with all of the bookmarks imported, the new one is only 372736.