Vibration API: plumbing from Blink to Java.

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 1a7508b10c6f559d2eec77af65b9447dc7ede0de..3273387f5db3d7713eae3303a19722b47e6df71a 100644
--- a/content/common/view_messages.h
+++ b/content/common/view_messages.h
@@ -1695,6 +1695,15 @@ IPC_SYNC_MESSAGE_CONTROL4_2(ViewHostMsg_OpenChannelToPlugin,
                             IPC::ChannelHandle /* channel_handle */,
                             webkit::WebPluginInfo /* info */)
 
+// Sent by the renderer to the browser to start a vibration with the given

[palmer, 2013/06/21 18:17:40]

Should these be guarded by #if defined(OS_ANDROID) ?

[Michael van Ouwerkerk, 2013/06/24 13:46:57]

This feature is not necessarily restricted to Android, and also it's easier to
automate tests this way.

+// duration.
+IPC_MESSAGE_CONTROL1(ViewHostMsg_Vibrate,
+                     unsigned int /* milliseconds */)

[palmer, 2013/06/21 18:17:40]

I'd say int64_t here.

For best results, use an explicitly-sized integer across the IPC boundary. It's
probably not going to be an issue on Android for a long time, but it could be
possible that (e.g.) a plugin process runs as 32-bit while the browser process
runs as 64-bit. Also, there's always the Java integers (well-defined absolute
sizes) vs. C++ integers (well-defined relative sizes) issue. In this exact case,
an explicitly-sized integer is mainly for readability.

Note also that the style guide wants you to use unsigned integers when the
defined behavior of integer overflow is necessary (signed overflow behavior is
undefined); but not to use unsigned as a way of asserting that the value will
never be negative.

Since the Android API for the vibrator needs a Java long, let's consistently use
the equivalent C++ type.

[Michael van Ouwerkerk, 2013/06/24 13:46:57]

Ok, so I changed it to int32_t. I think the use of a long in Java is a red
herring. We don't want to support such long vibrations anyway, so it seems
wasteful to use int64_t. 

Also, the spec uses 'unsigned long' in IDL
(http://dev.w3.org/2009/dap/vibration/#vibration-interface) which seems to
translate to 'unsigned' in Blink. I'm casting this to int32_t in
renderer_webkitplatformsupport_impl.cc.

On 2013/06/21 18:17:40, Chromium Palmer wrote:

+
+// Sent by the renderer to the browser to cancel the currently running
+// vibration, if there is one.
+IPC_MESSAGE_CONTROL0(ViewHostMsg_CancelVibration)
+
 #if defined(OS_WIN)
 IPC_MESSAGE_ROUTED1(ViewHostMsg_WindowlessPluginDummyWindowCreated,
                     gfx::NativeViewId /* dummy_activation_window */)