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

[Nadya678]

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]

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]

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]

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

[FRSgit]

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]

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).

[crenshaw-dev]

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?

[johannhof]

(As noted in #72, we intend to archive this repository and are thus triaging and resolving all open issues)

I'm not 100% sure if there's a distinction between this issue and whatwg/dom#587 so I'll assume we can continue to track it there.

[FRSgit]

@johannhof Yes, it's more or less the same.

BTW. do you know how this process could be sped up? Should I try to file the PR according to the guidelines even though there was no discussion in the referenced issue thread?

[johannhof]

Hi @FRSgit, thanks for confirming. I think the main thing that's needed on the issue is implementer interest. I'll try to mention this to the relevant team on Chromium but overall this is a difficult barrier for most proposals, as there are obviously many things to prioritize.