120105 2013-08-20 23:35:29 -0700 http/tests/navigation/post-frames-goback1-uncached.html fails on Qt, GTK+, and EFL bots 2013-08-23 01:24:50 -0700 1 1 1 Unclassified WebKit Page Loading 528+ (Nightly build) Unspecified Unspecified NEW LayoutTestFailure P2 Normal --- 120028 120152 1 rniwa webkit-unassigned abrhm ap beidson kadam ossy seokju spena zan zarvai oldest_to_newest 919350 0 rniwa 2013-08-20 23:35:29 -0700 The test added by http://trac.webkit.org/changeset/154306 is failing on GTK+, Qt, and EFL bots: http://webkit-test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=http%2Ftests%2Fnavigation%2Fpost-frames-goback1-uncached.html e.g. http://build.webkit.org/results/GTK%20Linux%2064-bit%20Debug%20WK1/r154378%20(3715)/results.html 919355 1 ap 2013-08-20 23:46:19 -0700 This looks like a difference in UI delegate implementation. If this test is run in a browser, a dialog asking whether it's OK to submit a form again appears. Mac DumpRenderTree simulates a "NO" answer, while the platforms where this fails say "YES". 919356 2 rniwa 2013-08-20 23:50:09 -0700 Should we simply rebaseline it then? 919492 3 ap 2013-08-21 09:55:29 -0700 Landing custom results sounds OK for now, but ideally, DumpRenderTree should be changed on these platforms, I think. 920011 4 ap 2013-08-22 16:27:49 -0700 I was wrong about the reason. DumpRenderTree allows the load, but it doesn't show up because the test finishes before the subframe loads. Looks like there may be two bugs: 1. WebCore dispatches a load event too early when going back. This happens in FrameLoader::retryAfterFailedCacheOnlyMainResourceLoad() when it calls stopAllLoaders(), but the load is not done yet, it is continued to attempt resubmitting the form! 2. Not quite sure what happens on platforms that fail the current test results. Perhaps they ignore Cache-Control, and cache the result of form submission anyway? Could someone please set a breakpoint in FrameLoader::retryAfterFailedCacheOnlyMainResourceLoad() and see if it's hit? So, Qt/Gtk/EFL results are what the test should print if not for issue (1), but they are probably like that because of another bug only, not because the right thing happens. 920141 5 spena 2013-08-23 01:03:50 -0700 (In reply to comment #4) > I was wrong about the reason. DumpRenderTree allows the load, but it doesn't show up because the test finishes before the subframe loads. > > Looks like there may be two bugs: > > 1. WebCore dispatches a load event too early when going back. This happens in FrameLoader::retryAfterFailedCacheOnlyMainResourceLoad() when it calls stopAllLoaders(), but the load is not done yet, it is continued to attempt resubmitting the form! > > 2. Not quite sure what happens on platforms that fail the current test results. Perhaps they ignore Cache-Control, and cache the result of form submission anyway? Could someone please set a breakpoint in FrameLoader::retryAfterFailedCacheOnlyMainResourceLoad() and see if it's hit? > > So, Qt/Gtk/EFL results are what the test should print if not for issue (1), but they are probably like that because of another bug only, not because the right thing happens. Thanks for the insight, Alexey! I will check debug the test and see what happens in retryAfterFailedCacheOnlyMainResourceLoad(). I also should rename the GTK-specific test, but will do that once we know a bit more about what's going on. 920142 6 spena 2013-08-23 01:11:14 -0700 I said "GTK-specific test" when I meant "GTK-specific bug". Anyway, it is correctly closed as invalid, and another one could be open if needed. I set a breakpoint in FrameLoader::retryAfterFailedCacheOnlyMainResourceLoad, but it is not hit in the GTK port. 920146 7 spena 2013-08-23 01:24:50 -0700 The GTK port produces the same output in http/tests/navigation/post-frames-goback1-uncached.html and http/tests/navigation/post-frames-goback1.html so I imagine this is consistent with your theory that we are ignoring the Cache-Control.