Summary: | Konqueror "restore tabs after crash" broken with webkit as default rendering engine | ||
---|---|---|---|
Product: | [Frameworks and Libraries] kwebkitpart | Reporter: | george panta <adgeruy> |
Component: | general | Assignee: | webkit-devel |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | adawit, dawan, frederic.coiffier, gkodadek, greenrd, matofesi |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Arch Linux | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
george panta
2010-08-05 01:09:25 UTC
It seems that every tab loads the url of the focused tab, ordering does not matter. This is a known issue and is the result of the difficulty we have in integrating QtWebKit's history management with that of Konqueror's. Hopefully soon I will come up with a solution that will address this problem... I see. Thanks for the clarification and for your work on this. SVN commit 1168104 by adawit: - More fixes/workaround for the history syncing issues between QtWebKit and Konqueror. This should improve restoration of content after crashes or any other abnormal shutdown of the hosting application (read: Konqueror). There is one caveat, but it is caused by the way Konqueror works and not kwebkitpart. For the details about the remaining issue, see link below: http://lists.kde.org/?l=kfm-devel&m=128275102319735&w=2. BUG:246751 M +34 -25 kwebkitpart.cpp M +3 -1 kwebkitpart.h M +43 -31 kwebkitpart_ext.cpp M +3 -2 kwebkitpart_ext.h M +38 -5 kwebkitpart_p.cpp M +3 -1 kwebkitpart_p.h M +48 -2 kwebkitpartfactory.cpp M +10 -1 kwebkitpartfactory.h M +29 -15 webpage.cpp M +5 -6 websslinfo.cpp M +2 -2 websslinfo.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1168104 *** Bug 252837 has been marked as a duplicate of this bug. *** *** Bug 258223 has been marked as a duplicate of this bug. *** *** Bug 260709 has been marked as a duplicate of this bug. *** *** Bug 250264 has been marked as a duplicate of this bug. *** *** Bug 267335 has been marked as a duplicate of this bug. *** |