1954841 - XSLTProcessor.transformToFragment behavior has changed

Status: RESOLVED FIXED

(Core :: XSLT, defect)

Description

[Brandon Gurwitz]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:137.0) Gecko/20100101 Firefox/137.0

Steps to reproduce:

The XLSTProcessor.transformToFragment() function with the first parameter an element (not a document). It behaves differently than it did in Firefox 136.
A simple sample of this behavior can be seen at the following link:
https://jsfiddle.net/nuhgxskw/1/

Actual results:

The element itself submitted as the first parameter to transformToFragment cannot be found by XSLT template's match rule. In the provided jsfiddle, the template with match="root" is not applied.
(Note, documentElement here used is for illustrative purposes. A real web application passes elements from a middle of large XML. Cloning the element to a wrapper would also not be effective because of the content size.)

Expected results:

The template match="root" should be applied to match the passed element itself. That was the behavior of Firefox 136 and earlier. If this is a planned change, then it should be indicated in the documentation and release notes for Firefox 137: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/137

Comment 1

[Robert Longson [:longsonr]]

Could you use https://mozilla.github.io/mozregression/ to determine a regression range?

Comment 2

[Brandon Gurwitz]

(In reply to Robert Longson [:longsonr] from comment #1)

Could you use https://mozilla.github.io/mozregression/ to determine a regression range?

My apologies for taking a few days to respond, I got the regression tool working and found some more detailed information. It appears that the change in behavior started with a nightly build that was published on February 5 2025, the build on Feb 4 works correctly. There are some more details about the test involving an "autoland" build, but I'm not familiar with that branch and not sure what information from it would be useful.
Pushlog link from the Feb 5 Nightly build: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=29c957dc0c6f710ef5e2471560a1f49e7c655db9&tochange=e96db7f2fc84bf31d8081316be884a96496fecb6

In the pushlog, I saw an entry by Peter Van der Beken to address Bug 1944313 (Propagate XSLT expression failure correctly). Could this be the the culprit for the change?

Comment 3

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

Andreas, you reviewed the patches for bug 1944313 so I am starting with you here. Thanks.

Comment 4

[Brandon Gurwitz]

It looks like FF 137 has been released and this bug has been included. Are there any updates to share, or a timeline of when it can be addressed? Thank you.

Comment 5

[Andreas Farre [:farre]]

Maybe Olli has an idea?

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Tracked in bug 1958091

Comment 8

[Andrew McCreight [:mccr8]]

Do we know for sure whether this is a regression from bug 1941002 or bug 1944313? Those are both in the range in comment 2.

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

Farre gave me this regression range on Matrix
https://hg-edge.mozilla.org/integration/autoland/pushloghtml?fromchange=a9bf095300363218d32bb301439f5971acf08328&tochange=a59f102fa3bb55a7a8208f34793b6ca611f566ab

Comment 10

[Andrew McCreight [:mccr8]]

Oh, great. Thanks.

Comment 11

[Peter Kjaer]

This change appears to be what has broken our application too.
We aren't using transformToFragment, but transformToDocument seems to have the same bug too.

Comment 13

[Masatoshi Kimura [:emk]]

137.0.2 release notes say "Fixed functional regressions in our XSLT support introduced in 137." and point to this bug. Can anyone confirm?

Comment 14

[Andrew McCreight [:mccr8]]

Could you please confirm that this issue is fixed in 137.0.2? Thanks.

Comment 15

[Praveen Chauhan]

Yes, this issue has been fixed in 137.0.2

Comment 16

[Brad Clements]

I don't think this bug is fixed, or maybe a new bug has been introduced.

I have a user reporting our internal website works correctly with 137.0.1 but does not work with 137.0.2

We use transformToFragment to add dom elements to existing pages based on xml data received from the server.

Some portions of the xslt continue to work as expected under 137.0.2, while others do not.

The part that does not work uses for-each over elements returned from a document() call, and inside that for-each, it iterates for-each over elements returned from key() call.

one or both of these for-each statements seems to not be iterating over any nodes.

I'll try to find time to narrow this down some..

Comment 17

[Brad Clements]

The xslt document in question contains this:

<xsl:variable name="carriers" select="document(concat($baseurl,'/data/getCarrierServiceList.xml'))" />

Where $baseurl would be something like "https://test.mywebsite.com/Customer

The xslt document is used like this:

	            var owner_document = document.implementation.createDocument("", "fragment", null);
	            var result = self.processor.transformToFragment(xml_object, owner_document);

Where xml_object is the xml document to be transformed to an html fragment

The transform calls a template, to which I've added some debugging

<xsl:template name="display_carrier_and_service_on_quote_from_Service_row">
<xsl:variable name="serviceid" select="@serviceid" />
<xsl:variable name="current_service" select="." />
<xsl:variable name="carrierid" select="../../@carrierid" />

    <b>
    carrierid <xsl:value-of select="$carrierid" /> serviceid <xsl:value-of select="$serviceid" />
    count carriers <xsl:value-of select="count($carriers)" />
    <xsl:for-each select="$carriers" >
        found carrierid <xsl:value-of select="@carrierid" />
        <xsl:for-each select="key('carrierid', $carrierid)">
            matched <xsl:value-of select="@carrierid" />
            <xsl:choose>
                <xsl:when test="not(@iscourier='true') and $carrierid !='BAX'">

In firefox 136.0.4 (linux), this generates the following output:

carrierid USPS serviceid USPSPARSEL count carriers 1 found carrierid matched USPSUSPS Parcel Select

But in firefox 137.0.2 (windows) it generates the following output:

carrierid USPS serviceid USPSPARSEL count carriers 0

In dev tools, network tab, in firefox 136.0.4, I see the call to https://test.mywebsite.com/Customer/data/getCarrierServiceList.xml which downloads an xml document used to map carrier and serviceid to human readable text.

But in firefox 137.0.2, no such network request is made.

Based on this, I'd say that document() doesn't work inside transformToFragment() in 137.0.2, but it does work in 137.0.1

Where there security changes introduced?

Comment 18

[Andrew McCreight [:mccr8]]

Please file a new XSLT bug for this issue and we can discuss it further there. Thanks.

Comment 19

[Brad Clements]

Hi, sure.. it appears this new "bug" was actually an intentional change in https://bugzilla.mozilla.org/show_bug.cgi?id=1953525

Its not clear to me if document() was disabled temporarily while a better security fix is developed, or if this is a permanent change. I'm not authorized to view related issues, so I cannot fully understand the rational for the change.

If this is a permanent change, I suppose there's no point opening a new issue.

If this is temporary change, I happy to open a new issue as you suggested.

Does anyone know off-hand if this change is permanent or not?

Thanks

Comment 20

[Brad Clements]

I have created a new issue https://bugzilla.mozilla.org/show_bug.cgi?id=1961252