FrameView and navigation
Visiting a site can have certain changes on a FrameView that will not be undone when leaving it. The most prominent example is a fixed background (by CSS) which will disable using blit on scrolling. There might be different things as well. Another one would be the PageCache and navigation to pages in it. The result is that for every page navigation you will create a new FrameView. For most/all ports this is done in FrameLoaderClient::transitionToCommittedForNewPage(). There is even a convience method shared between most ports in the form of Frame::createView.
From an API point of view this means that there is one WebKitWebView (in terms of Gtk+) and this WebKitWebView has one WebCore::Page and this page has exactly one WebCore::Frame the so called mainFrame but throughout the lifetime of WebKitWebView there will be multiple instances of FrameView’s setup on the WebCore::Frame mainFrame. This also means that there are times were multiple WebCore::FrameView instances are around but only one should be active at a time.
For WebKit/GTK+ we will need to make sure that all the state of a WebKitWebView is transferred/set to the WebCore::FrameView when it gets created and ever change to a WebKitWebView gets forwarded to it. The most prominet state information are colors and GtkAdjustment (another posting). I think Gustavo is also about to introduce Scrollbar policies soon.