Summary: | fast/loader/recursive-before-unload-crash.html is flakey on leopard | ||
---|---|---|---|
Product: | WebKit | Reporter: | Eric Seidel (no email) <eric> |
Component: | Tools / Tests | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED DUPLICATE | ||
Severity: | Normal | CC: | abarth, ap, beidson, darin |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | PC | ||
OS: | OS X 10.5 |
Description
Eric Seidel (no email)
2010-07-08 10:45:55 PDT
https://trac.webkit.org/browser/trunk/LayoutTests/fast/loader/recursive-before-unload-crash.html I can get you failure logs from the bot. > I can get you failure logs from the bot.
Of course, please do.
My apologies. I got distracted. Here it is: --- /tmp/layout-test-results/fast/loader/recursive-before-unload-crash-expected.txt 2010-07-09 13:38:55.000000000 -0700 +++ /tmp/layout-test-results/fast/loader/recursive-before-unload-crash-actual.txt 2010-07-09 13:38:55.000000000 -0700 @@ -6,8 +6,8 @@ main frame - didStartProvisionalLoadForFrame ALERT: Adding iframe frame "<!--framePath //<!--frame0-->-->" - didStartProvisionalLoadForFrame -main frame - didCancelClientRedirectForFrame frame "<!--framePath //<!--frame0-->-->" - didFailProvisionalLoadWithError +main frame - didCancelClientRedirectForFrame main frame - didFailProvisionalLoadWithError This test demonstrates a problem with our handling of the beforeunload event. If a script manages to try and navigate the frame from beforeunload - when a navigation is already pending - we end up blowing out the stack by recursively consulting the policy delegate then running onbeforeunloa d repeatedly. Looks like a race in the frame loader callbacks. The frame loader callbacks are quite racy. It's very difficult to design a test that doesn't race them. |