Version: (using KDE KDE 3.4.0) Installed from: Debian testing/unstable Packages OS: Linux There are many bug reports related to anchors not working in past versions of Konqueror. I believe this report is unique because it only happens inside a frame and I'm pretty sure it's new with 3.4. Details: If a page loaded inside a frame has a link of the form #frag or doc.html#frag, clicking the link will not scroll to the position of the fragment. Right-clicking inside the frame and choosing "Frame -> Open in This Window" will jump to the expected location. I have narrowed this down to a very small test case, which I will attach to the bug, or you can follow these instructions to reproduce the problem: 1. Vist http://java.sun.com/j2se/1.4.2/docs/api/ 2. Click a class name in the lower left hand frame (e.g. AWTEvent) 3. Scroll down to the Field Summary section and click on a field name (e.g. ACTION_EVENT_MASK) 4. Note that the link does not work. 5. Now right click in the frame and choose Frame -> Open in This Window 6. Note that the frame is now displaying the ACTION_EVENT_MASK detail section.
Created attachment 10752 [details] Bug-104396.zip These very small files demonstrate the problem as simply as possible. Unzip the archive, then view the file Bug-104396/index.html. Note that neither of the two links appears to work. However, right-click -> Frame -> Show in This Window jumps to the correct location.
Additional notes: this may be a duplicate of Bug 79726, but since the test URL for that bug no longer exists, I can't confirm that it's the same problem, hence the new bug. My KDE 3.4 packages came from http://pkg-kde.alioth.debian.org/kde-3.4.0/ but I also saw this problem on my previous compiled-with-konstruct setup.
This problem looks very similar to the one reported in Bug 48071 and I believe it is a duplicate. I doubt that the use of frames is the cause of the problem. When I follow your instructions and wait until the frame for AWTEvent is completely loaded the anchor does work. When I click on ACTION_EVENT_MASK as fast as I can, loading the frame is stopped and the anchor won't work. Which is exactly the same problem as reported in Bug 48071.
This bug is not the same as Bug 48071. It never happens without frames, always happens with frames. Also, it does happen (for me, on KDE 3.4.0) after the page is fully loaded - my attached test page has less than 30 lines of HTML with no images, so it loads pretty much instantly, and just to be sure I waited a while after the spinning KDE gear stopped moving to make sure the page as finished rendering before clicking the link. HOWEVER, it does seem to be related to something in my settings, as a new test user with no ~/.kde or ~/.kderc does not see the problem. I'll narrow it down further when I get a chance and update the bug.
I initially only tried to reproduce the problem with java.sun.com, not with your testcase. The site takes a while to load so that's why it looked like bug 48071 to me. I tried your testcase now and I think you are right that this is another problem. Note that I could not reproduce the bug with your testcase (with a recent CVS build).
OK, new information. I narrowed down the configuration issue needed to trigger this bug and it turns out you can only reproduce the bug if you have the line cache=Reload in your ~/.kde/share/config/kio_httprc file. Without cache=Reload, anchor links work fine; with cache=Reload, anchor links inside frames don't work. My Kanotix system has an /etc/skel directory (from which new user accounts are initialized) that contains /etc/skel/.kde including kio_httprc with the setting, which is why at first I was seeing the problem even for newly created users. Perhaps someone with rights could change the title of the bug to this: cache=Reload breaks anchor links inside frames
Jesse, can you reproduce this problem with KDE 3.5? It seems to work fine here
Philip, I don't at the moment have access to a KDE 3.5 build to re- test with. But did you make sure to test with cache=Reload in your kio_httprc file? See Comment #6 - this configuration is necessary to reproduce the bug. I'll check back in when I've had a chance to test it myself with 3.5.
Jesse, any update on this?
Could you change the title of the bug to "cache=Reload breaks Anchor links inside a frame"? (see comment 4 and step 1 of the HTR below.) Thanks. I just tested and found that half of the bug is gone in KDE 3.5.4, and also that the cache=Reload setting which causes this bug is not (currently) accessible via the GUI, so probably most users will never see this. See discussion below. First of all, here's a more explicit HTR: 1. Setup: edit ~/.kde/share/config/kio_httprc to ensure you have the setting "cache=Reload" 2. (Re-)start konqueror with this new setting 3. In konqueror, open index.html from this bug's attachment (id=10752) 4. Click "link to same page". Expected behavior: browser window scrolls down to reveal the text "target" at the bottom of the page. 5. Click back 6. Click "link to different page". Expected behavior: browser goes to a new page with the text "This is Frame 2" at the top, and scrolls down to reveal the text "target" at the bottom of the page. Actual behavior in KDE 3.4.3: 4. Nothing happens. 6. Browser goes to new page "This is Frame 2" but does not scroll down to target. Actual behavior in KDE 3.5.4: 4. browser scrolls down to target, as expected - this test is fixed 6. Browser goes to new page "This is Frame 2" but does not scroll down to target Discussion of cache=Reload: It turns out that the GUI for this setting is in Settings -> Configure Konqueror -> Cache -> Policy. The 3 settings for this option in both KDE 3.4.3 and KDE 3.5.4 are "Keep Cache in Sync", "Use cache whenever possible", and "Offline browsing mode", which set the cache property in kio_httprc to Refresh, Cache, and CacheOnly. These values correspond to 3 of the 5 possible values for the enum CacheControl in kdelibs/kio/kio/global.h (line 327). The setting that causes the bug is cache=Reload, with the following comment in the source code: "Always fetch from remote site." Maybe cache=Reload was once the way to turn off caching, and maybe at some point cache=Reload was deprecated in favor of a new setting UseCache=false? In any case, there's no GUI for it now, but some users may have this setting anyway, either because they upgraded from an old version of KDE which did provide a setting for it, or because their OS distribution had a stock kio_httprc with that value in it.
See also comment 6 on bug 125034. I can't tell if these two are duplicates though. Anyone?
I wasn't able to reproduce Bug 125034, but it doesn't sound like a duplicate of this bug to me, since it doesn't involve frames or the cache=Reload setting. For this bug, though, I've now tested with KDE 3.5.5 and can still reproduce the problem every time. I've put test case 2 (the one that's still broken) up on a web page so anyone can reproduce it without having to unzip the bug attachment: http://bug104396.web19.eml.cc/
Retitling as requested in comment 10
Nice testcase, Jesse. I can reproduce with "cache=Reload" in kio_httprc. When I remove that setting it works
I too can confirm this with "cache=Reload" in kio_httprc.
I can't reproduce this in 3.5.9 or svn trunk r795406, using the instructions/testcase from comment #12 .
I can still reproduce this in 3.5.9 and trunk r798768 when setting cache=Reload in kio_httprc.
Message from the Bugsquad and Konqueror teams: This bug is closed as outdated, as we do not have the manpower to maintain the KDE3 version anymore. If you still can reproduce this issue with Konqueror 4.8.4 or later, please open a new report. Thank you for your understanding.