Bug #6037
closedixsl:schedule-action return objects
100%
Description
In SaxonJS 2, ixsl:schedule-action
with the document
attribute is available on Node.js. However the documentation says that the instruction "returns immediately with an object containing any associated JavaScript XMLHttpRequest (XHR) objects, or an empty sequence otherwise." It is not clear in the documentation that while this is true in the browser, there are no such XHR objects on Node.js, and the instruction always returns an empty sequence. The point of returning the XHR objects is: "This enables HTTP requests from ixsl:schedule-action instructions to be aborted by user interaction, by making the underlying XHR objects accessible." So this mechanism is actually not currently available in Node.js.
It would be useful to clarify this behaviour in the SaxonJS 2 documentation.
Updated by Debbie Lockett over 1 year ago
- Assignee set to Debbie Lockett
Furthermore, on the SaxonJS 3 development branch, the implementation of ixsl:schedule-action
has been updated to use the Fetch API for HTTP requests and document fetching, both in the browser and on Node.js. Rather than returning XHR objects, we return AbortControllers, on Node.js as well as in the browser (enabling use of the aborting mechanism). So while ixsl:schedule-action/@document
returns an empty sequence with SaxonJS 2 on Node.js; it returns an object in SaxonJS 3. We give advice to throw away the result of an ixsl:schedule-action
instruction to prevent it being written to the current result tree (https://www.saxonica.com/saxon-js/documentation2/index.html#!ixsl-extension/instructions/schedule-action); but it is easy to make this mistake (see the current failure of nodejs unit test schedule-009
), and potentially even more so with this change between SaxonJS 2 and 3.
Perhaps we can amend the implementation so that the instruction only returns objects when we are not writing to the current result tree (i.e. when context.tempOutputState !== false
); so it always just returns an empty sequence when writing to the current result tree.
Updated by Debbie Lockett over 1 year ago
Maybe it's not actually surprising that the mechanism for aborting HTTP requests is not actually available in Node.js: what would that actually look like? The mechanism works in the browser with user interaction; but we don't actually have that in Node.js, do we?
Updated by Debbie Lockett about 1 year ago
- Status changed from New to Resolved
- Fix Committed on JS Branch 2, Trunk added
Documentation updates committed on the saxonjs2
branch to clarify the status when using ixsl:schedule-action
in Node.js with SaxonJS 2.
Updates committed on the main
branch to explain the changes to ixsl:schedule-action
in SaxonJS 3.
Updated by Debbie Lockett about 1 year ago
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in JS Release set to SaxonJS 2.6
Bug fix applied in the SaxonJS 2.6 maintenance release.
Please register to edit this issue
Also available in: Atom PDF Tracking page