226336 - Security Error while trying to load Template from chrome

Status: RESOLVED EXPIRED

(Core :: XSLT, defect)

Description

[TheSeer]

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

Security Error: Content at file:///storage/xul/content/dev/test.xml may not load
data from chrome://dev/content/test.xsl.

Reproducible: Always

Steps to Reproduce:
1. copy attached test.xml and test.xsl to a chrome reg'd dir
2. modify the href in test.xml to match the location
3. try to load the page

Actual Results:  
Error as in Details

Expected Results:  
Rendered the (xul) page

Removing the path information from the href seems to fix the problem. I'm
currently unaware if the file is treated as chrome:// or file:// using that
workaround and what security-implications that may have...

Comment 1

[TheSeer]

Attachment: Basic XML File with xsl stylesheet link

Comment 2

[TheSeer]

Attachment: Simple Hello world example to show bug ( basic xul window with a button )

Comment 3

[Boris Zbarsky [:bzbarsky]]

> I'm currently unaware if the file is treated as chrome:// or file:// using that

It's treated as file://.

The error is correct -- non-chrome things may NOT link to chrome, except in a
few very controlled circumstances (and even those, imo, should be eliminated).

Comment 4

[TheSeer]

According to your quote you got me wrong..
Maybe my explanation wasn't good.

I am loading an XML-File from chrome://dev/content/test.xml with an embeded link
to an XSL using the same full uri ( chrome://dev/content/test.xsl) which get's
denied by the security manager.

So for some reason the test.xml is - even though loaded from chrome://
considered to be file:// which is WRONG and thus imho a BUG.

My Comment about not beeing sure about the 'file' was a) about the XSL loaded
and ab) wether the result would run in a file:// or chrome:// context.

Comment 5

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 6

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.