Bug 55329 – REGRESSION (r79810): fast/events/pageshow-pagehide-on-back-cached.html failing on Windows

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[Adam Roben (:aroben)]

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

[Adam Roben (:aroben)]

Added Windows expected failure results

Committed r79829: <http://trac.webkit.org/changeset/79829>

[Adam Roben (:aroben)]

<rdar://problem/9060202>

[Adam Roben (:aroben)]

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?

[Ryosuke Niwa]

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.

[Adam Roben (:aroben)]

Added to the Skipped file

Committed r79992: <http://trac.webkit.org/changeset/79992>

[WebKit Review Bot]

http://trac.webkit.org/changeset/79992 might have broken GTK Linux 32-bit Debug

[Adele Peterson]

Justin, are you looking into this, since it looks like it was caused by your change?

[Justin Schuh]

(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.

[Justin Schuh]

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.

[Adam Roben (:aroben)]

See also bug 58441.

[Brent Fulgham]

This is no longer failing.