Simple HTTP server for Chromoting End-to-End tests

chrome/test/remoting/http_server/clientpage.js

+// Copyright (c) 2014 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.
+
+// Set some global variables for the browsertest to pick up
+var keypressSucceeded = false;
+var keypressText = '';
+
+/**
+ * Method to make an XHR call to the server for status
+ */
+// TODO(chaitali):Update this method to poll and get status of all

[Jamie, 2014/03/04 21:40:35]

Nit: Space before "Update".

[chaitali, 2014/03/05 22:02:22]

Done.

+// test vars in each poll and stop when all are true.
+function poll() {
+
+  var request = new XMLHttpRequest();
+  request.open('GET', '/poll?test=keytest', true);

[Jamie, 2014/03/04 21:40:35]

Can we use a relative URL here too?

[chaitali, 2014/03/05 22:02:22]

Removed the /. The rest of it needs to remain so cherrypy can direct this to the
poll handler. Is that what you meant by relative URL?

On 2014/03/04 21:40:35, Jamie wrote:

[Jamie, 2014/03/06 00:15:01]

Yes, that's what I had in mind.

+
+request.onreadystatechange = function() {

[Jamie, 2014/03/04 21:40:35]

Nit: Indentation.

[chaitali, 2014/03/05 22:02:22]

Done.

+    if(request.readyState == 4 && request.status == 200) {

[Jamie, 2014/03/04 21:40:35]

Nit: Space after "if".

[chaitali, 2014/03/05 22:02:22]

Done.

+      console.log('Polling status : ' + request.responseText);
+      data = JSON.parse(request.responseText);

[Jamie, 2014/03/04 21:40:35]

This should be in a try...catch block, or there's a jsonParseSafe method that we
use in remoting.js that you can copy if you're going to be parsing a lot of
JSON.

[chaitali, 2014/03/05 22:02:22]

Done.

+      // If keypress succeeded then
+      // update relevant vars and stop polling.
+      if (data.keypressSucceeded == true) {
+        keypressSucceeded = data.keypressSucceeded;
+        keypressText = data.keypressText;
+      } else {
+        // If keypress did not succeed we should
+        // continue polling.
+        setTimeout(poll, 3000);

[Jamie, 2014/03/04 21:40:35]

3s seems like quite a long time to wait. I think we could avoid a wait
altogether using a hanging GET, but in the interim, maybe just reduce this to
1s?

[chaitali, 2014/03/05 22:02:22]

Changed to 1s.

I thought about long polling but what I want from the framework is that it polls
and gets a list of status vars from the server. As the host completes actions,
statuses will change. So it is possible that keypressSucceeded is true but
mouseSucceeded is false at some given time. With regular polling we'll receive
regular status of all vars and tests can complete as the statuses come in. With
long polling we'll have to wait till all the vars are true on the server and
block tests.

What I would really like is Server Sent Events but not sure how to do that here.

On 2014/03/04 21:40:35, Jamie wrote:

[Jamie, 2014/03/06 00:15:01]

This is fine for now, but let's talk off-line about improving it. It's possible
I've missed something obvious, but a hanging GET approach seems to be better
than polling, even for the scenario you describe.

+      }
+    }
+  };
+
+  request.onerror = function() {
+    console.log('Polling failed');
+  };
+
+request.send();

[Jamie, 2014/03/04 21:40:35]

Nit: Indentation.

[chaitali, 2014/03/05 22:02:22]

Done.

+};
+
+window.addEventListener('load', function(){
+  poll();
+});

[Jamie, 2014/03/04 21:40:35]

I think you're missing a 'false' parameter for addEventListener (technically,
it's optional in Chrome, but you've used it elsewhere, and I think jscompile
treats it as mandatory).

[chaitali, 2014/03/05 22:02:22]

Done.

+