Got it. Sounds good from my end. --Amanda
On Mon, May 4, 2009 at 5:08 PM, Darin Fisher <[email protected]> wrote: > Right, that's actually what I'm suggesting we aim for. When the renderer > needs to ask questions about the HWND associated with a RenderView, it can > just ask questions of the RenderViewHost. The RenderViewHost can use its > HWND to answer the questions. > The story is not quite that simple of course since we need to answer those > IPCs on a background thread and the RenderViewHost only runs on the main UI > thread. Hence, we need the map that the IO thread can interrogate. > -Darin > > On Mon, May 4, 2009 at 1:37 PM, Amanda Walker <[email protected]> wrote: >> >> Hmm. Would it be even cleaner for nothing but the plugin host process >> to care about the NativeViewId, since it's what has to provide it to >> the plugin via NPAPI? For everything else, either we're windowless >> and just shipping bitmaps around (no need for a window reference at >> all except to keep the plugin happy) or we're windowed and just need >> an ID that the plugin process can map to a "real" window reference. >> I'm not clear on why the renderer needs to track it at all (though the >> browser might, for things like the scrolling performance reparenting >> stuff) >> >> --Amanda >> >> On Mon, May 4, 2009 at 1:57 PM, Darin Fisher <[email protected]> wrote: >> > Yes, seems like it should be all around cleaner too :) >> > -Darin >> > >> > On Mon, May 4, 2009 at 9:43 AM, Adam Barth <[email protected]> wrote: >> >> >> >> I see. In this design, we would translate render_view_ids to >> >> NativeViewIds on the IO thread instead of round-tripping the UI >> >> thread. That seems workable without changing the semantics of the IPC >> >> messages. >> >> >> >> Adam >> >> >> >> >> >> On Sun, May 3, 2009 at 10:31 PM, Darin Fisher <[email protected]> >> >> wrote: >> >> > We should definitely eliminate the need for the renderer to refer >> >> > directly >> >> > to its native view. I have been gradually working in this direction. >> >> > Instead of sending view ids around, it should be enough to reference >> >> > the >> >> > render_view_id (i.e., routing_id). We don't need to graph this >> >> > mapping >> >> > onto >> >> > RendererSecurityPolicy (in fact that would definitely overload the >> >> > meaning >> >> > of renderer security policy). Instead, we should probably just build >> >> > a >> >> > new >> >> > mapping from render_view_id to object. Perhaps that mapping system >> >> > could be >> >> > used by the RendererSecurityPolicy to store security bits associated >> >> > with >> >> > the render view so that we don't need to have two maps. >> >> > I am already close to eliminating the NativeViewID parameters in the >> >> > WebKit >> >> > API. >> >> > -Darin >> >> > >> >> > On Sun, May 3, 2009 at 7:14 PM, Adam Barth <[email protected]> >> >> > wrote: >> >> >> >> >> >> Currently we have a handful of renderer -> browser IPC messages that >> >> >> contain gfx::NativeViewIds: >> >> >> >> >> >> ViewHostMsg_GetWindowRect >> >> >> ViewHostMsg_GetScreenInfo >> >> >> ViewHostMsg_GetRootWindowRect >> >> >> ViewHostMsg_GetRootWindowResizerRect >> >> >> ViewHostMsg_ScriptedPrint >> >> >> >> >> >> These make me sad because the render could ask about random >> >> >> NativeViewIds (HWNDs) that have nothing to do with that renderer. >> >> >> There are two approaches we can use to correct these infelicities: >> >> >> >> >> >> 1) Change these message to avoid sending NativeViewIds. This seems >> >> >> possible, but some unknown amount of work. >> >> >> >> >> >> 2) Add more state to RendererSecurityPolicy that tracks which >> >> >> NativeViewIds each renderer is permitted to interrogate. >> >> >> >> >> >> I'm inclined to go with (2), but I wanted to check in with Mac / >> >> >> Linux >> >> >> folks to make sure this makes sense for those platforms too. >> >> >> >> >> >> Thoughts? >> >> >> >> >> >> Adam >> >> >> >> >> >> >> >> > >> >> > >> >> > > >> >> > >> > >> > >> > >> > >> > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
