Pepper and WebKit API change to support a plugin knowing if a scrollbar is an overlay one.

ppapi/c/dev/ppb_scrollbar_group_dev.h

+/* Copyright (c) 2011 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.
+ */
+#ifndef PPAPI_C_DEV_PPB_SCROLLBAR_GROUP_DEV_H_
+#define PPAPI_C_DEV_PPB_SCROLLBAR_GROUP_DEV_H_
+
+#include "ppapi/c/pp_instance.h"
+#include "ppapi/c/pp_resource.h"
+
+#define PPB_SCROLLBAR_GROUP_DEV_INTERFACE_0_1 "PPP_Scrollbar_Group(Dev);0.1"
+#define PPB_SCROLLBAR_GROUP_DEV_INTERFACE PPB_SCROLLBAR_GROUP_DEV_INTERFACE_0_1
+
+// The interface for a scrollbar group. Horizontal and vertical scrollbars for
+// the same region need to be associated together with one group. This is
+// necessary for some platforms in which changes to one scrollbar lead to
+// animation changes for the other.
+struct PPB_ScrollbarGroup_Dev {
+  // Create a new scrollbar group.  Returns 0 if the instance is invalid.
+  PP_Resource (*Create)(PP_Instance instance);
+
+  // Used on platforms that animate the scrollbars when resizing or when the

[darin (slow to review), 2011/08/05 15:24:00]

when we discussed what to call this interface, i had no idea it would have all
of these methods.  these methods make me think this interface should have a name
more like PPB_ScrollableArea_Dev.

like we were talking yesterday, we'll probably want to move away from allowing
plugins to allocate individual scrollbars, and instead build up the concept of a
scrollable area that the plugin can render into.  this could be the start of
that?

[jam, 2011/08/05 17:07:01]

I agree. It seems cumbersome for the embedder to create two scrollbars and a
scrollbar group, and implement three interfaces (widget/scrollbar/resize) so
they can show scrollbars.

I'll take a stab to change this to one interface each way. I'm going to try to
figure out why they're not showing on resize though, because that will probably
change the API.

[jam, 2011/08/06 02:15:58]

Rereading what you wrote, I realize I might have misunderstood what you meant
initially. I was thinking of having one interface in each direction for this. I
think the plugin will still want to control painting. The reason is for most
plugins, I suspect they will want to make scrollbars synchronous with the data
which shouldn't be very expensive to render. In the pdf case, the document is
sometimes very slow to render and this makes us want to render the scrollbars
first always. This necessitates a complicated PaintManager which I think would
only be useful for the pdf plugin.

[jam, 2011/08/06 15:57:47]

actually, thinking more about this, we probably don't even need to involve the
plugin. i.e. instead of having the plugin need to implement the new resize api
and pass the callbacks from there to scroll_group, we can do this automatically.

[jam, 2011/08/06 17:29:47]

ok, patch uploaded. what do you think of this approach?

+  // mouse is moving in the content area. Harmless to call on other platforms.
+  void (*MouseEnteredContentArea)(PP_Resource scrollbar_group);
+  void (*MouseMovedInContentArea)(PP_Resource scrollbar_group);
+  void (*MouseExitedContentArea)(PP_Resource scrollbar_group);
+  void (*WillStartLiveResize)(PP_Resource scrollbar_group);
+  void (*ContentResized)(PP_Resource scrollbar_group);
+  void (*WillEndLiveResize)(PP_Resource scrollbar_group);
+};
+
+#endif  /* PPAPI_C_DEV_PPB_SCROLLBAR_GROUP_DEV_H_ */