305035 - XML content loaded via data: URL doesn't transform (XSLT ignored)

Status: RESOLVED INVALID

(Core :: XSLT, defect)

Description

[Sean McMurray]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.11) Gecko/20050729
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.11) Gecko/20050729

document.getElementById('myFrame').contentDocument.location.href =
'data:text/xml,<?xml version="1.0"?><?xml-stylesheet type="text/xsl"
href="test.xsl"?><document><content/></document>';

places the xml in the iframe, but fails to do the xslt transform.
It presents as xml text.

Reproducible: Always

Steps to Reproduce:
1.load xml content into iframe via data: URL
2.
3.

Actual Results:  
iframe presents as xml text

Expected Results:  
iframe should present transformed document.

Comment 1

[Jesse Ruderman]

Attachment: testcase (zip)

Comment 2

[Jesse Ruderman]

Maybe the same-origin check for XSLT is getting confused by the document being
at a data: URL.

Comment 3

[Sean McMurray]

I tried with a relative url in the <?xml-stylesheet/> and with an absolute
chrome: url.

Both fail to transform.

Comment 4

[Peter Van der Beken [:peterv]]

How do you expect a relative URL to work resolved against a data URL? And the
access to chrome is probably blocked by security checks, any messages in the JS
console?

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Actually, i think there might be a bug here. For data-documents we give the
document the same principal and baseuri as the original document, i think. So
rather then doing

rv = secMan->CheckSameOriginURI(mDocumentURI, url);

we should maybe use the uri of the principal rather mDocumentURI. We'd need to
make the same change for xsl:import and document() too.

I wonder how XMLHttpRequest deals with this.

Comment 6

[Peter Van der Beken [:peterv]]

You're talking about the absolute url case?

Comment 7

[Sean McMurray]

(In reply to comment #4)

I am doing this from inside the same chrome, so there shouldn't be security blocks.

No messages in the JS console.

Comment 8

[Boris Zbarsky [:bzbarsky]]

> and baseuri as the original document

No, I don't believe we give it the same base URI... where do you see that happening?

And why are we calling CheckSameOriginURI anyway?  We should use CheckSameOriginPrincipal, since that will also work right with document.domain, etc...

Comment 9

[Bjoern Hoehrmann]

href="test.xsl" resolves to "data:test.xsl" which is not a meaningful data:
resource identifier. The test case cannot work as intended; the bug report is invalid.

Comment 10

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Resolving as invalid, we have other bugs covering using better security manager functions.