Version: (using Devel) OS: Linux Installed from: Compiled sources If the Link for the "View full version" contains a #-character, the link can not be opened in a external browser (Open in a internal tab works). For example "welt.de" adds #reqRSS to its links. The welt.de RSS-Feed can be found under http://www.welt.de/?service=Rss.
Should be fixed by 873506 (for trunk, and around that time also for the 4.1 branch (>= 4.1.3)), escaping links passed to the external browser should be correct since then. Your example works for me. Which version do you use? Reopen if you can reproduce this problem with more recent builds.
Hi Frank, thank you for your reply. Rev 873506 is of Oct 19th. I'm using the openSUSE packages from the UNSTABLE repo which are quite near to trunk. I can still reproduce this with the latest packages (4.1.87 (KDE 4.2 >= 20090101)).
Ok, I just compiled Akregator from SVN-Trunk. And could reproduce it again, BUT... ... I found out, it only happens if set the "open external"-command as left-click action. If I choose "open in external browser" from the context-menu it now seems to work (This way it works in the packaged version, too).
Confirmed. Apparently this is an issue in KHTMLPart, or in how we use it. See also http://bugs.kde.org/show_bug.cgi?id=180789 Needs further investigation.
Found the reason for this: We pass the link's article to KHTMLPart::begin() when rendering the article, which in turn does KHTMLPart::setUrl() telling the KHTMLPart that it currently shows that URL. Unfortunately this is required to make relative links inside the article work. But as the KHTMLPart now thinks it is already showing the linked website and the clicked link is the same URL and an anchor #foo, it doesn't load the page but tries to jump to the anchor #foo in the currently displayed HTML, which of course fails. Not sure how to fix this without breaking relative links. One workaround might be to pass the URL to begin() without the file: "http://www.welt.de/politik/article3087972/" instead of "http://www.welt.de/politik/article3087972/Atheismus-Werbung-erobert-den-Globus.html#reqRSS". That should keep relative links working. That'd need good testing though, to avoid regressions.
Omitting the filename seems dangerous (as it's not always clear whether it's a filename or a directory). Adding a bogus query item to the preview URL seems to work.
SVN commit 916644 by osterfeld: fix Complete Story link if the link contains an anchor. We must tell KHTMLPart that it shows the linked item to make relative links work, but that in turn breaks in the presence of an anchor (as KHTMLPart tries to simply jump to the anchor instead of opening the website). Workaround: adding a bogus query item makes the two URLs different for the anchor check but keeps the relative link resolution working. BUG:177754 BUG:180789 _M . (directory) M +9 -1 akregator/src/articleviewer.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=916644
SVN commit 916646 by osterfeld: backport: SVN commit 916644 by osterfeld: fix Complete Story link if the link contains an anchor. We must tell KHTMLPart that it shows the linked item to make relative links work, but that in turn breaks in the presence of an anchor (as KHTMLPart tries to simply jump to the anchor instead of opening the website). Workaround: adding a bogus query item makes the two URLs different for the anchor check but keeps the relative link resolution working. CCBUG:177754 CCBUG:180789 M +9 -1 articleviewer.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=916646