Created attachment 59139 [details] A minimal example HTML to demonstrate the problem Version: 0.7.0 (using KDE 4.6.2) OS: Linux I just discovered this problem by chance: Let’s say I display a page (from now on called “Page A”). If I click on a link on Page A which causes Rekonq to download (not display) a file, and then cancel the resulting Save As dialog, subsequently the page in Rekonq gets locked -- I can neither click on a link nor navigate it with the Tab key. I can only reload now. This only happens though if I got to Page A using the Forward or Back function. The page does not get locked if it was loaded directly. It also happens only if I left-click the link, but not if I right-click the link and chose "Save link as". This bug also messes with the tab’s history: When Page A gets locked and I invoke Go Forward, Page B is shown, but the address bar still shows Page A’s address. Going Back to Page A now shows an empty page with the address of Page B. But reloading any of page A or B reloads the correct page as the history in my head expects, disregarding what the address bar is showing. Reproducible: Always Steps to Reproduce: - Go to a page ("page A") that has a link which Rekonq will download and not display itself (for an example see Additional Information) - go to a Page B (by clicking a link on Page A or entering another address) - go Back in the history to display Page A again - left-click on the download link, a Save As dialog appears - cancel the Save As dialog Actual Results: the page is now locked and its history is somewhat borked (described in last paragraph of Details). Expected Results: The Actual Results should not have happened. On my system, for example, Rekonq immediately shows a Save As dialog when I click on the link to a ZIP file. Hence the attached example shows the bug for me. In it, click on the first link and go Back. Now click on the ZIP link (make sure the file exists of course, e.g. by zipping the html).
Could not reproduce. Rekonq 0.6.1 KDE 4.5.5 Tested it on this page: http://www.video.auxpa.org/audio.shtml
Indeed, I can’t reproduce the lock-up on that page of yours either. Have you tried it with my minimal example? But then again, I didn’t notice similar problems before, so it might have only been introduced by 0.7. I can’t be sure of that though.
I tried here: http://www.download4a.com/Linux/Games/Sports/Install-Foobillard.html and here: http://wiki.wesnoth.org/CompilingWesnothOnWindows And it still was unreproducable, again rekonq 0.6.1, KDE 4.5.5 Perhaps this is a regression in 0.7? I could not test it with your example because test.zip doesn't exist and so no save as dialog pops up. instead, i get a "file doesn't exist" page.
My example is a minimal HTML page that was supposed to demonstate the problem locally. So you have to download it first. And because creating a ZIP file oneself is not difficult, I didn’t attach one. I could ask a friend with a similar bleeding-edge Gentoo setup whether he can confirm my problem. I first discovered it using my local apache (via http://localhost/test.html). But during writing this response I also tried it by loading the file locally (i.e. file:///home/frank/public_html/test.html). Now a click on the ZIP link opens it in Ark (I guess KDE’s inner mechanics recognise a local file and execute the default file type handler), but Rekonq still locks up the page.
O.k., Tried it again locally with the attached test page and can confirm that it is not reproducible in Rekonq 0.6.1 KDE 4.5.5.
I can confirm this with rekonq-git(>0.7.50). This bug could be related to bug 268327.
I tried with the test.html page suggested and with all the links posted here. I cannot reproduce this with: rekonq 0.8.73 qtwebkit 2.2.x kdelibs 4.8.x Closing in two weeks from now if no-one replies with a reproducible case in a similar configuration.