I assume this is something you want to try to fix for 1.5?

Removed Priority-Unassigned label.
Added Priority-High label.

We have not been able to reproduce those flakes entirely.

They definitely don't fail in dart2js. We've done some things that we believe will help make it less likely to happen (I removed the use of the boot.js that we had at the time of the roll, and we are upgrading to the latest version of the polyfills).

I chatted with Rico about getting flaky history information, and unfortunately we don't have flaky logs for the Dartium bots, so he mentioned that the best we can do is remove the status lines and see what happens.

John plans to submit https://codereview.chromium.org/307793002 today, which will remove these pass/fail status lines.

John tried to remove but had to revert.

Let's try again after I roll to 36.0.1985.49 (https://code.google.com/p/dart/issues/detail?id=19269).

There are a few stability fixes there, include a couple related to html imports:
http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog_blink.html?url=/branches/chromium/1985&range=173811:175393&mode=html

Do you think these might be related? I suspect our Polymer tests are the only ones using imports extensively.

Adding Vijay as owner of this (under the assumption that the next step is to try to bring in the Blink stability fixes).

Set owner to @vsmenon.

ah yes, that could totally be the issue. Thank you Vijay! :D

Any update on this?

I'm looking into this, I can reproduce locally. I'll update later today.

We've replicated the underlying issue (custom elements not upgrading at the expected time) with upstream Chrome (36 beta and 37 canary).

It only appears to occur if two frames are concurrently loading pages with custom elements - hence why we're seeing it in the test framework.

Dropping from this milestone. We still need a way to re-enable polymer tests - perhaps working around this bug if necessary.

Removed this from the 1.5 milestone.
Added this to the 1.6 milestone.

because we don't use iframes with content_shell, we have been able to run polymer tests there. I can't recall exactly when we did the switch in the status files, but we have already enabled the tests in content_shell in bleeding_edge.

Removed this from the 1.6 milestone.
Added this to the 1.7 milestone.

Removed this from the 1.7 milestone.
Added this to the 1.8 milestone.

This test is flaky on dartium now:
polymer/example/component/news/test/news_index_test

It sounds like the same problem - the assertion that fails is
 expect(listComp is Polymer, true, reason: 'x-news should be created');

All the other tests in the list in the top comment remain marked as flaky in the status file, but this test was removed - it was marked failing before polymer 0.4, and removed in https://codereview.chromium.org//558673004. Restoring its flaky status.

Removed this from the 1.8 milestone.

Added this to the 1.9 milestone.

Added Accepted label.

Removed this from the 1.9 milestone.
Added this to the 1.10 milestone.

Is this still an issue?

Removed the owner.
Added Triaged label.

It might be - we need to investigate. The flaky status is still in our .status file in polymer-dart here: https://github.com/dart-lang/polymer-dart/blob/master/.status

There was a bug creating the .flaky logs in the package-bots that was fixed this week, so we should be able to take another look.

cc @jakemac53.