Prevention of default events / event propagation not working
See original GitHub issuePrevention of default events or hindering event propagation doesn’t seem to be functional in cytoscape.js. I am trying to override the default event which happens upon clicking a node (the node is selected) with instead selecting the node’s neighborhood. None of the methods for hindering event propagation seem to work:
cy.off("click");
cy.on("click", "node", null, function(e) {
e.stopPropagation();
e.stopImmediatePropagation();
e.preventDefault();
e.originalEvent.stopPropagation();
e.originalEvent.stopImmediatePropagation();
e.originalEvent.preventDefault();
e.cyTarget.neighbourhood("node").select();
}
The result is that only the clicked node is selected. Using a setTimeout hack seems to confirm that the default event overrides the desired effect, i.e. replacing the last line of the event callback with
window.setTimeout(function() {
e.cyTarget.neighbourhood("node").select();
}, 50);
works.
Issue Analytics
- State:
- Created 8 years ago
- Comments:7 (3 by maintainers)
Top Results From Across the Web
Stop propagation doesn't work - Stack Overflow
Nor stopPropagation (), because it stops propagation of event to higher levels of DOM, while other eventListeners on the same level (button in ......
Read more >How to correctly use preventDefault(), stopPropagation(), or ...
Prevents the browsers default behaviour (such as opening a link), but does not stop the event from bubbling up the DOM.
Read more >Event.stopPropagation() - Web APIs | MDN
The stopPropagation() method of the Event interface prevents further propagation of the current event in the capturing and bubbling phases.
Read more >Why isn't event.stopPropagation() working?!
Instead you can use event.nativeEvent.stopImmediatePropagation() to stop event propagation and prevent events being bubbled to parent component.
Read more >How to Stop Propagation of an Event in JS - JavaScript Tutorial
Note that the event.stopPropagation() method doesn't stop any default behaviors of the element e.g., link click, checkbox checked. If you want to stop...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
For the effect you’re describing, I would argue that it’s the opposite: You want custom selection behaviour, so you don’t want selection state to be mutable by default. Otherwise, any number of user events would generate selection.
It’s far terser and more future-proof to selectify elements in the short window they need to be rather than hunt down every event (and at the right stage of the event) that could cause selection (both now and in future versions that may add things).
This is far clearer, and it always works.
OK. My idea is along the lines that a separate
boxselect
(or such) event would be fired for all nodes in the box, allowing the library user to implement any selection behavior. I.e. the box selection event would be similar to any other user input (click, tap, etc.).