[System-Keyboard-Lock] Forward navigator functions to RenderFrameHost

content/browser/keyboard_lock/keyboard_lock_browsertest.cc

+// Copyright 2017 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.
+
+#include <stdint.h>
+
+#include "base/command_line.h"
+#include "base/files/file_path.h"
+#include "base/location.h"
+#include "base/memory/ref_counted.h"
+#include "base/single_thread_task_runner.h"
+#include "base/test/thread_test_helper.h"
+#include "content/browser/web_contents/web_contents_impl.h"
+#include "content/public/browser/browser_context.h"
+#include "content/public/browser/browser_thread.h"
+#include "content/public/browser/storage_partition.h"
+#include "content/public/common/content_switches.h"
+#include "content/public/test/browser_test_utils.h"
+#include "content/public/test/content_browser_test.h"
+#include "content/public/test/content_browser_test_utils.h"
+#include "content/shell/browser/shell.h"
+
+namespace content {
+
+// This browser test is aimed towards exercising the File System API bindings

[whywhat, 2017/04/12 16:02:12]

nit: update comment

[Hzj_jie, 2017/04/13 00:38:53]

Done.

+// and the actual implementation that lives in the browser side.
+class KeyboardLockBrowserTest : public ContentBrowserTest {
+ public:
+  KeyboardLockBrowserTest() = default;
+
+  void SimpleTest(const std::string& function_name,
+                  const std::string& expected_result) {
+    // The test page will perform tests on keyboard lock APIs, then write the
+    // result into an element with id "result".
+    Shell* const the_browser = shell();
+
+    VLOG(0) << "Navigating to URL and blocking.";
+    ASSERT_TRUE(NavigateToURL(
+        the_browser, GetTestUrl("keyboard_lock", "keyboard_lock.html")));
+    VLOG(0) << "Navigation done.";
+    std::string result;
+    ASSERT_TRUE(ExecuteScriptAndExtractString(the_browser,
+                                              function_name + "();", &result));
+    ASSERT_EQ(result, expected_result);
+  }
+
+ protected:
+  void SetUpCommandLine(base::CommandLine* command_line) override {
+    ContentBrowserTest::SetUpCommandLine(command_line);
+    command_line->AppendSwitchASCII("--enable-blink-features", "KeyboardLock");
+  }
+};
+
+IN_PROC_BROWSER_TEST_F(KeyboardLockBrowserTest, RequestTest) {
+  // TODO(zijiehe): This test should receive "Succeeded" once the implementation
+  // in RenderFrameHostImpl has been finished.
+  SimpleTest("testRequestKeyLock", "Failed: Unsupported");
+}
+
+IN_PROC_BROWSER_TEST_F(KeyboardLockBrowserTest, CancelTest) {
+  SimpleTest("testCancelKeyLock", "Succeeded");
+}
+
+IN_PROC_BROWSER_TEST_F(KeyboardLockBrowserTest, RequestTwiceTest) {
+  // TODO(zijiehe): This test should receive "Succeeded" once the implementation

[whywhat, 2017/04/12 16:02:12]

nit: I'd say you have a layout test for this and the code that enforces this
behavior is also in Blink so testing the same behavior here maybe redundant.

[Hzj_jie, 2017/04/13 00:38:54]

If it's not a must-have, I would remove this file and its associated js / html
file from this change: the browser change has not been finished, I cannot test
the behavior other than "Failed: Unsupported" here.

Or maybe I can return "Succeeded" from RenderFrameHostImpl even it takes no
effect. What's the common practice for an unfinished feature like this?

[whywhat, 2017/04/13 02:34:36]

I think it's okay to add browser tests later that would actually execute the
implementation part and remove this tests for now. It also makes your change
smaller :)

[Hzj_jie, 2017/04/13 22:24:24]

:)

+  // in RenderFrameHostImpl has been finished.
+  SimpleTest("testRequestKeyLockTwice",
+             "Failed: Last requestKeyLock() has not finished yet.\n"
+             "Failed: Unsupported\n");
+}
+
+}  // namespace content