fast/events/pageshow-pagehide-on-back-cached.html has been failing on Windows since r79810. See the URL for a failure diff.
Did not fail: http://build.webkit.org/builders/Windows%207%20Release%20%28Tests%29/builds/9810
Did fail: http://build.webkit.org/builders/Windows%207%20Release%20%28Tests%29/builds/9812
Added Windows expected failure results
Committed r79829: <http://trac.webkit.org/changeset/79829>
Looks like the test just produced the cross-platform results on Windows XP Debug (Tests) (and thus failed because it didn't match the Windows-specific results I checked in): http://build.webkit.org/results/Windows%20XP%20Debug%20(Tests)/r79879%20(25784)/fast/events/pageshow-pagehide-on-back-cached-pretty-diff.html
Seems like we should skip this test since it fails unpredictably. Maybe it is timing-sensitive?
It seems like this test is now failing again on Win 7:
But the corresponding changeset http://trac.webkit.org/changeset/79919 is nothing to do with page events.
Added to the Skipped file
Committed r79992: <http://trac.webkit.org/changeset/79992>
http://trac.webkit.org/changeset/79992 might have broken GTK Linux 32-bit Debug
Justin, are you looking into this, since it looks like it was caused by your change?
(In reply to comment #7)
> Justin, are you looking into this, since it looks like it was caused by your change?
I'm not familiar with the area this is testing, but I don't see how this could be related to r79810. My patch delays events from firing in the middle of setting an attribute value (during the window between child removal and assigning the value). I can't see how it would have an effect like this on just one platform, but I'll take a look today.
I don't have vs2005 to test Safari w/ WebKit trunk on Windows, but I checked against Chrome on Windows. The test fails on stable (before r79810) and on trunk (after r79810). I also verified that that the code path I changed is never executed during the test (and I can't see how it could be on any platform).
I'd like to help track this down, but I'm not familiar with the cache code and I don't see how my change could have triggered the test failure. It seems like the test is flaky for other reasons.
See also bug 58441.
This is no longer failing.