e.preventDefault on custom events does not carry into base event

[ldoubleuz]

When I have a listener function for a custom event such as "tapstart", e.preventDefault does not work as intended, and users must explicitly call e.baseEvent.preventDefault.

This could easily be a point of confusion, and also breaks backwards compatibility with older code.

[csuwildcat]

Can you give me an idea of what the expected behavior should be? I'm not sure what you mean, as there is no true default for the custom events, as they are just expressions of when other events and conditions occur. Let's talk more, and example would be helpful to see what you have in mind.

[ldoubleuz]

Basically, something similar to jQuery's approach, such that e.preventDefault is interpreted as meaning "I want to preventDefault the event that got auto-wrapped into a custom event under the hood".

[csuwildcat]

If we want to offer the behavior you describe (relaying the preventDefault down), I feel we should introduce a separate, or combined method to enable it.

[ldoubleuz]

But in what use case would someone want to preventDefault a custom event without preventDefaulting the base event? The point of this issue is to simplify the API usage and make the event manipulation as close to native as possible (which is what jQuery does), and introducing a separate method defeats the purpose.

[csuwildcat]

The new longtap event is a good example - while a user may want to prevent the longtap progression, they may not want to stop the underlying touchend.
A good example of the opposite is swipe. On Chrome for Android, unless you prevent just the underlying touchstart event (and that alone), every attempt at swiping will initiate the browser's tab switching behavior.

Another thing to consider: if you block the underlying observed delegate, you could be affecting the operation of other events as well.

There are many reasons you just want to prevent one or the other, I believe we should add methods for both.

[csuwildcat]

I'll try to take a look at providing a solution for this next week

[pennyfx]

@csuwildcat What's the status of this ?

[csuwildcat]

It can be done, but needs to be coded into core. If implemented, it should
be a separate method, like preventAllDefaults
On Mar 12, 2014 12:38 PM, "Arron Schaar" [email protected] wrote:

@csuwildcat https://github.com/csuwildcat What's the status of this ?

Reply to this email directly or view it on GitHubhttps://github.com//issues/23#issuecomment-37454150
.

[csuwildcat]

I can get this in sometime this week.

[xooxdoo]

Week ?

[csuwildcat]

Haven't seen this for a long time, sorry about that. I can do this if it's
still something folks want - do you?
On Feb 25, 2016 9:22 PM, "Youness Belfkih" [email protected] wrote:

Week ?

—
Reply to this email directly or view it on GitHub
#23 (comment).

[xooxdoo]

it can be handy in some situations

[xooxdoo]

people don't use preventDefault() all the time but having wont it effect your event system because calling it is optional e.g. submit on form, click on submit, drop on an element ...

what we want is a shorter version of event.baseEvent.preventDefault as event.preventDefault like ...

event.preventDefault = event.baseEvent.preventDefault.bind( event.baseEvent )

[xooxdoo]

opened a pull request didn't test it tho

[csuwildcat]

The issue that comes to mind with the pull request's code is that events can inherit from other events., so the preventDefault call would need to cascade down to the next in the chain. For example: if you called prevent default on a custom composite event called longtap that inherited from tap that inherited from click, the current PR would (seemingly) not reach the click.

As I see it we have two options:

1. Overwrite preventDefault with a function that calls it on each level, all the way to the root event

2. Create a new preventDefault function, called preventAllDefaults that did the walk of the custom event chain down to the root event