Fix MaterialPDFExtensionTest.ElementsTest in Polymer 1.0.5

chrome/test/data/pdf/material_elements_test.js

Index: chrome/test/data/pdf/material_elements_test.js
diff --git a/chrome/test/data/pdf/material_elements_test.js b/chrome/test/data/pdf/material_elements_test.js
index f7f507e1813e02f2087253e4cd461a484ffb91dc..b0a6ad2d3f8d8125e25d6a3b01a882a7a288cc0f 100644
--- a/chrome/test/data/pdf/material_elements_test.js
+++ b/chrome/test/data/pdf/material_elements_test.js
@@ -135,7 +135,7 @@ var tests = [
       chrome.test.assertEq('hidden', subBookmarks[1].$.expand.style.visibility);
 
       chrome.test.succeed();
-    });
+    }, 10);

[raymes, 2015/07/30 04:33:22]

Hmm doing this could make the test flaky. If there is no polymer event that we
could catch which signals the bookmarks have loaded, could we fire an event
ourselves from inside the last bookmark to load?

[tsergeant, 2015/07/30 05:02:09]

My understanding of it (based on reading the Polymer.Async code) is that tasks
queued with a delay value cannot preempt tasks without a delay value. Tasks with
a delay are scheduled on the browser message loop using setTimeout, and Polymer
doesn't relinquish control back to that message loop until all non-delay tasks
are completed. All other tasks fired during this test have no delay, so this
task will be called last.

I don't think the test should be flaky for that reason. Otherwise, adding a
second nested .async() call also appears to fix the issue.

[tsergeant, 2015/07/30 07:04:05]

Actually, I've now convinced myself the other way. It was possible for control
to go back to the browser, depending on exactly how tasks are queued. Reading a
bunch *more* Polymer code, it seems that `Polymer.dom.flush()` is the best way
to force all templates to render (see [1]). With this, the test passes with no
async tasks at all.

[1]
https://github.com/Polymer/polymer/commit/89a767c1f97bff9d96f063f4ecfee79bc2f...

   }
 ];