Running mochitest-2/5 with Wireshark running, I caught this test making a network request: GET /StyleSheets/activity-home.css HTTP/1.1 Host: www.w3.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20110105 Firefox/4.0b9pre Accept: text/css,*/*;q=0.1 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 Referer: http://mochi.test:8888/tests/dom/tests/mochitest/dom-level1-core/test_PIsetdatanomodificationallowederrEE.html Looks like it's loading a stylesheet from w3.org. We should fix this to not hit the network.

Can we also report this to the W3C? Their test suite should really be self-contained....

Sure. Do you have any idea where I'd report it?

I guess the webapps working group, since the DOM WG is no more?

"The WebApps WG Drives DOM Specifications. The W3C Web Applications Working Group has taken over responsibility for the Document Object Model specifications, including a new revision of DOM Level 3 Events, a new DOM Core specification, and potentially any errata on older DOM specifications. Discussion can be directed to either the public-webapps@w3.org or the www-dom@w3.org mailing lists. "

The stylesheet doesn't seem to be needed here, does it?

Probably not, but: 1) The patch doesn't take it out 2) http://mxr.mozilla.org/mozilla-central/search?string=activity-home says there are 526 other files that load this stylesheet. Think "every single test in the DOM L1 test suite". Maybe none of them need it (pretty likely, in fact). But maybe the right fix here is to have the proxy mochitests run against proxy this stylesheet to something, instead of hacking all the tests?

(In reply to comment #6) > Probably not, but: > > 1) The patch doesn't take it out Damn, again! I think I should have a script attaching my patches and make sure they are not empty :( > 2) http://mxr.mozilla.org/mozilla-central/search?string=activity-home says > there > are 526 other files that load this stylesheet. Think "every single test in > the DOM L1 test suite". Maybe none of them need it (pretty likely, in > fact). But maybe the right fix here is to have the proxy mochitests run > against proxy this stylesheet to something, instead of hacking all the > tests? Indeed, I didn't check if it was used by other tests. I assumed it wasn't, given that this bug was specific, but it seemed weird. A solution could be to update all the tests in a batch. Easy to do but a little annoying to review. Do we already have such a system to proxy the stylesheet?

We already proxy other domains (mochi.test, say); there's no reason we couldn't proxy www.w3.org, I assume.

server-locations.txt lists all the hosts we proxy through the Mochitest httpd.js: http://mxr.mozilla.org/mozilla-central/source/build/pgo/server-locations.txt

(In reply to comment #9) > server-locations.txt lists all the hosts we proxy through the Mochitest > httpd.js: > http://mxr.mozilla.org/mozilla-central/source/build/pgo/server-locations.txt Ted, can we easily redirect a specific path (say www.w3.org/StyleSheets/) to a specific local directory?

All hosts get proxied to the same place, which is like $objdir/_tests/testing/mochitest if you run from the objdir. (We may have renamed that recently, but you'll find server.js there.)

Proxying would be reasonable if we were running unmodified tests, but we aren't, we've already made all sorts of changes and additions to make them work with the mochitest harness. This patch just makes one more, loading the (unnecessary, vaguely horrifying, and with trailing whitespace preserved) stylesheet from a relative URI. Rather than actually looking at the patch, I recommend reviewing the oneliner that produced it, find dom/tests/mochitest/dom-level1-core/ -type f | xargs perl -pi -e 's!http://www.w3.org/StyleSheets/!!'

Comment on attachment 510227 [details] [diff] [review] switch to relative URI I guess....

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/194dd9a57615 http://hg.mozilla.org/releases/mozilla-1.9.1/rev/592245536089

The "3.6.15" we're releasing today does not fix this bug, the release containing this bug fix has been renamed to "3.6.16" and the bugzilla flags will be updated to reflect that soon. Today's release is a re-release of 3.6.14 plus a fix for a bug that prevented many Java applets from starting up.