Minimal Chrome Frame with Aura.

ipc/ipc_message_utils.h

Index: ipc/ipc_message_utils.h
diff --git a/ipc/ipc_message_utils.h b/ipc/ipc_message_utils.h
index fc72210059e2f939f0510251f3569715f4ec96f6..c775d8da00ebf29f08b8b96d0da84dafccc151be 100644
--- a/ipc/ipc_message_utils.h
+++ b/ipc/ipc_message_utils.h
@@ -475,6 +475,13 @@ struct SimilarTypeTraits<base::PlatformFileError> {
   typedef int Type;
 };
 
+#if defined(OS_WIN)
+template <>
+struct SimilarTypeTraits<HWND> {
+  typedef HANDLE Type;

[jam, 2013/02/27 20:35:34]

we already send HWNDs in IPCs, so I'm not sure why this is needed? i.e. see
https://code.google.com/p/chromium/codesearch#chromium/src/ipc/ipc_message_ut...

an example ipc that looks like it's already sent in win aura:
PluginProcessHostMsg_PluginWindowDestroyed

or is this needed now because you removed the entry for gfx::PluginWindowHandle
?

[grt (UTC plus 2), 2013/02/28 02:48:41]

That code sends HANDLEs, not HWNDs. In practice, they're the same thing, but I
believe that macro magic makes them distinct types (at least in debug builds) to
help catch developer mistakes (like calling CloseHandle instead of CloseWindow
on an HWND). This fact (that they're distinct types) makes the template-fu fail
when an HWND is marshaled.
That's exactly it. The PluginWindowHandle thing looked to me like a "why can't
we marshal HWNDs?" hack (see the accompanying comment) and made all attempts to
send an HWND succeed. My solution here (which came about after a fair amount of
cursing at cryptic msvc template-related error messages) tells the IPC
marshaling system that when it sees an HWND it can safely cast it to a HANDLE
and use the HANDLE marshaling that you pointed to above.

+};
+#endif  // defined(OS_WIN)
+
 template <>
 struct IPC_EXPORT ParamTraits<base::Time> {
   typedef base::Time param_type;