Closed Bug 439721 Opened 16 years ago Closed 16 years ago

XSLT fails if in local path outside of xml file's path

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 397894

People

(Reporter: txe, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

Firefox 3 fails to process XSLT files if they are outside of the current XML file's path (or descendant paths).

For example, these work:

<?xml-stylesheet type="text/xsl" href="test.xsl"?>
<?xml-stylesheet type="text/xsl" href="sub/test.xsl"?>

But these fail:

<?xml-stylesheet type="text/xsl" href="../test.xsl"?>
<?xml-stylesheet type="text/xsl" href="../sub/test.xsl"?>

This seems to only be for local files (not handled by a web server). I can reproduce it in both Ubuntu and Vista.

Firefox 2 and IE7 don't have this problem.

Here are my simplified test files:

test/xsl/test.xsl:

    <?xml version="1.0" encoding="UTF-8"?>
    <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:template match="/test"><html><body><h1>This worked: <xsl:apply-templates /></h1></body></html></xsl:template>
    </xsl:stylesheet>


test/xsl/test.xml: (xsl in same path, works)

    <?xml version="1.0"?>
    <?xml-stylesheet type="text/xsl" href="test.xsl"?>
    <test>xsl in same path</test>


test/test.xml: (xsl in child path, works)

    <?xml version="1.0"?>
    <?xml-stylesheet type="text/xsl" href="xsl/test.xsl"?>
    <test>xsl in child path</test>


test/xsl/sub/test.xml: (xsl in parent path, FAILS)

    <?xml version="1.0"?>
    <?xml-stylesheet type="text/xsl" href="../test.xsl"?>
    <test>xsl in parent path</test>


test/xml/test.xml: (xsl in sibling path, FAILS)

    <?xml version="1.0"?>
    <?xml-stylesheet type="text/xsl" href="../xsl/test.xsl"?>
    <test>xsl in sibling path</test>


Reproducible: Always

Steps to Reproduce:
1. create an xml file which references an xsl file in the same path
2. view the xml file in firefox
3. verify that it works (html is rendered)
4. move the xsl file to the parent directory
5. update the xml to point to the xsl file (so the path has ".." in it)
6. verify that it fails (html is not rendered)
Actual Results:  
On Vista and Ubuntu, XSLT fails to work if it's a local file not inside the XML file's path (or descendant paths).  If the XML and XSL are remote or being served by a web server, it works.  So the bug seems to be for file:// urls only.

Expected Results:  
I expect XSLT to work even if it's in a parent or sibling directory, like it did in Firefox 2.
I experienced the same problem using an absolute path to link from xml to xls file. When the xml exists in the same location as the xsl than FF3 does the translation as expected.
When I move the xml to any other location than FF3 does a weired translation stripping all XML tags and showing the content of the tags as an unstructured couninous text.

I'd expect FF3 to do translation correctly or showing the XML as if there where no xsl at all (providing a message in the status bar).

bye
TT
There is a work around, which I found on a forum: 
http://forums.mozillazine.org/viewtopic.php?f=25&t=670995

Here it is:

1) type about:config in the address bar
2) change security.fileuri.strict_origin_policy to false

Seems like the default security settings in Firefox 3 are too aggressive for local XSL to work properly.  Changing that setting completely fixed the problem for me, both on Vista and Ubuntu.
Thanks, this works for me too. 

But I feel there should be some hint when this restriction applies in standard configuration. 

And (as I said before) when the XML is not applied (because of the restriction) the XML schould be presented as structured Text as if there was no XSL at all.
Yeah, that make sense.  Nice error messages in particular would be great.  Of course, it's traditionally been hard to get useful XSLT error messages (or debugging info) in Firefox and IE, so my expectations weren't (and aren't) very high.  Maybe someday someone will make a decent XSLT debugging plugin?  
This is a duplicate of bug 397894.
Thanks for pointing that out!  I didn't look back to 2007 for it, since it started (for me) with Firefox 3.0.  

Looks like Firefox developers need to favor either:

a) security for 95% of users --or--
b) convenience for 5% of users (mostly developers)

Too bad we can't just download an extension which turns that strict security setting to false.  Then, people on intranets or whatever who need local XSLT can [be told to] install the extension.  It's a lot easier to tell someone to install a particular extension than to explain to them how to hack about:config.

Maybe someone has done this already?
In my view the main problem with this bug is, that FF seams to do some XSL translation (it strips all xml tags) and one could feel there was some error in the XSL file.

For me the restrictive default was ok when

a) users would see the XML file as if the XSL was not given at all and
b) users would get an an info that XSL processing is disabled because of a security restriction.

I belive that most FF users are smart enougth to find the security setting to toggle in this case.

bye
TT
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.