24820 – visited links don't change colour until after they are hovered over with the mouse.

(*** This bug was imported into bugs.kde.org ***)
Package: khtml
Version: 3.0 (using KDE 2.1.1 )
Severity: normal
Installed from: Linux-Mandrake 8.0 i586
Compiler: gcc version 2.96 20000731 (Linux-Mandrake 8.0 2.96-0.48mdk)
OS: Linux
OS/Compiler notes: 2.4.3-ac12
Viewing web page at http://www.mail-archive.com/cooker@linux-mandrake.com/
Click with middle mouse button on any link on the page
to open it in a new window (works fine).
The clicked on link remains "blue" (virgin) instead of changing color to show that it has been visited. The next time the mouse cursor is hovered over the link it belatedly changes color (to red).
Minor nuisance.
(Submitted via bugs.kde.org)
(Called from KBugReport dialog. Fields OS manually changed)

Reproducible in 3.1rc3. 
 
 

Seems fixed in CVS 2003年11月11日

no, it's not

*** Bug 72102 has been marked as a duplicate of this bug. ***

*** Bug 72454 has been marked as a duplicate of this bug. ***

*** Bug 72454 has been marked as a duplicate of this bug. ***

using KDE 3.2RC1
the link change color perfectly, but you have to quit the selection. (click on the background.) 
when the link is no longer selected (square around it) it becomes to another color.
I think that does not even work on IE, you need to press F5, for visited links to update color. ;)
i suggest to close the bug.
the only thing that could be added is to auto unselect the link as we open a new window. which COULD be annoying. i dont know.

This is not the case for me. I browse the CVS archives at lists.kde.org daily and use middle mouse clicking/tab browsing when I see a commit which I want to read on. Currently the color of the selected link doesn't change until I remouse over it after the page on the tab has loaded (doesn't change when I deselect the link, or anything else. Usually what I have to do is after I've loaded a few links I'll move the mouse up and down the page a few times to change all the visited link's color so I know if there are any others I would like. It would be nice if the page changed color right after it is selected (after the active state color change that is).

Retested with KDE-3.2.2 (Fedora Core2-test3):
Link does not change colour until moused-over after initial selection.
Better than the original condition, but still not perfect.
Keep open, I think.

EDIT: retested with Fedora Core-2-RC1.
Link does not change colour until moused-over after initial selection.
Better than the original condition, but still not perfect.

Still valid with 3.3 Beta 1.

*** Bug 65915 has been marked as a duplicate of this bug. ***

Problem present in konqueror 3.3.1 (debian sid).
 - Link change colour if I leave mouse cursor over the link until the selection rectangle appears.
 - Link does not change color if I move mouse cursor immediately after clicking on a link (link will be then colored if i move back mouse cursor over the link).

I confirm the problem in debian sid and konqueror 3.3.1.

Still present in 3.4 beta2

bug still present for 3.4.1 using kubuntu !!

Still present in 3.4.2, Suse 9.3 rpm's.

Still present in 3.5 with Gentoo.

still valid, 3.5.2 from debian.

Created attachment 15805 [details] 
Proposed patch
I think this works.

No my patch doesn't work. It either requires a signal from the HistoryProvider to inform when the history changes, or a hack pretend the history is instantly updated when clicking a button.

SVN commit 617941 by mkoller:
BUG: 24820
immediately redraw visited links with the respective color when the page
got loaded and inserted into the history
 M +3 -3 khtml/html/html_documentimpl.cpp 
 M +1 -0 kparts/historyprovider.cpp 
 M +5 -0 kparts/historyprovider.h 
--- branches/KDE/3.5/kdelibs/khtml/html/html_documentimpl.cpp #617940:617941
@@ -78,11 +78,11 @@
 m_doAutoFill = false;
 
 /* dynamic history stuff to be fixed later (pfeiffer)
- connect( KHTMLFactory::vLinks(), SIGNAL( inserted( const QString& )),
- SLOT( slotHistoryChanged() ));
 connect( KHTMLFactory::vLinks(), SIGNAL( removed( const QString& )),
 SLOT( slotHistoryChanged() ));
 */
