Vibration API: plumbing from Blink to Java.

content/common/view_messages.h

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 // IPC messages for page rendering.
 // Multiply-included message file, hence no include guard.
 
 #include "base/process.h"
 #include "base/shared_memory.h"
 #include "base/strings/string16.h"
@@ skipping 1677 matching lines @@
 // necessary, and will return a handle to the channel on success.
 // On error an empty string is returned.
 IPC_SYNC_MESSAGE_CONTROL4_2(ViewHostMsg_OpenChannelToPlugin,
                             int /* routing_id */,
                             GURL /* url */,
                             GURL /* page_url */,
                             std::string /* mime_type */,
                             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 */)
 
 IPC_MESSAGE_ROUTED1(ViewHostMsg_WindowlessPluginDummyWindowDestroyed,
                     gfx::NativeViewId /* dummy_activation_window */)
 #endif
 
 // Get the list of proxies to use for |url|, as a semicolon delimited list
 // of "<TYPE> <HOST>:<PORT>" | "DIRECT".
@@ skipping 613 matching lines @@
 // Since the browser keeps handles to the allocated transport DIBs, this
 // message is sent to tell the browser that it may release them when the
 // renderer is finished with them.
 IPC_MESSAGE_CONTROL1(ViewHostMsg_FreeTransportDIB,
                      TransportDIB::Id /* DIB id */)
 #endif
 
 // Adding a new message? Stick to the sort order above: first platform
 // independent ViewMsg, then ifdefs for platform specific ViewMsg, then platform
 // independent ViewHostMsg, then ifdefs for platform specific ViewHostMsg.