24820 2001-04-26 15:33:01 +0000 visited links don't change colour until after they are hovered over with the mouse. 2023-12-26 16:52:29 +0000 1 1 2 Applications konqueror khtml part 4.5.4 Compiled Sources Linux RESOLVED FIXED LO minor --- 1 mlord konqueror-bugs-null arthur bluedzins code dev+kde georg.wittenburg grundleborg kde kde l.savernik lex.lists opensource romainguinot samuel.brack 535 oldest_to_newest 29996 0 mlord 2001-04-26 15:27:56 +0000 (*** 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) 105603 1 jim 2002-11-14 15:50:21 +0000 Reproducible in 3.1rc3. 180960 2 lpassos 2003-11-27 21:43:59 +0000 Seems fixed in CVS 2003-11-11 186349 3 l.savernik 2003-12-15 18:56:05 +0000 no, it's not 192634 4 maksim 2004-01-07 22:45:03 +0000 *** Bug 72102 has been marked as a duplicate of this bug. *** 194083 5 coolo 2004-01-12 13:53:33 +0000 *** Bug 72454 has been marked as a duplicate of this bug. *** 194146 6 coolo 2004-01-12 17:27:55 +0000 *** Bug 72454 has been marked as a duplicate of this bug. *** 201186 7 opensource 2004-02-03 00:25:56 +0000 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. 214534 8 techniq35 2004-03-12 04:13:27 +0000 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). 230532 9 mlord 2004-05-10 21:37:14 +0000 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. 230561 10 mlord 2004-05-10 22:16:37 +0000 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. 247252 11 michael.jahn 2004-07-09 21:42:57 +0000 Still valid with 3.3 Beta 1. 249312 12 jo.oiongen 2004-07-16 13:00:58 +0000 *** Bug 65915 has been marked as a duplicate of this bug. *** 285662 13 bugs.kde.org 2004-11-14 12:28:14 +0000 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). 285676 14 gmludo 2004-11-14 13:12:03 +0000 I confirm the problem in debian sid and konqueror 3.3.1. 313926 15 vljubovic 2005-02-14 12:49:43 +0000 Still present in 3.4 beta2 364296 16 lex.lists 2005-08-10 05:44:02 +0000 bug still present for 3.4.1 using kubuntu !! 366343 17 nikanorov 2005-08-17 15:20:20 +0000 Still present in 3.4.2, Suse 9.3 rpm's. 404885 18 kde 2006-01-09 22:57:48 +0000 Still present in 3.5 with Gentoo. 434302 19 lex.lists 2006-04-27 05:50:47 +0000 still valid, 3.5.2 from debian. 434623 20 15805 kde 2006-04-28 02:08:18 +0000 Created attachment 15805 Proposed patch I think this works. 447455 21 kde 2006-06-17 23:49:44 +0000 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. 496992 22 martin 2006-12-30 17:52:04 +0000 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; 505251 23 l.savernik 2007-01-30 18:25:40 +0000 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 ); 505257 24 l.savernik 2007-01-30 18:32:11 +0000 Unfixing this bug. The fix caused major performance degradation and some other quirks. Until there's an efficient solution, this bug will stay open. 537530 25 germain 2007-07-23 03:10:24 +0000 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 ); 562736 26 lex.lists 2007-12-13 00:05:34 +0000 bug still valid for kde4 591422 27 grundleborg 2008-04-03 12:46:48 +0000 This bug is still present in svn trunk r790203. 591981 28 martin.fitzpatrick 2008-04-05 20:38:15 +0000 Confirmed on Konq/4.0.3 although the behaviour is that the link changes colour once deselected (click on background). 601507 29 foureyes779 2008-05-16 07:48:01 +0000 Strange thing is, it WORKSFORME using KDE4.0.3 and Konq. 602027 30 lex.lists 2008-05-18 03:45:25 +0000 I can confirm bug still exists with fedora 9's 4.0.3 639575 31 romainguinot 2008-08-20 22:34:59 +0000 Bug still exists with fedora 9 w/ 4.1.0... minor nuisance 688307 32 wassipaul 2008-12-28 15:27:34 +0000 Bug still exists in KDE 4.1.3, Kubuntu 8.10 packages 796368 33 georg.wittenburg 2009-07-22 09:18:02 +0000 Still reproducible in 4.3 RC2 on Debian experimental. 929839 34 georg.wittenburg 2010-03-07 09:11:08 +0000 Fixed in 4.4.1. Thanks! 970395 35 dev+kde 2010-05-30 20:37:04 +0000 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. 970784 36 georg.wittenburg 2010-05-31 11:39:50 +0000 Actually, you're right. Hmm... I must've mixed up Konqueror and Firefox when testing... 1066175 37 samuel.brack 2010-12-31 16:17:35 +0000 Still valid in 4.5.4, updating version 1506706 38 opensource 2015-03-22 00:26:02 +0000 11 years later, I will make the same recommendation. close this bug 2276627 39 arthur 2023-12-26 16:52:29 +0000 Cannot reproduce in 22.12.3, it most certainly has been fixed. 15805 2006-04-28 02:08:18 +0000 2006-04-28 02:08:18 +0000 Proposed patch anchor-update.diff text/plain 733 kde SW5kZXg6IGh0bWwvaHRtbF9pbmxpbmVpbXBsLmNwcAo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBodG1sL2h0bWxf aW5saW5laW1wbC5jcHAJKHJldmlzaW9uIDUzNDc3OCkKKysrIGh0bWwvaHRtbF9pbmxpbmVpbXBs LmNwcAkod29ya2luZyBjb3B5KQpAQCAtMTUxLDExICsxNTEsMTEgQEAKIAkgICAgLy8gIyMjIGFs c28gY2hlY2sgaWYgZm9jdXNlZCBub2RlIGlzIGVkaXRhYmxlIGlmIG5vdCBpbiBkZXNpZ25tb2Rl LAogCSAgICAvLyBhbmQgcHJldmVudCBsaW5rIGxvYWRpbmcgdGhlbiAoTFMpCiAJICAgIGlmIChn ZXREb2N1bWVudCgpLT52aWV3KCkgJiYgIWdldERvY3VtZW50KCktPmRlc2lnbk1vZGUoKSkgewot CSAgICAgIGlmIChrKSAKLQkJY2xpY2soKTsKLQkgICAgICBlbHNlCi0JCWdldERvY3VtZW50KCkt PnZpZXcoKS0+cGFydCgpLT4KLQkJICAgIHVybFNlbGVjdGVkKCB1cmwsIGJ1dHRvbiwgc3RhdGUs IHV0YXJnZXQgKTsKKwkgICAgICAgaWYgKGspCisJCSAgY2xpY2soKTsKKwkgICAgICAgZWxzZQor CQkgIGdldERvY3VtZW50KCktPnZpZXcoKS0+cGFydCgpLT51cmxTZWxlY3RlZCggdXJsLCBidXR0 b24sIHN0YXRlLCB1dGFyZ2V0ICk7CisgICAgICAgICAgICAgICBzZXRDaGFuZ2VkKCk7CiAJICAg IH0KICAgICAgICAgfQogICAgICAgICBldnQtPnNldERlZmF1bHRIYW5kbGVkKCk7Cg==