Look at base/gfx/gtk_native_view_id_manager -- it implements #2 for GTK. I like both approaches, but would really prefer #1. Adam implemented #2 in part for security but also in part because our initialization order made it a pain to have a native view id handy at the point the render view is getting created (which is where all these ViewHostMsg messages get their arguments from).
It may be the case that none of those listed calls *should* need to specify a window -- we know which renderer they're calling from so we can map that back to the implicit current window. (Maybe you can get window info from windows you've spawned, though...) 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 -~----------~----~----~----~------~----~------~--~---
