Bug #1590


Event processing, preventDefault

Added by Manfred Staudinger over 11 years ago. Updated about 11 years ago.

Start date:
Due date:
% Done:


Estimated time:


I have an anchor like this

<a id="Index_Q" href="Index_de_Q.html" onclick="toggleInto(event, 'Index_Q_div')">Q</a>
<xsl:template match="html:a" mode="ixsl:onclick">
	<xsl:message select="'onclick', name(.), @id"/>
	<xsl:message select="'cancelable', ixsl:get(ixsl:event(), 'cancelable')"/>
	<xsl:variable name="t" select="ixsl:call(ixsl:event(), 'preventDefault')" as="item()*"/>
	<xsl:message select="'preventDefault', $t"/>

INFO: onclick a Index_Q

INFO: cancelable true

INFO: preventDefault

While the first and second message produce what I expected, the ixsl:call does not: $t is empty and toggleInto still gets invoked.

Did I miss something trivial?

Actions #1

Updated by Michael Kay over 11 years ago

I'm not familiar enough with the event handling to know whether this should have the required effect, but it doesn't surprise me that $t is empty: surely preventDefault() is defined to return no result?

What happens if you call event.stopPropagation()?

Generally, I would advise against using xsl:variable to call methods for their side effects, because variables are not always evaluated when you expect it. Using xsl:value-of is safer. If you use xsl:value-of then Saxon carefully avoids doing any inferencing based on the the knowledge that the function result is void, so it calls the function and outputs an empty text node, which has no effect. But I don't think that explains the problem here - so long as the xsl:message references $t, you should be OK. If you took the xsl:message away however, $t would not be evaluated because there is no need.

Actions #2

Updated by Philip Fearon over 11 years ago

  • Status changed from New to In Progress
  • Assignee set to Philip Fearon
  • Priority changed from Low to Normal
  • Found in version set to 1.0

To test prevention of default behaviour I used the following template:

<xsl:template match="a" mode="ixsl:onclick">
   <xsl:result-document href="#main" method="append-content">
   <p>clicked item</p>
<xsl:sequence select="ixsl:call(ixsl:event(),'preventDefault')"/>

This was used with the anchor element:

<a href="">Default</a>

The expected behaviour is for the xsl:template to modify the output - in this case append a paragraph to the #main div element - but to prevent the default behaviour where the browser would navigate to the URI within the href attribute. This worked successfully for the Chrome, Firefox, Safari and IE9 browsers - so I suspect that the issue you're experiencing is associated with the use of xsl:variable to cause this side-effect (it is not advisable to rely on xsl:message executing because this may be removed from code accidentally and also this code may not execute under certain circumstances - eg. if logging is disabled).

One issue that does arise from this test however is that the 'preventDefault' method is not supported by Internet Explorer 8 and previous versions. To get the same effect in JavaScript one would have to return false from the event handler. In XSLT we currently can't emulate this, so current thinking is a new 'ixsl:prevent-default' attribute for xsl:template - for example:

<xsl:template match="a" mode="ixsl:onclick" ixsl:prevent-default="yes">
   <xsl:result-document href="#main" method="append-content">
      <p>clicked item</p>
Actions #3

Updated by Philip Fearon over 11 years ago

The ixsl:prevent-default attribute has been implemented ready for the next Saxon-CE release. Internally, this exploits GWT's cross-browser event handling and has been tested to work in Internet Explorer 7 and later (and should also work in IE6), along with Chrome, Safari, Firefox and Opera.

If the ixsl:prevent-default attribute is not present or has a value of 'no' then the default behaviour for the event will proceed as normal. If the ixsl:prevent-default attribute has a value of 'yes' the default behaviour for the event is inhibited.

Actions #4

Updated by Philip Fearon over 11 years ago

  • Status changed from In Progress to Resolved
Actions #5

Updated by O'Neil Delpratt about 11 years ago

  • Status changed from Resolved to Closed
  • Sprint/Milestone set to Release 1.1
  • % Done changed from 0 to 100
  • Fixed in version set to 1.1

Bug fixed for Saxon-CE version 1.1 release

Please register to edit this issue

Also available in: Atom PDF