Bug 14729

Due to CSS Frame's can overlap. This means one would have to make sure to deliver expose events in the same z-order as the one of the Render Tree and to get alpha between overlapping frames right. The planned solution to this issue is the following: -Make Frame's not use any Gdk/Gtk resources -Create the FrameView on demand from within the FrameLoaderClientGdk -Make ScrollView not use any Gdk/Gtk resources and follow the Windows and Qt design which involves fixing PlatformScrollbar and properly implementing the HitEvent in a way robust across different styles/themes. The biggest issue with FrameView's will be handling GtkAdjustment to the outside and drawing scrollbars. E.g. the WebKitGtkPage will get gtk_widget_set_scroll_adjustments called and these need to be forwarded to the FrameView (everytime the FrameView gets created). -Make WebKitGtkPage something like a GtkDrawable and have a GdkWindow of the size of the viewport. All ScrollView's need to track there current scroll offset and relative position in their parent. ScrollView::update and the other invalidate methods need to invalidate the right rect of the outer GtkDrawable of the WebKitGtkPage. -WebKitGtkPage should behave like a GtkLayout and be embedable in a GtkScrolledWindow -ScrollView::addWidget should continue to work to allow embedding plugins at one point in time. -Big question of addWidget for ScrollView's is who is going to create the scrollbars? Who is going to forceLayout when we show/hide scrollbars?