Bug 21250

Created attachment 23949 [details] Patch

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

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).

Fixed in r37105