This bug is a meta bug to track fixing all tests which load external URLs.

I ran mochitest-browser-chrome with Wireshark running, and here's the packet capture log. I tried to exclude my local network traffic, but a bunch of it slipped in anyway. Sorry about that.

(In reply to comment #1) > Created attachment 506990 [details] > mochitest-browser-chrome wireshark packet capture log > > I ran mochitest-browser-chrome with Wireshark running, and here's the packet > capture log. I tried to exclude my local network traffic, but a bunch of it > slipped in anyway. Sorry about that. Thanks!

mochitest-chrome is not terribly interesting, it's got the stock live bookmarks stuff, but nothing else AFAICT. There's an interesting request at the beginning that I didn't notice in the browser-chrome log, although I assume it's there as well. Apparently we GET http://www.mozilla.org/ looking for a microsummary or something? It looks like: GET / HTTP/1.1 Host: www.mozilla.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20110105 Firefox/4.0b9pre Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip, deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Connection: keep-alive X-Moz: microsummary

Here's mochitest-1/5. There are a couple of interesting things in this log, I'll file some bugs. Conveniently, we get Referer headers when normal Mochitests do HTTP requests. :)

Here's mochitest-2/5, which only seems to have one misbehaving test.

mochitest-3/5 also has only one misbehaving test.

mochitest-4/5 appears to have no offenders. Hooray!

mochitest-5/5 has just one naughty test.

reftest and crashtest were totally clean runs. Hooray! xpcshell seems to hit https://www.google.com/, but for the life of me I cannot find where that's happening.

jstestbrowser and mochitest-a11y were also clean runs. I think I'm done here.

(In reply to comment #3) > There's an interesting request at the beginning that I didn't notice in the > browser-chrome log, although I assume it's there as well. Apparently we GET > http://www.mozilla.org/ looking for a microsummary or something? It looks like: > > GET / HTTP/1.1 > Host: www.mozilla.org > User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20110105 > Firefox/4.0b9pre > Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 > Accept-Language: en-us,en;q=0.5 > Accept-Encoding: gzip, deflate > Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 > Keep-Alive: 115 > Connection: keep-alive > X-Moz: microsummary I looked last night and couldn't actually find the test for this. Starting to think maybe it's something in the browser code?

Yeah, I have no idea how the microsummary code works. Presumably it's getting run on some of the default bookmarks?

(In reply to comment #12) > Yeah, I have no idea how the microsummary code works. Presumably it's getting > run on some of the default bookmarks? Oh! That's possible :/

So will the test prefs change from a .PAC file to routing everything through the JS proxy server, allowing it to log bogus requests?

I don't know of any plans to do that at this time, but that sounds like it would be a useful path to take. See also bug 616182, which requests that we return a fixed IP for all DNS lookups controlled via a pref.

There doesn't seem to be anything left to do here. We can reopen this if something is broken in the meantime.

Re-opening because there's a couple new dependent bugs.

Fixed again. :)