REGRESSION: http/tests/loading/redirect-with-no-location-crash.html failing on Tiger bot Example: http://build.webkit.org/results/Tiger%20Intel%20Release/r48458%20(4387)/results.html CCing the folks I see from: http://trac.webkit.org/browser/trunk/LayoutTests/http/tests/loading/redirect-with-no-location-crash.html
Tiger may just need new results checked in.
http://trac.webkit.org/changeset/48413 is the regressing change (where the test was added).
(In reply to comment #2) > http://trac.webkit.org/changeset/48413 is the regressing change (where the test > was added). How can it be a regression being this a new test? I think you were right in your previous comment where you say that probably Tiger just needs different results checked in.
It's not a regression, Tiger fails the new test, it needs to be fixed to pass it, having a bug report is important though, thanks!
(In reply to comment #3) > How can it be a regression being this a new test? I think you were right in > your previous comment where you say that probably Tiger just needs different > results checked in. I would say it needs to be either fixed or skipped. I don't think checking in a failed load as expected result is the way to go here.
Well, it's a regression in the sense that the bots were green before the checkin and are red afterwards. :) Either way, we need to check in new results or roll out the change. I don't know which results are correct, or why Tiger's would be different from normal mac results.
Either way, we can't leave the bots green. :) So action is needed asap. Sounds like you guys are on it, which is great. Thanks!
(In reply to comment #6) > Well, it's a regression in the sense that the bots were green before the > checkin and are red afterwards. :) Either way, we need to check in new results > or roll out the change. I don't know which results are correct, or why Tiger's > would be different from normal mac results. Or skip the test, which is what we do when we fail new tests in GTK+, I would say - we don't roll them back because our code is wrong. Checking in different results would be OK if the expected result for a load that results in a Location-less 302 response is for it to fail in Tiger. If this is actually the result of a different behavior in, say, Tiger's CFNetwork that is not going to be fixed, or if a fix is not planned for the short term, skipping would be the option, rolling out the change doesn't seem sensible to me. I have taken action to fix the other rednesses the change caused because they were caused by bad expected results, but I am not in a position to decide what to do for this test for Tiger, so we need input from a Mac/Tiger person.
This issue with 302 is a known bug with the CFNetwork from the Tiger era that was fixed by the time Leopard was released. Apple folks can refer to <rdar://problem/5081884> for details. My recommended course of action is to add this test to the Skipped list for Tiger until we can explore a workaround.
(In reply to comment #9) > This issue with 302 is a known bug with the CFNetwork from the Tiger era that > was fixed by the time Leopard was released. > > Apple folks can refer to <rdar://problem/5081884> for details. > > My recommended course of action is to add this test to the Skipped list for > Tiger until we can explore a workaround. I have landed r48487, skipping the test for Tiger, thanks for the comment, and the rubber stamp, and Eric for bringing this up! I'll leave the bug open.
Thank you for the quick response.
Tiger is no longer supported.