Bug 24820 - visited links don't change colour until after they are hovered over with the mouse.
Summary: visited links don't change colour until after they are hovered over with the ...
Status: REOPENED
Alias: None
Product: konqueror
Classification: Applications
Component: khtml part (show other bugs)
Version: 4.5.4
Platform: Compiled Sources Linux
: LO minor with 535 votes (vote)
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
: 65915 72102 (view as bug list)
Depends on:
Blocks:
 
Reported: 2001-04-26 15:33 UTC by mlord
Modified: 2015-03-22 00:26 UTC (History)
12 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Proposed patch (733 bytes, patch)
2006-04-28 02:08 UTC, Allan Sandfeld
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mlord 2001-04-26 15:27:56 UTC
(*** 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)
Comment 1 Jim Dabell 2002-11-14 15:50:21 UTC
Reproducible in 3.1rc3. 
 
 
Comment 2 Luis Carvalho 2003-11-27 21:43:59 UTC
Seems fixed in CVS 2003-11-11
Comment 3 Leo Savernik 2003-12-15 18:56:05 UTC
no, it's not
Comment 4 Maksim Orlovich 2004-01-07 22:45:03 UTC
*** Bug 72102 has been marked as a duplicate of this bug. ***
Comment 5 Stephan Kulow 2004-01-12 13:53:33 UTC
*** Bug 72454 has been marked as a duplicate of this bug. ***
Comment 6 Stephan Kulow 2004-01-12 17:27:55 UTC
*** Bug 72454 has been marked as a duplicate of this bug. ***
Comment 7 Mathieu Jobin 2004-02-03 00:25:56 UTC
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.

Comment 8 Sean Lynch 2004-03-12 04:13:27 UTC
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).
Comment 9 mlord 2004-05-10 21:37:14 UTC
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.
Comment 10 mlord 2004-05-10 22:16:37 UTC
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.
Comment 11 Michael Jahn 2004-07-09 21:42:57 UTC
Still valid with 3.3 Beta 1.
Comment 12 Jo Øiongen 2004-07-16 13:00:58 UTC
*** Bug 65915 has been marked as a duplicate of this bug. ***
Comment 13 David Coulm 2004-11-14 12:28:14 UTC
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).

Comment 14 GML 2004-11-14 13:12:03 UTC
I confirm the problem in debian sid and konqueror 3.3.1.
Comment 15 Vedran Ljubovic 2005-02-14 12:49:43 UTC
Still present in 3.4 beta2
Comment 16 lexual 2005-08-10 05:44:02 UTC
bug still present for 3.4.1 using kubuntu !!
Comment 17 Andrey Nikanorov 2005-08-17 15:20:20 UTC
Still present in 3.4.2, Suse 9.3 rpm's.
Comment 18 Neil Skrypuch 2006-01-09 22:57:48 UTC
Still present in 3.5 with Gentoo.
Comment 19 lexual 2006-04-27 05:50:47 UTC
still valid, 3.5.2 from debian.
Comment 20 Allan Sandfeld 2006-04-28 02:08:18 UTC
Created attachment 15805 [details]
Proposed patch

I think this works.
Comment 21 Allan Sandfeld 2006-06-17 23:49:44 UTC
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.
Comment 22 Martin Koller 2006-12-30 17:52:04 UTC
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;
 
Comment 23 Leo Savernik 2007-01-30 18:25:40 UTC
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 );
Comment 24 Leo Savernik 2007-01-30 18:32:11 UTC
Unfixing this bug. The fix caused major performance degradation and some other quirks. Until there's an efficient solution, this bug will stay open.
Comment 25 Germain Garand 2007-07-23 03:10:24 UTC
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 );
Comment 26 lexual 2007-12-13 00:05:34 UTC
bug still valid for kde4
Comment 27 George Goldberg 2008-04-03 12:46:48 UTC
This bug is still present in svn trunk r790203.
Comment 28 Martin Fitzpatrick 2008-04-05 20:38:15 UTC
Confirmed on Konq/4.0.3 although the behaviour is that the link changes colour once deselected (click on background).
Comment 29 theron 2008-05-16 07:48:01 UTC
Strange thing is, it WORKSFORME using KDE4.0.3 and Konq. 
Comment 30 lexual 2008-05-18 03:45:25 UTC
I can confirm bug still exists with fedora 9's 4.0.3
Comment 31 Romain GUINOT 2008-08-20 22:34:59 UTC
Bug still exists with fedora 9 w/ 4.1.0... minor nuisance
Comment 32 Stephan Wassipaul 2008-12-28 15:27:34 UTC
Bug still exists in KDE 4.1.3, Kubuntu 8.10 packages
Comment 33 Georg Wittenburg 2009-07-22 09:18:02 UTC
Still reproducible in 4.3 RC2 on Debian experimental.
Comment 34 Georg Wittenburg 2010-03-07 09:11:08 UTC
Fixed in 4.4.1. Thanks!
Comment 35 Frank Steinmetzger 2010-05-30 20:37:04 UTC
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.
Comment 36 Georg Wittenburg 2010-05-31 11:39:50 UTC
Actually, you're right. Hmm... I must've mixed up Konqueror and Firefox when testing...
Comment 37 Samuel Brack 2010-12-31 16:17:35 UTC
Still valid in 4.5.4, updating version
Comment 38 Mathieu Jobin 2015-03-22 00:26:02 UTC
11 years later, I will make the same recommendation.

close this bug