Bug 120105 – http/tests/navigation/post-frames-goback1-uncached.html fails on Qt, GTK+, and EFL bots

• Status: NEW
• Component: Page Loading

[Ryosuke Niwa]

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

[Alexey Proskuryakov]

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

[Ryosuke Niwa]

Should we simply rebaseline it then?

[Alexey Proskuryakov]

Landing custom results sounds OK for now, but ideally, DumpRenderTree should be changed on these platforms, I think.

[Alexey Proskuryakov]

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.

[Simon Pena]

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

[Simon Pena]

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.

[Simon Pena]

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.