Bug #3499


Keys should be invalidated if the (relevant part of the) HTML page is updated

Added by Debbie Lockett about 6 years ago. Updated over 5 years ago.

Start date:
Due date:
% Done:


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


If a variable refers to part of an HTML page which is subsequently rewritten, the result may be wrong because the 'old' value of the variable is used. For instance, suppose a template variable is defined as

<xsl:variable name="input" select="ixsl:get(ixsl:page()//div[@id='target']/textarea[@id='input'],'value')"/>

and another template has the action of overwriting the relevant textarea

<xsl:template name="overwrite">
        <xsl:result-document href="#target" method="ixsl:replace-content">
            <textarea data-ref="input"></textarea>

Then we do not see the correct new value for $input after the 'overwrite' has been called.

Internally, a key is used for the reference to the textarea node. The issue is that when the textarea is overwritten, the key should be invalidated, so that it is reevaluated properly.

Actions #1

Updated by Debbie Lockett about 6 years ago

The second sample above should be

<xsl:template name="overwrite">
        <xsl:result-document href="#target" method="ixsl:replace-content">
            <textarea id="input"></textarea>
Actions #2

Updated by Debbie Lockett about 6 years ago

JS unit test ixsl/get02 added to replicate the problem.

Actions #3

Updated by Debbie Lockett about 6 years ago

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

The fix is to clear all keys every time xsl:result-document is used to insert into the HTML page. (We only really need to invalidate "relevant" keys, but knowing which these are may be complicated; so it is simpler to always invalidate all keys.) This is done using

window.document._saxonIndexes = {};

within Expr.resultDoc.

Fix committed on 1.0 and trunk (2.0) branches.

Actions #4

Updated by Debbie Lockett over 5 years ago

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

Bug fix applied in the Saxon-JS 1.1.0 maintenance release.

Please register to edit this issue

Also available in: Atom PDF Tracking page