Fix prop_attr_reflection_test in drt/dartium (fixes issue 14295)

pkg/polymer/test/prop_attr_reflection_test.dart

Index: pkg/polymer/test/prop_attr_reflection_test.dart
diff --git a/pkg/polymer/test/prop_attr_reflection_test.dart b/pkg/polymer/test/prop_attr_reflection_test.dart
index 2ca8f4231fa2e482b2033174518a936e37230564..e429114ae1757107aba7a1105e96e393a8912aa1 100644
--- a/pkg/polymer/test/prop_attr_reflection_test.dart
+++ b/pkg/polymer/test/prop_attr_reflection_test.dart
@@ -37,6 +37,7 @@ Future onAttributeChange(Element node) {
     observer.disconnect();
     completer.complete();
   })..observe(node, attributes: true);
+  Platform.flush();

[Siggi Cherem (dart-lang), 2013/10/22 01:40:31]

Not sure if you prefer to fix this in some other way.

Here is what happened: this code used to be called within the
dirty-checking-zone when we used @initMethod below. When I changed the test to
use main, this code started being executed in the top-level zone.

[Jennifer Messerly, 2013/10/22 05:51:51]

yeah, this is fine ... however, out of curiosity what would it take to have
things in the zone? it seems a bit dangerous if our main/initPolymer pattern
doesn't lead people down the path of running Polymer code in a zone.

Maybe initPolymer sound take a callback for that purpose? Or some other way of
making the zone more obvious?

   return completer.future;
 }
 
@@ -52,9 +53,9 @@ main() {
   Polymer.register('x-compose', XCompose);
 
   test('property attribute reflection', () {
-    var xcompose = query('x-compose').xtag;
-    var xfoo = query('x-foo').xtag;
-    var xbar = query('x-bar').xtag;
+    var xcompose = query('x-compose');
+    var xfoo = query('x-foo');
+    var xbar = query('x-bar');
     xfoo.foo = 5;
     return onAttributeChange(xfoo).then((_) {
       expect(xcompose.$['bar'].attributes.containsKey('zim'), false,