Is this implemented on the Mac? This seems like a mapping from NativeViewId to whatever the Mac version of an HWND is, which sounds similar to gtk_native_view_id_manager...
Adam On Mon, May 4, 2009 at 5:55 AM, Amanda Walker <[email protected]> wrote: > The Mac needs something morally equivalent to #2 (with plugins as the > current forcing function--there's no cross-process window handle we > can use, so we need to track them ourselves anyway). I also strongly > agree that the browser needs to be able to validate which window(s) a > renderer can ask about, rather than blindly interpreting an untrusted > parameter as an HWND. > > --Amanda > > On Sun, May 3, 2009 at 10: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 -~----------~----~----~----~------~----~------~--~---
