Version: latest git snapshot (using KDE 4.6.1) OS: Linux On some websites when I click back the address in the URL bar does not change. Clicking back again changes it to an off by one address. Reproducible: Always Steps to Reproduce: Go to http://cdimage.ubuntu.com/ click kubuntu then daily click back click back again Actual Results: On the first back, the URL bar remains at /kubuntu/daily/ On the second back, the URL bar remains at /kubuntu/ Expected Results: On the first back, the URL bar should be /kubuntu/ On the second back, the URL bar should be /
Confirmed, targeting to 0.7
Sorry, this does not happen here.
This may be connected to bug 260844. I can confirm this on rekonq and arora, so I guess this is an upstream bug.
Created attachment 58521 [details] working testcase I did some investigations on that bug. When I click the back button, MainWindow::openPrevious is called. Here, a QWebHistoryItem is created, which has the right url. With this item, QWebHistory::goToItem is called. When MainView::webViewUrlChanged(const QUrl&) is called by the QWebView::urlChanged signal, the url has changed to the wrong one (e.g. before "http://cdimage.ubuntu.com/kubuntu/", now "http://cdimage.ubuntu.com/kubuntu/daily/"). I could not reproduce this with a similar testcase (attached), so somewhere that url was changed or my testcase is different from this situation. My system: KDE 4.6.1 Qt 4.7.2 GCC 4.5.2 Arch Linux 64bit
I can reproduce this with rekonq 0.7.0 (Kubuntu Natty) while working through the Rails "getting started" guide (http://guides.rubyonrails.org/getting_started.html). Halfway through section 4.3 of the guide, I go through the following set of URLs: 1. localhost:3000 (Error: no route matches "/") 2. localhost:3000/home (Error: no route matches "/home") 3. localhost:3000/home/index (valid page is rendered) When I go back from the third step (either with alt-left or by clicking on the back button in the toolbar), the page is rerendered, but the location bar lags by one step. (I.e., when I go back from step 3. to 2., it's still showing "localhost:3000/home/index", and when I go back to step 1., it shows "localhost:3000/home".)
In my test case, the key is that a page returns an error (404 for step 1 and 2). This is confirmed by the fact that when I add a route so that "localhost:3000" matches a valid page, only going back from step 3 to 2 fails to update the location bar, because that page is still a 404. Going back to step 1 is now a valid page (200), and the location is updated correctly.
Targetting 0.8, but I really never could reproduce it. Can you test it again, please?
I'm still able to reproduce it.
Ah.. found the culprit! I can reproduce it against QtWebkit 2.0.x but NOT against QtWebKit 2.2. Targetting as RESOLVED -> UPSTREAM.