Bug 55329

Summary: REGRESSION (r79810): fast/events/pageshow-pagehide-on-back-cached.html failing on Windows
Product: WebKit Reporter: Adam Roben (:aroben) <aroben>
Component: DOMAssignee: 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

Adam Roben (:aroben)
Reported 2011-02-27 13:22:54 PST
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
Attachments
Adam Roben (:aroben)
Comment 1 2011-02-27 13:31:27 PST
Added Windows expected failure results Committed r79829: <http://trac.webkit.org/changeset/79829>
Adam Roben (:aroben)
Comment 2 2011-02-27 13:32:06 PST
Adam Roben (:aroben)
Comment 3 2011-02-28 11:06:41 PST
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?
Adam Roben (:aroben)
Comment 5 2011-03-01 05:54:52 PST
Added to the Skipped file Committed r79992: <http://trac.webkit.org/changeset/79992>
WebKit Review Bot
Comment 6 2011-03-01 08:39:11 PST
http://trac.webkit.org/changeset/79992 might have broken GTK Linux 32-bit Debug
Adele Peterson
Comment 7 2011-03-02 16:58:21 PST
Justin, are you looking into this, since it looks like it was caused by your change?
Justin Schuh
Comment 8 2011-03-04 09:37:19 PST
(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
Comment 9 2011-03-04 10:35:52 PST
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)
Comment 10 2011-04-15 06:34:06 PDT
See also bug 58441.
Brent Fulgham
Comment 11 2015-01-21 12:18:29 PST
This is no longer failing.
Note You need to log in before you can comment on or make changes to this bug.