[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: History continued....
From:       David Faure <david () mandrakesoft ! com>
Date:       2000-10-01 11:39:38
[Download RAW message or body]

On Sat, 30 Sep 2000, Waldo Bastian wrote :
>First of all thank you David and Simon for your explanations.
>Due to them I managed to find the following problem:
>When KHTMlPart::openURL is called it doesn't directly change the URL (m_url). 
>It delays that to begin(). When you select "back" very fast what happens is 
>that basically openURL() is called twice in a row, and only in the end 
>begin() is called. And to make it worse, before the second openURL() is 
>called, saveState() is called as well. Visually:
>
>If the history looks like: url1, url2, url3.
>
>*user presses back (1st)*
>*user presses back (2nd)*
>saveState() m_url == url3
>openURL(url2)
>saveState() m_url == url3
>openURL(url1)
>begin() m_url = url1

Eeek.

>After this the history is sort of corrupted because when you now go forward 
>again you end up with the content of url2 being reported as url3.
>
>The patch below made way back in May seems to cause this.
>When you revert it (and don't forget to do the same in the new restoreURL() 
>as well!) things work much better when going through the history fast.
>Obviously this patch was done for a reason, but I don't know which "relative 
>links" it was supposed to fix. (HTTP Redirections??)

No, any relative link on the page. Like most links on www.kde.org, which look like
"announcements/index.html" or "blah.html" and are relative to the URL of the page,
i.e. http://www.kde.org/.

The reason for the patch is that without it, if you are on www.kde.org, then click a link
to some other website (say, developer.kde.org), and then _quickly_, before the new
page starts being rendered, you click on a relative link in the current page,
it will be interpreted as relative to developer.kde.org, which is obviously wrong.

>I would like to revert the patch and fix these rrelative links in some other 
>way. Maybe by introducing m_referrer_url to kparts?

We could have a m_workingURL, like in some previous version of khtml IIRC.
It would point to the new URL we are loading, and be copied into m_url only in begin().
But then the steps above would still saveState() on a wrong URL.
[So in fact m_workingURL is worth nothing :)]

In fact, it looks like saveState should do nothing if we haven't even started to 
render the page. IIRC we have a bool for that, that says if we started to do anything or not.
If we are just going back very quickly in the history, then we don't want saveState to
change anything to the history that we have for this intermediate page.

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://www.mandrakesoft.com/~david/, http://www.konqueror.org/
KDE, Making The Future of Computing Available Today
See http://www.kde.org/kde1-and-kde2.html for how to set up KDE 2

[prev in list] [next in list] [prev in thread] [next in thread]