http/tests/navigation/relativeanchor-goback is failing on the buildbot.
<rdar://problem/5237081>
Darin mentioned that he thought that this was due to Adele's change to form element saving.
This was, indeed, caused by http://trac.webkit.org/projects/webkit/changeset/21738
The failing test seems straighforward enough once I read it, but I keep thinking that I understand it, and then I cannot reproduce it inside the browser. (The test relies heavily on dump render tree.)
I might understand what is going on here, but I haven't confirmed yet. I think that these new results may actually be correct. The reason that I have been having so much trouble reproducing the in browser, is that the browser has a back-forward cache, and DumpRenderTree turns the back-forward cache off. So When this test "goes back" it actually kicks off a new load. And when we kick off a new load in the browser, we do not expect the form input to be retained. I think that this test was exposing the very bug that Adele fixed. Probably once upon a time, it worked as expected because there was a time when the back-forward list was enabled for DumpRenderTree. But now that it is disabled, I actually think that it is correct that the form values are reset to their defaults. I am going to work on confirming this.
I have confirmed that re-enabling the back-forward cache for DumpRenderTree causes the test to pass. As I said in my previous comment, I think that this test should only pass with the back-forward cache enabled. I think that it *was* passing in DumpRenderTree before because it was hitting that case that Adele fixed. I am going to do a bit more investigation.
Okay, I looked at the in the Debugger, and I feel confident that my assessment is correct. The relative URL should be treated as a different URL when it is loaded rather than "gone back to" via the back button. We have always treated them as separate if you re-enter the URL in the address bar, so it seems the same should hold for DumpRenderTree. I will edit the test to be less confusing and update the expected results.
Created attachment 14905 [details] Patch Here is a patch that uploads new results for the test. I did not end up changing the text in the js-file to make the results more clear because it affects to many other tests. Seems like something that should be done after a fuller investigation of all of the tests that use that js file.
Comment on attachment 14905 [details] Patch Yay!
Fixed with r22076.