From c82916e053ca985f88ac8daf3e5ff4feef2d27d3 Mon Sep 17 00:00:00 2001 From: "bzbarsky%mit.edu" Date: Wed, 22 Feb 2006 05:09:01 +0000 Subject: [PATCH] Changing comment, since I figured out why we're doing things in a wacky way. No bug. --- xpfe/appshell/src/nsContentTreeOwner.cpp | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/xpfe/appshell/src/nsContentTreeOwner.cpp b/xpfe/appshell/src/nsContentTreeOwner.cpp index d5bf4c5d1c05..61d756a024f6 100644 --- a/xpfe/appshell/src/nsContentTreeOwner.cpp +++ b/xpfe/appshell/src/nsContentTreeOwner.cpp @@ -124,8 +124,14 @@ NS_INTERFACE_MAP_BEGIN(nsContentTreeOwner) NS_INTERFACE_MAP_ENTRY(nsIWebBrowserChrome2) NS_INTERFACE_MAP_ENTRY(nsIInterfaceRequestor) NS_INTERFACE_MAP_ENTRY(nsIWindowProvider) - // XXXbz why not just implement those interfaces directly on this object? - // Should file a followup and fix. + // NOTE: This is using aggregation because there are some properties and + // method on nsIBaeWindow (which we implement) and on nsIEmbeddingSiteWindow + // (which we also implement) that have the same name. And it just so + // happens that we want different behavior for these methods and properties + // depending on the interface through which they're called (SetFocus() is a + // good example here). If it were not for that, we could ditch the + // aggregation and just deal with not being able to use NS_DECL_* macros for + // this stuff.... NS_INTERFACE_MAP_ENTRY_AGGREGATED(nsIEmbeddingSiteWindow, mSiteWindow2) NS_INTERFACE_MAP_ENTRY_AGGREGATED(nsIEmbeddingSiteWindow2, mSiteWindow2) NS_INTERFACE_MAP_END