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 -~----------~----~----~----~------~----~------~--~---
