Re-sending. Wrong address the first time. > 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 -~----------~----~----~----~------~----~------~--~---
