Bug 21250 - Rename updateContents to repaintContentRectangle and make it cross-platform
: Rename updateContents to repaintContentRectangle and make it cross-platform
Status: RESOLVED FIXED
: WebKit
Platform
: 528+ (Nightly build)
: Macintosh Mac OS X 10.5
: P2 Normal
Assigned To:
:
:
:
: 21083
  Show dependency treegraph
 
Reported: 2008-09-30 12:52 PST by
Modified: 2008-09-30 13:11 PST (History)


Attachments
Patch (24.70 KB, patch)
2008-09-30 12:56 PST, Dave Hyatt
darin: review+
Review Patch | Details | Formatted Diff | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2008-09-30 12:52:32 PST
Rename updateContents to repaintContentRectangle and make it cross-platform
------- Comment #1 From 2008-09-30 12:56:34 PST -------
Created an attachment (id=23949) [details]
Patch
------- Comment #2 From 2008-09-30 13:01:13 PST -------
(From update of attachment 23949 [details])
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 From 2008-09-30 13:05:51 PST -------
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 From 2008-09-30 13:11:31 PST -------
Fixed in r37105