Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chrome, doesn't accept preventDefault and still cancelable is true #63

Open
Nadya678 opened this Issue Feb 27, 2018 · 6 comments

Comments

Projects
None yet
4 participants
@Nadya678
Copy link

Nadya678 commented Feb 27, 2018

Chrome cannot preventDefault on the #document, <body/> and <html/> objects. The cancelable is still true. The warnings and access violation should be reported IMO only if cancelable is false.

TouchEvent 
{
altKey:false
bubbles:true
cancelBubble:false
cancelable:true
changedTouches:TouchList {0: Touch, length: 1}
composed:true
ctrlKey:false
(...)
}

[Intervention] Unable to preventDefault inside passive event listener due to target being treated as passive. See https://www.chromestatus.com/features/5093566007214080

IMO if any browser "improve scrolling" and other make extensions, the event should have set cancelable to false due to specification.

After setting touch-action:none the warning is not emitted but still the event is not cancelled by use of preventDefault and stopPropagation.

@dtapuska

This comment has been minimized.

Copy link

dtapuska commented Feb 27, 2018

cancelable is set to false under certain conditions. Try this; goto chrome://version and in devtools console type monitorEvents(window, "touchmove") you will see the cancelable is false.

There are situations where cancelable is not set to false (as long as one of listeners of the event isn't passive) then the event ends up being not cancelable yet you can't prevent default it inside a event listener.

@FRSgit

This comment has been minimized.

Copy link

FRSgit commented Mar 9, 2018

Well, imo situation like this is at least unfortunate - there is no option to distinguish whether listener is passive or no (ergo if preventDefault can/cannot be used) from inside of the event's handler.

Also that clearly means cancelable property does not reflect current event's state - sure, from point of view of non-passive listener event is cancelable, but when looking from the perspective of passive event it is not.

The same problem occurs for every passive event's listener.

Summing up - my proposal would be to change a bit conditions under which cancelable is set to false or to add to the event object a new property (e.g. 'preventable') which will always go along with real possiblity to stop the event.

@dtapuska

This comment has been minimized.

Copy link

dtapuska commented Mar 9, 2018

You can determine if it is passive or not by calling preventDefault and examining the defaultPrevented attribute. Is that sufficient for you?

@FRSgit

This comment has been minimized.

Copy link

FRSgit commented Mar 9, 2018

Calling preventDefault raises warnings/errors (depends on browser - not sure what exact behaviour should be here according to the spec), so it's not a way. I would rather not have console full of garbage. Also, isn't that weird to fire some action to check whether is it possible or not?
Other way around would be to have a possibility to check if currently fired listener is passive or not.

@FRSgit

This comment has been minimized.

Copy link

FRSgit commented Apr 10, 2018

There is of course other possibility - not to raise console.error when code tries to preventDefault inside passive event listener - just print some verbose message/warning in the console.

I'm so strict about it because when you write output of the error message which is currently raised in chrome, so:
Unable to preventDefault inside passive event listener invocation.
you'll see that lots of people in community are confused by this error-looking output.

Let's make it either an error (so it can be catched and silenced if needed) or verbose notification (which is not even visible in console by default).

@mac9416

This comment has been minimized.

Copy link

mac9416 commented Dec 24, 2018

Ditto. I just submitted a PR to tiny-slider that I thought should clear up the preventDefault warnings. But it doesn't.

I also don't see a warning that a non-passive 'touchmove' event listener has been attached... so although I trust @dtapuska that there's another event listener keeping this one from being passive, it's going to be a pain to find it.

Maybe that's a Chrome bug, that it doesn't warn for touchmove events?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.