Feature #5923
closedProvide a way to control event listener parameters
0%
Description
I'm getting this warning in a <xsl:template match="svg:svg" mode="ixsl:onwheel">
template:
Ignoring 'preventDefault()' call on event of type 'wheel' from a listener registered as 'passive'.
I haven't set the passive
parameter, so I suppose SaxonJS has?
Can we have a get a general mechanism for controlling event listener parameters? I'm imagining something like this:
<xsl:template match="svg:svg" mode="ixsl:onwheel" ixsl:event-options="map{ 'capture': true(), 'passive': false() }">
Files
Updated by Norm Tovey-Walsh over 1 year ago
Do you have any kind of example for this? I can't reproduce it. OTOH, I also can't work out how to scroll an SVG. Everything I see on the web says that you should set scroll:overflow on the wrapper. AFAICT, an onwheel event doesn't cause any problems on a DIV.
Updated by Martin Honnen over 1 year ago
https://chromestatus.com/feature/6662647093133312 suggests that with Chrome (and I think also Mozilla) wheel
and similar at the window
or document
or document.body
level are by default treated as passive.
And doesn't SaxonJS register event listeners you declare with mode="ixsl:onXXX"
at the window or document level, meaning any use of ixsl:onwheel
will have a listener created and subjected to the "default" passive setting Chrome imposes?
Updated by Martin Honnen over 1 year ago
https://martin-honnen.github.io/xslt/2023/onwheel/sample1.html is a test case (just with HTML, no SVG used) that has e.g.
<xsl:template match="div[@id = 'div1']" mode="ixsl:onwheel">
<xsl:message select="saxon:timestamp() || ': ' || ixsl:event() => ixsl:get('type')"/>
</xsl:template>
<xsl:template match="div[@id = 'div1']" mode="ixsl:onmouseover">
<xsl:message select="saxon:timestamp() || ': ' || ixsl:event() => ixsl:get('type')"/>
</xsl:template>
<xsl:template match="div[@id ='div2']" mode="ixsl:onwheel">
<xsl:message select="saxon:timestamp() || ': ' || ixsl:event() => ixsl:get('type'), ixsl:event() => ixsl:call('preventDefault', [])"/>
</xsl:template>
for which you can see in the browser console that SaxonJS sets up two document wide event listeners where the mouseover
has passive
as false
but the wheel
get the default passive
as true
and that way the attempt to call preventDefault
causes Chrome to emit
[Intervention] Unable to preventDefault inside passive event listener due to target being treated as passive. See https://www.chromestatus.com/feature/6662647093133312
Updated by Martynas Jusevicius over 1 year ago
My code looks like this:
<xsl:template match="svg:svg" mode="ixsl:onwheel">
<xsl:sequence select="ixsl:call(ixsl:event(), 'preventDefault', [])"/>
...
Updated by Martin Honnen over 1 year ago
Here is a screeshot from the Chrome developer tools that shows that the two event listeners for mouseover
and wheel
are being set up by the same SaxonJS code but result in different passive
settings due to the default that Chrome enforces for wheel
:
Updated by Martynas Jusevicius over 1 year ago
Just to clarify what I was trying to do: prevent window scroll during onwheel
and zoom the SVG in/out instead.
Updated by Norm Tovey-Walsh over 1 year ago
Ah, this is an issue in Chrome, not Firefox.
Updated by Norm Tovey-Walsh over 1 year ago
FWIW, it isn't that we set passive
true, it's:
If not specified, defaults to false – except that in browsers other than Safari, defaults to true for the
wheel
,mousewheel
,touchstart
andtouchmove
events.
Updated by Martynas Jusevicius over 1 year ago
OK, so my question is then: how do I port the following JS code to SaxonJS? From https://codepen.io/osublake/pen/oGoyYb
window.addEventListener("wheel", onWheel);
function onWheel(event) {
event.preventDefault();
...
Updated by Norm Tovey-Walsh over 1 year ago
Sorry. I wasn't suggesting that we don't need to fix this bug. I was just clarifying that it isn't the result of an explicit choice on our part, but rather a case of varying defaults. It's a bug, or at least an obviously missing feature, and we should fix it.
Updated by Martynas Jusevicius over 1 year ago
I'm sorry too, my comment wasn't meant to come accross as harsh :)
Updated by Norm Tovey-Walsh over 1 year ago
- Status changed from New to Resolved
- Applies to JS Branch Trunk added
- Applies to JS Branch deleted (
2) - Fix Committed on JS Branch Trunk added
Only one listener is instantiated for any given event type (e.g., there's only one listener for wheel
events no matter how many xsl:template
elements match in that mode). Consequently, the ixsl:event-options
attribute is placed on the xsl:mode
declaration:
<xsl:mode name="ixsl:onwheel"
ixsl:event-options="map{'passive':false()}"/>
The ixsl:event-options
attribute is an expression. It may not refer to the context. If it refers to variables, they must be static.
Updated by Martynas Jusevicius over 1 year ago
Hmm I'm not sure this helps to address my use case in the light of Martin's comment. I'll try to produce a test case.
Updated by Norm Tovey-Walsh over 1 year ago
I'm not sure what to suggest by way of a workaround for now. This is fixed for SaxonJS 3.0.
Updated by Martynas Jusevicius over 1 year ago
- Company set to Martynas Jusevičius
- Contact person set to Martynas Jusevičius
My understanding is that despite this new feature allowing to set event
option ‘passive: false()’, it will have no effect because document-level
events are “passive by default” and SaxonJS is binding listeners at
document level. Does that make sense?
On Thu, 8 Jun 2023 at 19.00, Saxonica Developer Community <
notifications@plan.io> wrote:
Updated by Norm Tovey-Walsh over 1 year ago
Do you have a citation for the 'passive by default' problem?
I tested the fix by verifying that an onwheel event generated console log errors in Chrome before I used the new feature to set passive to false, and not after I set it to false.
Updated by Martynas Jusevicius over 1 year ago
This is what Martin linked to earlier in the thread: Feature: Treat Document Level Wheel/Mousewheel Event Listeners as Passive
Updated by Martynas Jusevicius over 1 year ago
The wheel/mousewheel event listeners that are registered on document level targets (window.document, window.document.body, or window) will be treated as passive if not specified as otherwise and calling preventDefault() inside such listeners will be ignored.
OK so maybe it would work... I would need to test.
Please register to edit this issue
Also available in: Atom PDF Tracking page