In wxWebKit the scrollbar is not reset when loading a new page. This patch fixes that.
Created attachment 21060 [details] one liner for resetting the scrollbar
Comment on attachment 21060 [details] one liner for resetting the scrollbar windowObjectCleared is definitely not the right place to be doing this. It's likely there is some underlying issue that is leading to the incorrect behaviour you're seeing -- none of the other ports call setContentsPos from within WebKit, which suggests to me that doing so for wx is papering over an issue elsewhere.
(In reply to comment #2) > (From update of attachment 21060 [details] [edit]) > windowObjectCleared is definitely not the right place to be doing this. It's > likely there is some underlying issue that is leading to the incorrect > behaviour you're seeing -- none of the other ports call setContentsPos from > within WebKit, which suggests to me that doing so for wx is papering over an > issue elsewhere. > Yeah, poking around some more, I think the real issue is that we don't handle FrameLoaderClientWx::transitionToCommittedForNewPage(), which deletes and re-creates the FrameView, and that's probably how all the other ports end up having their scroll positions reset.
Created attachment 21075 [details] new patch to fix scrolling This patch does it by implementing transitionToCommittedNewPage() so the scroll positions are reset when a new page is loaded, and also maintained so that back and next restore the scroll positions as well. This also simplifies the logic for initializing and managing wxWebView.
Comment on attachment 21075 [details] new patch to fix scrolling This does the trick! :-)
landed in r33036, thanks! :)