Hide location bar on Javascript-initiated scroll.

cc/input/top_controls_state_list.h

Index: cc/input/top_controls_state_list.h
diff --git a/cc/input/top_controls_state_list.h b/cc/input/top_controls_state_list.h
new file mode 100644
index 0000000000000000000000000000000000000000..7ebe93f143bfb012488e73e98675ebf14be3e379
--- /dev/null
+++ b/cc/input/top_controls_state_list.h
@@ -0,0 +1,19 @@
+// Copyright (c) 2013 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 CC_INPUT_TOP_CONTROLS_STATE_LIST_H_
+#define CC_INPUT_TOP_CONTROLS_STATE_LIST_H_
+
+#ifndef DEFINE_TOP_CONTROLS_STATE
+#error "DEFINE_TOP_CONTROLS_STATE should be defined before including this file"
+#endif
+
+// These values are defined with macros so that a Java class can be generated

[aelias_OOO_until_Jul13, 2013/05/02 18:44:23]

I understand the problem you're addressing here but it's not really a concern of
CC, and AFAIK this is not an accepted pattern in Chromium code.  Please define
the enum normally and have matching constants on the Java side, and add some
comments warning about the other class that should be modified in sync.  (This
enum shouldn't often change anyway.)

[Michael van Ouwerkerk, 2013/05/08 16:21:15]

Well, there is precedent in net/ chrome/ and content/:
net/android/java/NetError.template
chrome/android/java/ToolbarModelSecurityLevel.template
content/public/android/java/src/org/chromium/content/common/ResultCodes.template

Marcus Bulach tells me this is the way forward, and we expect to use this
pattern more in the future. Because of this, I'd prefer to keep this part as is.

On 2013/05/02 18:44:23, aelias wrote:

+// for them.
+DEFINE_TOP_CONTROLS_STATE(SHOWN, 1)
+DEFINE_TOP_CONTROLS_STATE(HIDDEN, 2)
+DEFINE_TOP_CONTROLS_STATE(BOTH, 3)
+
+#endif  // CC_INPUT_TOP_CONTROLS_STATE_LIST_H_
+