Closed Bug 628966 Opened 14 years ago Closed 14 years ago

test_bug428847.html (by way of file_bug428847-1.xhtml) loads http://www.mozilla.com/whatever.xsl over the network

Categories

(Core :: XML, defect)

Product:
Core
Component:
XML
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla5
Tracking Flags:
Tracking Status
status2.0 --- .1-fixed
status1.9.2 --- .17-fixed
status1.9.1 --- .19-fixed

People

(Reporter: ted, Assigned: philor)

References

(Blocks 1 open bug)

Details

Attachments

(2 files, 1 obsolete file)

Trunk and 2.1 and 2.0 - Use example.com and a todo
(deleted), patch
sicking
: review+
Details | Diff | Splinter Review
1.9.2 and 1.9.1 - just example.com
(deleted), patch
Details | Diff | Splinter Review
I ran mochitest-1/5 with Wireshark running and caught this test making a HTTP request: GET /whatever.xsl HTTP/1.1 Host: www.mozilla.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20110105 Firefox/4.0b9pre Accept: text/xml,application/xml,application/xhtml+xml,*/*;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/content/base/test/file_bug428847-1.xhtml Origin: http://mochi.test:8888 We should fix this to load the stylesheet from the test server (using a mochi.test or example.com URL).
Version: unspecified → Trunk
I'm puzzled about what happened here. Apparently the point of the test was that we would deny the load of http://www.mozilla.com/whatever.xsl (so it didn't matter that it wasn't local, because we weren't going to load it), and the test checked whether we still loaded the page that tried to apply it, rather than displaying an error message. Then, going by http://hg.mozilla.org/mozilla-central/rev/f1af6bb87895, apparently cross-site XHR made it so that we did load it, and then... I guess applying that 404 page as a stylesheet resulted in something which didn't have a <body>. If we *meant* to allow any page to load any other cross-origin page as a stylesheet, then the test should be removed, rather than just having the part where we test the results commented out. If there are some sorts of cross-origin stylesheet loads that are still denied (file:/// maybe?), then the test should be trying to load one of them instead. If we totally didn't mean to break denying cross-origin stylesheet loads, then rather than commenting out the test telling us we did, we should be blocking on fixing that.
blocking2.0: --- → ?
Curse you, Bugzilla, I wanted sicking getting https://bugzilla.mozilla.org/show_bug.cgi?id=628966#c1 in his bugspam, not getting a second comment waving up the page saying "read that, please?"
Oh, I guess I could just run the blessed test and see how it's failing, couldn't I? I take back my nom here, I can't morph this enough to be both the bug about hitting the network and the bug about breaking the test. What's happening is that we're getting a "" error message, so cross-site XHR regressed bug 428847, but the right fix *here* is to change the PI to load something local (and to change from commenting out a failing test to making it a todo). The regression, and whether it should block, needs to be a separate bug.
blocking2.0: ? → ---
Copy-paste is hard. A "Error loading stylesheet: A network error occurred loading an XSLT stylesheet: http://www.mozilla.com/whatever.xsl" error message.
Fixes the network access by using the proxied example.com, and switches the commented-out test to be a todo.
Assignee: nobody → philringnalda
Status: NEW → ASSIGNED
Attachment #508304 - Flags: review?
Attachment #508304 - Attachment is patch: true
Attachment #508304 - Attachment mime type: application/octet-stream → text/plain
Attachment #508304 - Flags: review? → review?(jst)
Blocks: 630089
Since the test isn't broken on 1.9.2
Attached patch 1.9.1 - example.com and proxying (obsolete) (deleted) — — Splinter Review
And it isn't broken on 1.9.1, but www.example.com is because when I was proxying it on 1.9.2 I didn't yet need it on 1.9.1
status1.9.1: --- → ?
status1.9.2: --- → ?
Comment on attachment 512082 [details] [diff] [review] 1.9.1 - example.com and proxying Wound up needing the www.example.com proxying for another patch, so this one won't need to land it.
Attachment #512082 - Attachment is obsolete: true
Whiteboard: [needs review jst]
Johnny, any chance you can review this soon? We'd really like to turn off outbound access for build machine soon, and this is blocking it.
Attachment #512080 - Attachment description: 1.9.2 - just example.com → 1.9.2 and 1.9.1 - just example.com
Attachment #508304 - Attachment description: Use example.com and a todo → Trunk and 2.1 and 2.0 - Use example.com and a todo
Whiteboard: [needs review jst]
Needs a 2.1 landing for sanity, probably.
http://hg.mozilla.org/mozilla-central/rev/ff5717c3e48c
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: fixed-in-cedar
Target Milestone: --- → mozilla2.2
http://hg.mozilla.org/releases/mozilla-2.1/rev/4c176899228b If somebody suggests that I should land this on 1.9 too, they won't see my smile. Just sayin'. ;-)
If anything runs tests on 1.9 and shows its head by hitting the network, that's just a handy way to spot something that's gone rogue and needs to be shot. Thanks again for the huge stream of checkins :)
Thanks everyone!
status2.0: --- → .1-fixed
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: