In security/block-test.html, the action taken when trying to load the initial resource (http://255.255.255.255/test.jpg) depends on the network proxy settings of the machine running the test. That nondeterminism should be removed by not testing the case with no ports specified.
Created attachment 24274 [details] Fixed test and Mac + Leopard results Start with port 1 on the initial load rather than no port.
Comment on attachment 24274 [details] Fixed test and Mac + Leopard results This doesn't seem right. We do need a test of the case with no specific port. It's a separate code path, and in the past there have been bugs with it. And this regression test will catch us if we break it again. I assume that people at Google are running into this because of the Google proxy configuration. Or is this a Chrome-specific issue? What possible solutions are there besides removing the test? review- for now
Many proxies (such as squid proxies) will send you content with an error message in it rather than reporting a nonexistant domain. Although I think this is stupid, it's pretty common. I don't think it's possible to write a test that depends on the network to return that some address doesn't exist.
Could we split the no-port case into its own test file? That way Chromium (and any other ports subject to the same problem) could skip that one part while still keeping deterministic coverage of all the rest.
+darin since he might not have seen pam's comment.
Created attachment 29204 [details] split no-port case into separate test For concrete consideration, here's a patch that splits the test as described above, moving the no-port case to a separate file.
Added a ChangeLog entry and landed in r42188.