-
Notifications
You must be signed in to change notification settings - Fork 20.6k
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
Add support for passive event listeners #2871
Comments
What kind of support are you looking for? I think it would be really hard to expose either We could create a new API which is what #1735 is about, but there are several hard issues to solve if we want that to be the foundation for Also, what is a reliable way to check for |
I don't presume to know enough about event handling in jQuery and the typical usage patterns to have a valuable opinion on what the right design is. But at a high-level, the thing you want for maximizing scroll performance is some way for the code attaching the listener to disable the use of This could even be just more syntax for the event name list. Eg. some knob that lets developers opt-in to passive-by-default for Or maybe developers just have to resort to
The explainer shows the typical (if obscure) pattern of feature-detecting dictionary members: var supportsCaptureOption = false;
document.createElement("div").addEventListener("test", function() {}, {
get capture() {
supportsCaptureOption = true;
return false;
}
}); |
I realize the API is tricky because of the As far as an actual, usable API, my ideal solution would be to drop But again, let's start by limiting the discussion right now to whether this feature should make it into jQuery. |
You can get pretty close to that today with special events: http://jsbin.com/bupesajoza/edit?html,js,output The caveat is that all events attached to a specific element will behave like the first event, whether you provide the class or not. So it works fine for elements where there is only one touchstart handler per element. |
The extra arg to the public API is messy but it's the least of the problems. I didn't even mention it because solving the architectural issues and legacy expectations would be much harder. If you shoehorn capture and passive into the existing API you have to define how it interacts with all the existing plumbing, worrying about how much it will break. If you create a new API you start with an empty slate and can say, for example if you want, that these events are never cloned or internally tracked during manipulation and also not subject to the special events system or jQuery's special triggering logic. |
Interesting, thanks. Anyway I'll leave it to you jQuery experts to figure out what, if anything, you want to do here. Let me know if there's any questions about or feedback on the API / browser behavior. When we ship passive support in Chrome (currently targeting the upcoming m50 release), you can expect to see a bunch of evangelism with hard data about the performance benefits seen in practice. I can believe it's premature to worry about it much until then, given that early adopters have some OK options for working around jQuery here. |
Thanks for opening this. I'd like to see the numbers on the performance benefits before implementing, tho. |
Plumbing-wise, this seems very feasible (just extra data to pass to Porcelain-wise, five arguments is ugly but @scottgonzalez's suggestion works for extending the Still, I think it can work. +1 from me. |
It's a lot more plumbing than that if we support capture. So let's not consider capture in this proposal at all.
The way I understood @RByers document, if you attach with
This is probably a relatively rare need, correct? Whatever the API to convey the new data, it doesn't necessarily have to support all signatures or options. It could be a |
You might want to consider polyfilling the visible effect of "passive" on
browsers that don't support it. This will reduce the chance of code
working fine in old browsers but failing in newer ones. See
https://github.com/RByers/EventListenerOptions/blob/gh-pages/EventListenerOptions.polyfill.js
for an example.
But that probably isn't critical.
|
Yes. To make it absolutely explicit, this ticket is purely limited to
I'm pretty sure we also need to skip our own
Yes. That it doesn't work would only be visible when people call
Please let's not do that. It would be clumsy for both us and our users, and the introduction of an inheritance-based pattern that is decidedly un-jQuery. |
Rick released a comparison video showing the potential of passive event listeners on CNN.com and it's pretty compelling: https://www.youtube.com/watch?v=NPM6172J22g I'm doing some deep dives of CNN and similar websites (e.g. bloomberg) to identify candidates for Passive Event Listeners but early take suggests that having Passive event listeners supported in jQuery would really help a lot. |
Is this fast-tracked on several major browsers? We can add plumbing here but it seems like it would be of limited use unless enough browsers support it. Some links to browser tickets tracking implementation would be helpful. |
Tracking bug for Safari is here. They've told me they're interested and they've contributed to the design, but who knows if/when they'll make implementing it a priority. Gecko tracking bug is here. Again priority isn't clear. We're hearing a bunch of demand from web developers though (mostly in response to my video tweet). So there's a bit of a chicken and egg problem here. I think the other engines are waiting to see the extent to which developers adopt this, and many of the developers we talk to don't have an easy way to use it because jQuery doesn't expose it yet. But some of the developers we're talking to aren't using jQuery and can get the benefit right away (and we've got the metrics to let us report what perf improvements such sites are having in aggregate), so that'll probably fuel interest. |
Just to be clear, the plugin that I mentioned above already lets you take advantage of passive event listeners, as long as you always want all the events of a particular type on a particular element to either be passive or non-passive. If you aren't ever attaching cancellable What more do you need at the moment to be able to use passive event listeners with jQuery? The lack of an |
The DOM spec is making increasing use of event listener options (passive late last year, invoke-once last month, and delegation likely soon). I think we should get on board with the trend by adding a final |
That's the messy part and a major change, which is why I'm looking for a way to satisfy this sooner than jQuery 4.0 (or later). We'll need at least a separate |
Thanks Dave, I agree this looks like it should be enough to ensure people aren't blocked. I'm reading up on JQuery's event customization support to better understand it, but in the interim can you clarify what would happen if some code did both I'm thinking this pattern is probably even better supported in a framework agnostic way (perhaps there's no need for a jQuery-specific plugin). Eg. in WICG/EventListenerOptions#39 I propose creating a generic library which just fires events named Actually, given jQuery's push on pointer events maybe
I think we really need to hear from some end developers using jQuery who are trying to get the perf benefit of passive touch listeners in their code. /cc @tylerbrandt from Optimizely and @CRHain88 who works on CNN. |
We're using a third-party library for an image carousel, which is using jQuery to manage How would Is that enough information re: our use case? |
You can have multiple namespaces on an event, if that is what you're asking. So the third-party library would just need to include the plugin above and add |
If they were done in that order, the second handler would also ignore preventDefault since the two handlers would both be multiplexed off the |
Any flag that globally changes behavior generally becomes a nightmare for plugin developers because they can't tell what behavior to expect. @arschmitz Does jQuery Mobile have calls to |
I feel like my position has been misconstrued. |
@scottgonzalez jQuery Mobile does not call I would really like to see support added for event listener options / passive events in general though jQuery Mobile has always battled issues with scrolling performance on android devices and this would directly help some of our cases. I have no problem writing and maintaining a plugin if need be as @dmethvin suggested for use in mobile if need be but would really prefer to just see it in core. |
This can all be done but it involves a major rewrite of the event system with breaking changes because of the way it affect internals. I don't see that happening until at least jQuery 4 and who knows when that will occur. I am looking for ways to satisfy the need to access passive event listeners via jQuery sooner than a year or more from now.
That should definitely not happen in a correct full implementation of all the native options. I like your suggestion above that turns
Right, there already is a global behavior of doing what |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
The status of this is still open in many other frameworks with some frameworks marking the issue as “will not fix”.
I am sure you can appreciate from the thread this is no trivial task.
When most contributors work full-time in paying jobs to support themselves and families, finding the free time to pour all your unpaid time and energy into can be hard to find.
Please use the thread to contribute not make demands. Thanks
…Sent from my iPhone
On 6 Feb 2019, at 06:22, batata004 ***@***.***> wrote:
Is this implemented? Lots of other frameworks are using it, why taking so many years to jquery implement it? If it is still not implemented, is there some "hack" I can use with the .on() to allow for passive?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.
http://www.mailguard.com.au
Report this message as spam
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
I am going to ask people to refrain from posting in this ticket until they have read the discussion above and understand that this feature cannot be implemented without serious breaking changes. |
… to addEventListener provoking many issues on event handling (i.e., e.preventDefalt() stopped to work). In this library, it resulted on weird scroll behavior on mobile, offcanvas appearing / disappearing, console warnings and wroing handling of offcanvas status (open/close). See this comment for a good overview of the problem: https://stackoverflow.com/a/39187679 For the time being, jQuery hasn't shipped a solution yet, so .on() is still unable to pass the parameters to the native addEventListener. See this issue to track the status of jQuery: jquery/jquery#2871 The only solution is to override touchmove event before loading jquery: See https://stackoverflow.com/questions/39152877/consider-marking-event-handler-as-passive-to-make-the-page-more-responsive and https://stackoverflow.com/questions/46094912/added-non-passive-event-listener-to-a-scroll-blocking-touchstart-event The code has been inserted on bootstrap.offcanvas.coffee and needs to be loaded after jQuery and before the library.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
We have this on the roadmap for 4.0 and abusive comments don't help. Just a few comments up I asked people to refrain from non-productive comments but it hasn't helped. If it continues we can just lock the ticket I guess. Given the comments, I think this ticket has turned into a Google Search destination for people wondering why some If your site is actually having performance issues that require passive listeners to fix, I already posted a simple fix above that will do that without the need for other breaking changes that will come with the 4.0 release. That plugin could be simplified to force all jQuery.event.special.touchstart = {
setup: function( _, ns, handle ){
this.addEventListener("touchstart", handle, { passive: true });
}
}; With this in place, if you try to call For more complicated cases where you need a mix of passive and non-passive listeners, 4.0 will be the ticket. Note that existing jQuery plugins that will inevitably break, and you will need to update them. If you are maintaining a web site and haven't written all the code yourself, be prepared for that. It may involve contacting the creators of jQuery plugins for any tooltip, carousel, lightbox, and maybe even browser add-in tools.
The problem isn't that mixing passive and non-passive listeners is too much work to fix in jQuery, although it is a major change. The problem is that it may end up being too much work to fix on your web site. There are no |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
We understand this is an important feature. The feature is coming and it's planned for 4.0. Most of the comments here aren't relevant to the development of the feature, so I'm locking the ticket. The workaround Dave posted will allow users to take advantage of the passive option until 4.0 is released. We can't say for sure when 4.0 will be ready. We are all volunteers that work on jQuery when we can make the time, but we'll go as fast as we can. |
Previously we would consider a user "present" and "last seen" if the browser window was visible. This has many edge cases, you could be considered present and around for days just by having a window open and no screensaver on. Instead we now also check that you either clicked, transitioned around app or scrolled the page in the last minute in combination with window visibility This will lead to more reliable notifications via email and reduce load of message bus for cases where a user walks away from the terminal
I added the |
Blink has shipped support for EventListenerOptions and we expect to soon ship support for the passive option.
Ideally jquery users would be able to mark event listeners as passive, so they can get the same performance benefits. Also @scottgonzalez mentions it would be good for jquery to polyfill the capturing API as well.
Thoughts? Feel free to file any issues / questions with the spec here.
The text was updated successfully, but these errors were encountered: