Fix MaterialPDFExtensionTest.ElementsTest in Polymer 1.0.5

Fix MaterialPDFExtensionTest.ElementsTest in Polymer 1.0.5

This CL forces templates to render immediately using Polymer.dom.flush()
instead of posting an async task. This ensures that the templates will
render regardless of changes to how the templates are rendered internally.

This issue was raised by https://codereview.chromium.org/1261403002/.

BUG=None

[tsergeant, 2015-07-30 03:27:53]

tsergeant@chromium.org changed reviewers:
+ raymes@chromium.org

[tsergeant, 2015-07-30 03:28:00]

The CQ bit was checked by tsergeant@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-07-30 03:28:19]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1254803006/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1254803006/1

[commit-bot: I haz the power, 2015-07-30 04:08:50]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-07-30 04:08:50]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

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

https://codereview.chromium.org/1254803006/diff/1/chrome/test/data/pdf/materi...
File chrome/test/data/pdf/material_elements_test.js (right):

https://codereview.chromium.org/1254803006/diff/1/chrome/test/data/pdf/materi...
chrome/test/data/pdf/material_elements_test.js:138: }, 10);
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]

https://codereview.chromium.org/1254803006/diff/1/chrome/test/data/pdf/materi...
File chrome/test/data/pdf/material_elements_test.js (right):

https://codereview.chromium.org/1254803006/diff/1/chrome/test/data/pdf/materi...
chrome/test/data/pdf/material_elements_test.js:138: }, 10);
On 2015/07/30 at 04:33:22, raymes wrote:
> 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?

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.

[raymes, 2015-07-30 05:59:57]

I see :) I think that's ok then but let's add a comment stating that because at
face value it looks like it's going to be flaky :) lgtm!

I think if we were doing this in production code I would err on the side of
caution and fire an event. In this case it doesn't seem clear that bookmarks is
guaranteed to be initialized after the async call, we're really relying on the
way polymers initialization of the bookmark elements works and also the way that
our initialization works (and the interaction between the two). But for this
test it seems ok :)

[tsergeant, 2015-07-30 07:04:06]

Updated with a much better solution that I found =D

https://codereview.chromium.org/1254803006/diff/1/chrome/test/data/pdf/materi...
File chrome/test/data/pdf/material_elements_test.js (right):

https://codereview.chromium.org/1254803006/diff/1/chrome/test/data/pdf/materi...
chrome/test/data/pdf/material_elements_test.js:138: }, 10);
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...

[tsergeant, 2015-07-30 07:04:14]

The CQ bit was checked by tsergeant@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-07-30 07:05:22]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1254803006/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1254803006/20001

[commit-bot: I haz the power, 2015-07-30 07:37:53]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-07-30 07:37:54]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Dan Beam, 2015-07-30 20:30:39]

dbeam@chromium.org changed reviewers:
+ dbeam@chromium.org

[Dan Beam, 2015-07-30 20:30:39]

I think our patches would need to be combined, as yours requires 1.0.5 to work
(I think, see: the failures in your try runs) and mine requires your test fixes
to ... roll to 1.0.5 :).

I'm going to add your test fixes to https://codereview.chromium.org/1261403002/
and submit them together (as the test works for me when I have both CLs applied
locally).

[tsergeant, 2015-07-30 22:47:17]

On 2015/07/30 at 20:30:39, dbeam wrote:
> I think our patches would need to be combined, as yours requires 1.0.5 to work
(I think, see: the failures in your try runs) and mine requires your test fixes
to ... roll to 1.0.5 :).
> 
> I'm going to add your test fixes to
https://codereview.chromium.org/1261403002/ and submit them together (as the
test works for me when I have both CLs applied locally).

Sounds good to me

[raymes, 2015-08-03 00:07:20]

lgtm!