Defer loading of audio/video tags while prerendering.

chrome/test/data/prerender/prerender_html5_common.js

Index: chrome/test/data/prerender/prerender_html5_common.js
diff --git a/chrome/test/data/prerender/prerender_html5_common.js b/chrome/test/data/prerender/prerender_html5_common.js
new file mode 100644
index 0000000000000000000000000000000000000000..00385790f380355f0270ac756a98f6a0bdeab697
--- /dev/null
+++ b/chrome/test/data/prerender/prerender_html5_common.js
@@ -0,0 +1,54 @@
+// 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.
+
+// Define a variable called willPlay which indicates if the media is expected
+// to start playing during the test.
+
+var canPlaySeen = false;
+var playingSeen = false;
+var canPlayThroughSeen = false;
+var hasError = false;
+
+var mediaEl = document.getElementById("mediaEl");
+
+function mediaEventHandler(e) {
+  console.log(e.type);

[cbentzel, 2011/11/15 18:55:33]

Is this console.log statement needed anymore? 

[Shishir, 2011/11/17 21:18:49]

Helpful for debugging failing tests, so might be worth keeping this.

[scherkus (not reviewing), 2011/11/17 23:27:50]

I'm a big proponent of quiet tests.

If a test started failing I'd assume a developer would do the necessary things
to debug it but leaving in log statements don't help us.

[Shishir, 2011/11/22 00:45:16]

Done.

+
+  switch (e.type) {
+    case 'canplay':
+      canPlaySeen = true;
+      break;
+    case 'playing':
+      playingSeen = true;
+      break;
+    case 'canplaythrough':
+      canPlayThroughSeen = true;
+      break;
+    case 'error':
+      hasError = true;
+      break;
+  }
+
+  if ((willPlay && canPlayThroughSeen && playingSeen) ||
+      (!willPlay && canPlayThroughSeen && !playingSeen)) {
+    document.title = 'PASS';
+  }
+}
+
+mediaEl.addEventListener('playing', mediaEventHandler, false);

[cbentzel, 2011/11/15 18:55:33]

Should this be using the network events (loadstart, progress, etc.) in addition
to the more playback-oriented events?

[scherkus (not reviewing), 2011/11/16 02:02:23]

I agree -- loadstart, progress, and stalled are good ones to watch

[Shishir, 2011/11/17 21:18:49]

The network events are not very reliable and its not clear to me which of them
will fire. It  seems to depend more on timing. I see stalled / waiting fire on a
couple of tests but not on all. Also the network state seems to to be
"loading_data (2)" when any of canplay, canplaythrough etc.. events fire. 

Any suggestions on cases we should test. 

[scherkus (not reviewing), 2011/11/17 23:27:50]

This is interesting to discuss and would like to hear cbentzel's thoughts on the
matter.

I think it might be worth biting the bullet and having at least one test take
3-5s to run in order to listen to loadstart/progress/stalled. The other tests
don't require it and can run fast, but it's important to understand which
networking/load events are getting fired during prerendering.

What about a test for the following:
loadStartSeen && stalledSeen

[Shishir, 2011/11/22 00:45:16]

Added a test for loadStart and stalled.

+mediaEl.addEventListener('canplay', mediaEventHandler, false);
+mediaEl.addEventListener('canplaythrough', mediaEventHandler, false);
+mediaEl.addEventListener('error', mediaEventHandler, false);
+
+function DidPrerenderPass() {
+  // The media should not have started at this point.
+  return !canPlaySeen && !playingSeen && !hasError &&
+      mediaEl.currentTime == 0 &&
+      mediaEl.readyState == mediaEl.HAVE_NOTHING;
+}
+
+function DidDisplayPass() {
+  // The actual test is done via the TitleWatcher.
+  return true;
+}