Split Date/Time picker values from IME processing since date/time related form values have been com…

content/common/view_messages.h

Index: content/common/view_messages.h
diff --git a/content/common/view_messages.h b/content/common/view_messages.h
index 7c72509001dcce91eaff7353559c869c03b198ea..9b72dae2215fa88eb1df2b13c929157ab0c93e0b 100644
--- a/content/common/view_messages.h
+++ b/content/common/view_messages.h
@@ -1990,6 +1990,11 @@ IPC_MESSAGE_ROUTED2(ViewHostMsg_EnumerateDirectory,
 IPC_MESSAGE_ROUTED1(ViewHostMsg_TakeFocus,
                     bool /* reverse */)
 
+// Required for opening a date/time dialog
+IPC_MESSAGE_ROUTED2(ViewHostMsg_OpenDateTimeDialog,
+                    int /* dialog type */,

[jam, 2013/01/14 21:10:55]

nit: here and below, the convention is to put the parameter name in the
dispatching function inside the comment (so type, and value)

[Miguel Garcia, 2013/01/17 12:17:40]

Done.

+                    std::string /* initial value */)

[palmer, 2013/01/14 23:53:35]

I'd rather send plain old data (e.g. an int of seconds since the epoch), or a
specific Date/Time/DateTime object, rather than a pre-baked *representation* of
the value. From the sender side of the code, we don't know how the recipient is
going to interpret/interpolate this value — what if it's a (cross-site
scriptable!) WebView someday, instead of a native Android GUI widget? What if
the string is formatted for the wrong locale? That kind of thing.

So, send the specific type you *mean*. That also has the benefit of bounding the
size of the sent object, which is important in IPC.

[Miguel Garcia, 2013/01/17 12:17:40]

As agreed, I'll do this in a separate patch.

On 2013/01/14 23:53:35, Chris P. wrote:

+
 // Required for updating text input state.
 IPC_MESSAGE_ROUTED1(ViewHostMsg_TextInputStateChanged,
                     ViewHostMsg_TextInputState_Params /* input state params */)