Bug 21530 – Don't test blocking 255.255.255.255 with no port

• Component: Page Loading
• Status: RESOLVED FIXED

[Pam Greene (IRC:pamg)]

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.

[Pam Greene (IRC:pamg)]

Created attachment 24274 [details]
Fixed test and Mac + Leopard results

Start with port 1 on the initial load rather than no port.

[Darin Adler]

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

[Brett Wilson (Google)]

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.

[Pam Greene (IRC:pamg)]

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 Fisher (:fishd, Google)]

+darin since he might not have seen pam's comment.

[Pam Greene (IRC:pamg)]

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.

[Pam Greene (IRC:pamg)]

Added a ChangeLog entry and landed in r42188.