This looks like a bug in the test harness. Not really sure how this would happen. Looking at the diff, something would have to be going wrong with js-test-pre. I don't really understand how it's possible though. The same call that prints "Make sure that a debug assert is not triggered when constructing the accessibility tree for this page." should print the missing lines. It's also weird that it just recently got flaky on only the Chromium windows bot (http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=accessibility%2Fadjacent-continuations-cause-assertion-failure.html). My best guess is that there is some weird interaction between this test and some test that runs before it. --- e:\b\build\slave\Webkit_Win\build\layout-test-results\accessibility/adjacent-continuations-cause-assertion-failure-expected.txt +++ e:\b\build\slave\Webkit_Win\build\layout-test-results\accessibility/adjacent-continuations-cause-assertion-failure-actual.txt @@ -3,10 +3,7 @@ z End of test Make sure that a debug assert is not triggered when constructing the accessibility tree for this page. - On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE". - - AXRole: AXWebArea AXValue: AXRole: AXStaticText AXValue: x AXRole: AXGroup AXValue:
I've been staring at this (and http://code.google.com/p/chromium/issues/detail?id=101996) a lot lately. This one is strange. Maybe there is some strangeness going on with innerHTML and the way we are trying to insert p elements into the existing p element? We should end up with: <p> <span> <p>$msg</p> <p>On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE".</p> </span> </p> Which is non-sensical but I've never seen that not work before.
Hasn't failed for a long time according to the flakiness dashboard, so I'm about to remove this test from the expectations. Feel free to reopen if you still want to track this issue.