Summary: | REGRESSION (r79810): fast/events/pageshow-pagehide-on-back-cached.html failing on Windows | ||
---|---|---|---|
Product: | WebKit | Reporter: | Adam Roben (:aroben) <aroben> |
Component: | DOM | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED FIXED | ||
Severity: | Normal | CC: | abarth, adele, bfulgham, darin, eric, jschuh, rniwa, webkit.review.bot |
Priority: | P2 | Keywords: | InRadar, LayoutTestFailure, PlatformOnly, Regression |
Version: | 528+ (Nightly build) | ||
Hardware: | PC | ||
OS: | Windows XP | ||
URL: | http://build.webkit.org/results/Windows%207%20Release%20(Tests)/r79810%20(9812)/fast/events/pageshow-pagehide-on-back-cached-pretty-diff.html |
Description
Adam Roben (:aroben)
2011-02-27 13:22:54 PST
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: http://build.webkit.org/results/Windows%207%20Release%20(Tests)/r79918%20(9867)/results.html http://build.webkit.org/results/Windows%207%20Release%20(Tests)/r79919%20(9868)/fast/events/pageshow-pagehide-on-back-cached-pretty-diff.html 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. |