+ connect( KHTMLFactory::vLinks(), SIGNAL( inserted( const QString& ) ),
+ SLOT( slotHistoryChanged() ));
 connect( KHTMLFactory::vLinks(), SIGNAL( cleared()),
 SLOT( slotHistoryChanged() ));
 }
@@ -222,7 +222,7 @@
 
 void HTMLDocumentImpl::slotHistoryChanged()
 {
- if ( true || !m_render ) // disabled for now
+ if ( !m_render )
 return;
 
 recalcStyle( Force );
--- branches/KDE/3.5/kdelibs/kparts/historyprovider.cpp #617940:617941
@@ -70,6 +70,7 @@
 {
 // no need to allocate memory, we only want to have fast lookup, no mapping
 d->dict.replace( item, (void*) 1 );
+ emit inserted( item );
 }
 
 void HistoryProvider::remove( const QString& item )
--- branches/KDE/3.5/kdelibs/kparts/historyprovider.h #617940:617941
@@ -89,6 +89,11 @@
 */
 void updated( const QStringList& items );
 
+ /**
+ * Emitted after the item has been inserted
+ */
+ void inserted( const QString& item );
+
 private:
 static HistoryProvider *s_self;
 

SVN commit 628618 by savernik:
Reverting r617941. This fixes jumping to the top right before loading a
new page and also fixes page loading time increase.
Attention packagers! Please include this patch in new versions of your
khtml-3.5.6 packages. Web surfing experience can be considered broken
without it.
CCMAIL: kde-packager@kde.org
BUG: 140768
CCBUG: 140777 
CCBUG: 24820
 M +1 -1 html_documentimpl.cpp 
--- branches/KDE/3.5/kdelibs/khtml/html/html_documentimpl.cpp #628617:628618
@@ -222,7 +222,7 @@
 
 void HTMLDocumentImpl::slotHistoryChanged()
 {
- if ( !m_render )
+ if ( true || !m_render )
 return;
 
 recalcStyle( Force );

Unfixing this bug. The fix caused major performance degradation and some other quirks. Until there's an efficient solution, this bug will stay open.

SVN commit 691149 by ggarand:
revert the instantly-colored-visited-links patch in trunk too.
It does not work.
CCBUG: 24820
 M +1 -1 html_documentimpl.cpp 
--- trunk/KDE/kdelibs/khtml/html/html_documentimpl.cpp #691148:691149
@@ -216,7 +216,7 @@
 
 void HTMLDocumentImpl::slotHistoryChanged()
 {
- if ( !m_render )
+ if ( true || !m_render )
 return;
 
 recalcStyle( Force );

bug still valid for kde4

This bug is still present in svn trunk r790203.

Confirmed on Konq/4.0.3 although the behaviour is that the link changes colour once deselected (click on background).

Strange thing is, it WORKSFORME using KDE4.0.3 and Konq. 

I can confirm bug still exists with fedora 9's 4.0.3

Bug still exists with fedora 9 w/ 4.1.0... minor nuisance

Bug still exists in KDE 4.1.3, Kubuntu 8.10 packages

Still reproducible in 4.3 RC2 on Debian experimental.

Fixed in 4.4.1. Thanks!

Georg, are you sure? I still observe the reported behavior in my 4.4.3.
I’d say it’s half-fixed. Suppose I middle-click on a link on BKO, there are two possible outcomes:
- I move the mouse away from the link before the new tab is loaded. Then the link’s colour changes from :hover back to :unvisited. Only when I move over it again after the tab is loaded, it becomes :visited.
- I stay over the link, thus its colour remains :active. I wait until the tab is loaded. Then I move the mouse away from the link, and it changes from :active right to :visited.
Perhaps you have such a fast connection that the first case doesn’t occur on your system, but here it takes a few seconds until the tab is finished.

Actually, you're right. Hmm... I must've mixed up Konqueror and Firefox when testing...

Still valid in 4.5.4, updating version

11 years later, I will make the same recommendation.
close this bug

Cannot reproduce in 22.12.3, it most certainly has been fixed.