Every dom-level1-core mochitest loads http://www.w3.org/StyleSheets/activity-home.css over the network

RESOLVED FIXED in mozilla2.0b12

Status

()

Core
DOM
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: ted, Assigned: philor)

Tracking

Trunk
mozilla2.0b12
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(status1.9.2 .17-fixed, status1.9.1 .19-fixed)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

7 years ago
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....
(Reporter)

Comment 2

7 years ago
Sure. Do you have any idea where I'd report it?
I guess the webapps working group, since the DOM WG is no more?

Comment 4

7 years ago
"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. "
Created attachment 507108 [details]
Removes the stylesheet

The stylesheet doesn't seem to be needed here, does it?
Assignee: nobody → mounir.lamouri
Status: NEW → ASSIGNED
Attachment #507108 - Flags: review?(bzbarsky)
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?
Attachment #507108 - Flags: review?(bzbarsky)
Attachment #507108 - Attachment is patch: false
(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.
(Reporter)

Comment 9

7 years ago
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?
(Reporter)

Comment 11

7 years ago
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.)
(Assignee)

Comment 12

7 years ago
Created attachment 510227 [details] [diff] [review]
switch to relative URI

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/!!'
Assignee: mounir.lamouri → philringnalda
Attachment #507108 - Attachment is obsolete: true
Attachment #510227 - Flags: review?(bzbarsky)
(Reporter)

Updated

7 years ago
Duplicate of this bug: 627011
Attachment #510227 - Attachment is patch: true
Attachment #510227 - Attachment mime type: application/octet-stream → text/plain
Comment on attachment 510227 [details] [diff] [review]
switch to relative URI

I guess....
Attachment #510227 - Flags: review?(bzbarsky) → review+
(Assignee)

Updated

7 years ago
Summary: test_PIsetdatanomodificationallowederrEE.html loads http://www.w3.org/StyleSheets/activity-home.css over the network → Every dom-level1-core mochitest loads http://www.w3.org/StyleSheets/activity-home.css over the network
(Assignee)

Comment 15

7 years ago
http://hg.mozilla.org/mozilla-central/rev/3001bf0ba0a3
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b12
status1.9.1: --- → ?
status1.9.2: --- → ?
Version: unspecified → Trunk
(Assignee)

Comment 16

7 years ago
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/194dd9a57615
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/592245536089
status1.9.1: ? → .18-fixed
status1.9.2: ? → .15-fixed
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.
You need to log in before you can comment on or make changes to this bug.