Project

Profile

Help

Bug #3442

Problems reusing parameters after ixsl:schedule-action

Added by Debbie Lockett about 1 year ago. Updated 12 months ago.

Status:
Closed
Priority:
Normal
Sprint/Milestone:
-
Start date:
2017-09-13
Due date:
% Done:

100%

Applies to JS Branch:
1.0, Trunk
Fix Committed on JS Branch:
1.0, Trunk
Fixed in JS Release:
SEF Generated with:
Company:
-
Contact person:
-
Additional contact persons:
-

Description

While working on the documentation app, a problem was discovered to do with using ixsl:schedule-action in a template, but not as the final construct. If a parameter (whose value is changed by some page interaction) is used again after it has been used within ixsl:schedule-action, then the value can come out wrong on subsequent interactions. For example, something like the following:

<xsl:message>before $hash-parts {$hash-parts}</xsl:message>
                <ixsl:schedule-action document="{$jpackage-path}">
                    <xsl:call-template name="package-page">
                        <xsl:with-param name="package-path" select="$jpackage-path"/>
                        <xsl:with-param name="hash-parts" select="$hash-parts"/>
                    </xsl:call-template>
                </ixsl:schedule-action>
   <xsl:message>after $hash-parts {$hash-parts}</xsl:message> 

The problem is that within the code for ixsl:schedule-action (in Expr.js), the new context for the called template is constructed using:

c2 = context.newContext(false);

when we should be using

c2 = context.newContext(true);

to ensure that parameters are cleared.

History

#1 Updated by Debbie Lockett about 1 year ago

Added JS unit test ixsl2/schedule01 which demonstrates problem.

#2 Updated by Debbie Lockett about 1 year ago

  • Status changed from New to Resolved
  • Fix Committed on JS Branch 1.0, Trunk added

Fixed as described above. Committed on 1.0 and trunk branches.

#3 Updated by Debbie Lockett 12 months ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in JS Release set to Saxon-JS 1.0.2

Bug fix applied in Saxon-JS 1.0.2 maintenance release.

Please register to edit this issue

Also available in: Atom PDF Tracking page