[VideoPlayer] Browser tests for new separated video player app

chrome/browser/resources/video_player/js/error_util.js

Index: chrome/browser/resources/video_player/js/error_util.js
diff --git a/chrome/browser/resources/video_player/js/error_util.js b/chrome/browser/resources/video_player/js/error_util.js
new file mode 100644
index 0000000000000000000000000000000000000000..30a1d542615132afd9240ed9c29b8d29a218ea62
--- /dev/null
+++ b/chrome/browser/resources/video_player/js/error_util.js
@@ -0,0 +1,43 @@
+// Copyright 2013 The Chromium Authors. All rights reserved.

[hirono, 2014/03/26 02:55:05]

nit: 2014

[yoshiki, 2014/03/26 04:55:52]

Done.

+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+'use strict';
+
+/**
+ * This variable is checked in SelectFileDialogExtensionBrowserTest.
+ * @type {number}
+ */
+window.JSErrorCount = 0;
+
+/**
+ * Count uncaught exceptions.
+ */
+window.onerror = function() { window.JSErrorCount++; };
+
+/**
+ * Wrap the function to use it as a callback.

[hirono, 2014/03/26 02:55:05]

nit: Wraps

[yoshiki, 2014/03/26 04:55:52]

Done.

+ * This does:
+ *  - Capture the stack trace in case of error.
+ *  - Bind this object
+ *
+ * @param {Object} thisObject Object to be used as this.
+ * @return {function} Wapped function.
+ */
+Function.prototype.wrap = function(thisObject) {

[hirono, 2014/03/26 02:55:05]

Strictly our design guide forbid us to modify prototypes of builtin objects.
https://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml?showon...

[yoshiki, 2014/03/26 04:55:52]

Not "strictly". The guide says "Modifying other builtins like Function.prototype
is less dangerous".

Of cause, we can instead use a normal function like wrap(func, thisObj). But I'm
considering to replace bind() with wrap() in Files.app as well as in video
player. Along the way, the same syntax as bind() is better to replace it, since
the only thing we need to do it replacing of the text.

[hirono, 2014/03/26 08:18:31]

SGTM. 

[mtomasz, 2014/04/01 19:37:50]

Out of curiosity. Why don't we put this code to #16? Is there any advantage of
wrap() over window.onerror?

I'm a little bit concerned about violating the style guide here, which clearly
says No for modifying prototypes of builtin types. Can't we avoid it?

+  var func = this;
+  var liveStack = (new Error('Stack trace before async call')).stack;
+  if (thisObject === undefined)
+    thisObject = null;
+
+  return function wrappedCallback() {
+    try {
+      return func.apply(thisObject, arguments);
+    } catch (e) {
+      console.error('Exception is happen in callback.', liveStack);

[hirono, 2014/03/26 02:55:05]

The e.stack is also useful information. Could you add it?

[hirono, 2014/03/26 02:55:05]

nit: Exception happens or Exception is thrown?

[yoshiki, 2014/03/26 04:55:52]

Done.

[yoshiki, 2014/03/26 04:55:52]

The original exception e will be caught by the handler of the outer function.

+
+      window.JSErrorCount++;

[mtomasz, 2014/04/01 19:37:50]

Aren't we incrementing JSErrorCount twice? #16 and #39?

+      throw e;
+    }
+  }
+};