Project

Profile

Help

Bug #6037

closed

ixsl:schedule-action return objects

Added by Debbie Lockett over 1 year ago. Updated about 1 year ago.

Status:
Closed
Priority:
Normal
Category:
IXSL extensions
Sprint/Milestone:
-
Start date:
2023-05-12
Due date:
% Done:

100%

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

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.

Actions #1

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.

Actions #7

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?

Actions #13

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.

Actions #14

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