Question about behavior of history navigation in restored konqueror instances...

[Dawit A]

Hello,

I have a question about Konqueror's method history restoration after
abnormal termination. Specifically I am trying to understand the purpose of
HistoryEntry's reload flag which prevents a part's restoreState function
from being invoked if history navigation was restored say after a crash.
This flag was introduced with commit -r873000 in konqview.cpp.

After that commit only the history state for last url visited will be
properly restored fully. All other restored history item s will have their
"reload" flag set to false when they are reloaded in HistoryEntry::loadItem
(konqview.cpp). That in turn will ensure that the embedded part's
"restoreState" function is never invoked when the user starts navigating
back and forth through history items (see line #811).

As such, history navigation will behave completely differently on
restored Konqueror session than a normally started one. In normally started
Konqueror instances, history navigation will always call restoreState(...)
where as in restored instances that function is only called for the first
item restored. Afterwards all history navigation will end up calling
openUrl(...) as if the user entered a new url into the location bar.

My question the is, was this done intentionally ? If so why ? To speed
up restoration as seems to be indicated from the commit log of r873000 ?

Regards,
Dawit A.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20100825/ff38cec5/attachment.htm>