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