{"action":"created","issue":{"url":"https://api.github.com/repos/RByers/EventListenerOptions/issues/20","labels_url":"https://api.github.com/repos/RByers/EventListenerOptions/issues/20/labels{/name}","comments_url":"https://api.github.com/repos/RByers/EventListenerOptions/issues/20/comments","events_url":"https://api.github.com/repos/RByers/EventListenerOptions/issues/20/events","html_url":"https://github.com/RByers/EventListenerOptions/issues/20","id":94601740,"number":20,"title":"Handle canceling event handlers that are added \"too late\"","user":{"login":"foolip","id":498917,"avatar_url":"https://avatars.githubusercontent.com/u/498917?v=3","gravatar_id":"","url":"https://api.github.com/users/foolip","html_url":"https://github.com/foolip","followers_url":"https://api.github.com/users/foolip/followers","following_url":"https://api.github.com/users/foolip/following{/other_user}","gists_url":"https://api.github.com/users/foolip/gists{/gist_id}","starred_url":"https://api.github.com/users/foolip/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/foolip/subscriptions","organizations_url":"https://api.github.com/users/foolip/orgs","repos_url":"https://api.github.com/users/foolip/repos","events_url":"https://api.github.com/users/foolip/events{/privacy}","received_events_url":"https://api.github.com/users/foolip/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":23,"created_at":"2015-07-12T21:44:22Z","updated_at":"2015-09-23T16:18:13Z","closed_at":null,"body":"What happens if the UI process/thread thinks that a point only has non-canceling event listeners, but when the event reaches the main thread, a regular event listener that calls `preventDefault()` has been added? It's too late to actually prevent the scroll, but it'll look to the event listener like it can prevent it.\r\n\r\nPerhaps create non-cancelable events when the UI process/thread actually isn't waiting for the result? Though this would make the presence of other no-op event handlers observable, ugh."},"comment":{"url":"https://api.github.com/repos/RByers/EventListenerOptions/issues/comments/142652205","html_url":"https://github.com/RByers/EventListenerOptions/issues/20#issuecomment-142652205","issue_url":"https://api.github.com/repos/RByers/EventListenerOptions/issues/20","id":142652205,"user":{"login":"RByers","id":1280419,"avatar_url":"https://avatars.githubusercontent.com/u/1280419?v=3","gravatar_id":"","url":"https://api.github.com/users/RByers","html_url":"https://github.com/RByers","followers_url":"https://api.github.com/users/RByers/followers","following_url":"https://api.github.com/users/RByers/following{/other_user}","gists_url":"https://api.github.com/users/RByers/gists{/gist_id}","starred_url":"https://api.github.com/users/RByers/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/RByers/subscriptions","organizations_url":"https://api.github.com/users/RByers/orgs","repos_url":"https://api.github.com/users/RByers/repos","events_url":"https://api.github.com/users/RByers/events{/privacy}","received_events_url":"https://api.github.com/users/RByers/received_events","type":"User","site_admin":false},"created_at":"2015-09-23T16:18:13Z","updated_at":"2015-09-23T16:18:13Z","body":"Yep, I agree this sucks but it's been the reality of touch (and wheel) event handling on most browsers since the introduction of threaded scrolling (eg. see my posts [here](https://plus.sandbox.google.com/+RickByers/posts/cmzrtyBYPQc) and [here](https://plus.sandbox.google.com/+RickByers/posts/LXKEENhnQSD)).  Today the impact is limited only to performance and we try to provide performance tools to help developers reason about it.  But their choice today is \"observe and hurt performance or don't observe\".  The thinking here is that we can let developers opt-out of this annoying choice - let them observe without having the side effect of hurting performance.  Isn't getting more developers to opt-into that (with tools/APIs to measure the performance improvement) exactly the way to solve the \"terrible developer experience\" you mention @Hixie?\r\n\r\nIn the long-run, if we can get enough frameworks to opt-in to this behavior, perhaps we can someday consider making it the default and solve this \"observing events hurts performance\" problem once and for all.  But just doing nothing and continuing to pretend in the specs that this issue doesn't exist is not going to help."}}