1249572 - XSLTProcessor.importStylesheet fails when <import> is used

Status: VERIFIED FIXED

(Core :: XSLT, defect)

Description

[slosd]

Starting with 45a builds importing another xsl file in a stylesheet fails:

testA.xsl
```
    <?xml version="1.0"?>
    <xsl:stylesheet version="1.0"
                    xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
                    xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
        <xsl:import href="testB.xsl"/>
    </xsl:stylesheet>
```

testB.xsl
```
    <?xml version="1.0"?>
    <xsl:stylesheet version="1.0"
                    xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
                    xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    </xsl:stylesheet>
```

test.js
```
    var xsltProcessor = Cc['@mozilla.org/document-transformer;1?type=xslt'].createInstance(Ci.nsIXSLTProcessor);
    xsltProcessor.importStylesheet('testA.xsl');
```

importStylesheet throws this exception:
```
    Exception { message: "", result: 2153775131, name: "", filename: "test.js", lineNumber: …, columnNumber: 0, data: null, stack: "…", location: XPCWrappedNative_NoHelper }
```

This might be related to bug 1072150

Comment 1

[:Gijs (he/him)]

(In reply to slosd from comment #0)
>     Exception { message: "", result: 2153775131, name: "", filename:
> "test.js", lineNumber: …, columnNumber: 0, data: null, stack: "…", location:
> XPCWrappedNative_NoHelper }

This is NS_ERROR_XSLT_LOAD_BLOCKED_ERROR. It is thrown in only two places:

https://dxr.mozilla.org/mozilla-central/search?q=NS_ERROR_XSLT_LOAD_BLOCKED_ERROR&=mozilla-central&redirect=true

both in https://dxr.mozilla.org/mozilla-central/rev/d5daf10d3b74b04e8fa63c4e5429de8a0adf79f8/dom/xslt/xslt/txMozillaStylesheetCompiler.cpp .

> This might be related to bug 1072150

What makes you say that - did you speak to Bobby? It's not obvious from this report. From a quick check of the csets involved, I don't see why it would be, but I could be wrong.

Unless you have solid information about this, it's probably better if you use mozregression ( http://mozilla.github.io/mozregression/ ) to narrow down when exactly the import of another XSLT file broke in this way. Given you already know it happened in the 45 timeframe you could run something like:

mozregression --good 44

and, assuming you can easily test this by opening a URL and have a reasonably fast internet connection, it should take only 10-20 minutes to figure out when exactly this broke, and if that really does match that bug or not.

Comment 2

[slosd]

(In reply to :Gijs Kruitbosch from comment #1)
> What makes you say that - did you speak to Bobby? It's not obvious from this
> report. From a quick check of the csets involved, I don't see why it would
> be, but I could be wrong.
It was just a stab in the dark. Given that I didn't have an error message the 
latest changes in the importStylesheet method was the first thing I looked at. 

mozregression points me to https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ec1df10696abe9fdb1f54c50e1e7cdb2d8405f21&tochange=4b6ae937a03d04142124fd8f45ac5b2441bd0590 (Bug 1222624)

This is what I tested:

page.xul
	<?xml version="1.0"?>
	<!DOCTYPE page SYSTEM "chrome://addon_id/locale/gcLocale.dtd">
	<page xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
	      <script type="application/javascript">
	        const { classes: Cc, interfaces: Ci } = Components;
	
	        var requestXsl = new XMLHttpRequest();
	        requestXsl.open('GET', "chrome://addon_id/content/testA.xsl", false);
	        requestXsl.send(null);
	        var xsl = requestXsl.responseXML;
	
	        var xsltProcessor = Cc['@mozilla.org/document-transformer;1?type=xslt'].createInstance(Ci.nsIXSLTProcessor);
	        xsltProcessor.importStylesheet(xsl);
	      </script>
	</page>

Comment 3

[:Gijs (he/him)]

(In reply to slosd from comment #2)
> mozregression points me to
> https://hg.mozilla.org/integration/mozilla-inbound/
> pushloghtml?fromchange=ec1df10696abe9fdb1f54c50e1e7cdb2d8405f21&tochange=4b6a
> e937a03d04142124fd8f45ac5b2441bd0590 (Bug 1222624)

Thanks, this is really helpful!

Jonas, can you take a look? I don't know enough about XSLT to do much more triage myself here, though naively I would suspect that the issue is that an import from a stylesheet breaks because it's not being imported directly from a document, so mLoadingDocument is null, which is a check that looks like it was added in bug 1222624.

Comment 4

[Andrew Overholt [:overholt]]

Giving to Jonas seeing as this is a regression.

Comment 5

[Peter Van der Beken [:peterv]]

I think Jonas made it required for chrome code to call |init(global)| on the XSLTProcessor first. You can't actually do that, since he added it to the xpidl but not to the webidl file, as I pointed out in review and in a followup needinfo in bug 1222624 :-/.

Comment 6

[Peter Van der Beken [:peterv]]

I think we should back out bug 1222624. Even when calling init(...) things don't work.

Comment 7

[Johnny Stenback (:jst)]

I'm afraid we just released 45 with this in it :( If we need to pull 45 for this and re-spin, we need to know ASAP.

Comment 8

[Peter Van der Beken [:peterv]]

Fixed by a backout. This should end up in 45.0.1 if we happen to do one.

https://hg.mozilla.org/integration/mozilla-inbound/rev/fe5bc1369d3e

Comment 9

[Sylvestre Ledru [:Sylvestre]]

Added to the release notes with "XSLTProcessor.importStylesheet was failing when <import> was used (1249572)" as wording

Comment 10

[Vlad Bacia-Mociran [:VladB]]

Hi,

I have tried to tested your issue on FF release 45.0.1 candidate build and could not reproduce it due to some errors encountered. 
I have created testA.xsl, testB.xsl and test.js files, as mentioned in the description. Also, I have created a HTML file that points to the test.js file and opened the HTML file in Firefox. In the console I have received the next error: `Cc is not defined`. Have I missed something ?

I have tried to run page.xul file from comment 2 in Firefox but I cannot run it. Could you provide more steps in order to verify this issue?

Thank you.

Comment 11

[Peter Van der Beken [:peterv]]

Easiest way is probably to open the 'Browser Console' and paste:

var importedDoc = `data:text/xml;charset=utf-8,${encodeURIComponent('<?xml version="1.0"?><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" />')}`;
var importingDoc = new DOMParser().parseFromString(
   `<?xml version="1.0"?>
    <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
      <xsl:import href="${importedDoc}"/>
    </xsl:stylesheet>`, "text/xml");
var xsltProcessor = Cc['@mozilla.org/document-transformer;1?type=xslt'].createInstance(Ci.nsIXSLTProcessor);
xsltProcessor.importStylesheet(importingDoc);

The result should just be undefined, no exception should be thrown (I see '[Exception... "<no message>"  nsresult: "0x8060001b (<unknown>)"  location: "JS frame :: debugger eval code :: <TOP_LEVEL> :: line 8"  data: no]' in a build that doesn't have the fix).

Comment 12

[Andrew Overholt [:overholt]]

(In reply to Peter Van der Beken [:peterv] from comment #11)
> Easiest way is probably to open the 'Browser Console' and paste:

Note that before you do this you have to enable JS in the browser console:
- open devtools (Ctrl/Cmd-Shift-i)
- click on gear icon
- under "Advanced settings", toggle the "Enable browser chrome and add-on debugging toolboxes" checkbox

Thanks for the instructions, Peter!

Comment 13

[Vlad Bacia-Mociran [:VladB]]

Thank you for the instructions, they were very helpful.

I have tested your issue on Ubuntu 14.04 x64 with Fx 45.0.1 release candidate (Build ID: 20160315153207) and Fx 45.0.1esr candidate 2 (Build ID: 20160316151906) and could not reproduce it. 

I have followed the steps from comment 12 and comment 11 and the result displayed in console is `undefined` without any other exceptions.

Comment 14

[Liz Henry (:lizzard) (relman/hg->git project)]

Fixing status flags since this was fixed in 45.0.1.