Bug 21250

Summary: Rename updateContents to repaintContentRectangle and make it cross-platform
Product: WebKit Reporter: Dave Hyatt <hyatt>
Component: PlatformAssignee: Dave Hyatt <hyatt>
Status: RESOLVED FIXED    
Severity: Normal CC: darin
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Mac   
OS: OS X 10.5   
Bug Depends on:    
Bug Blocks: 21083    
Attachments:
Description Flags
Patch darin: review+

Description Dave Hyatt 2008-09-30 12:52:32 PDT
Rename updateContents to repaintContentRectangle and make it cross-platform
Comment 1 Dave Hyatt 2008-09-30 12:56:34 PDT
Created attachment 23949 [details]
Patch
Comment 2 Darin Adler 2008-09-30 13:01:13 PDT
Comment on attachment 23949 [details]
Patch

I don't understand why Chrome is derived from HostWindow. That doesn't make sense to me. I could see why Chrome would *have* a HostWindow* stored in it, but it seems really strange to derive it from HostWindow. Maybe the right thing would be private inheritance? Adding these new virtual functions to Chrome makes it harder to understand the purpose of the Chrome class.

This new window-repaint-related stuff seems way too low level to me to be a good addition to ChromeClient, but I guess it already had all this "backing store" stuff in it.

r=me
Comment 3 Dave Hyatt 2008-09-30 13:05:51 PDT
Darin:

The point is to allow ScrollView to communiate via an interface in the *platform* layer, even though what really has to happen is that the interface calls out (over in the page layer).

HostWindow <-> Chrome is basically analogous to:

ScrollView <-> FrameView

Right now ScrollView violates the platform/ layer abstraction all over the place by casting itself to FrameView and manually grabbing the ChromeClient.  This new HostWindow object will enable ScrollView to remain a platform/ abstraction.

It may be that there should be a ChromeWindow and ChromeWindowClient instead of a Chrome and ChromeClient, but looking at Chrome, the majority of functions defined on it are window-related.

One final point: the number of functions defined on Chrome should actually *shrink* by the time I'm done with this refactoring, since all of those backing store functions are going to go away (and/or be replaced).

Comment 4 Dave Hyatt 2008-09-30 13:11:31 PDT
Fixed in r37105