Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upAdd support for passive event listeners #2871
Comments
This comment has been minimized.
This comment has been minimized.
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 |
This comment has been minimized.
This comment has been minimized.
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;
}
}); |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
Thanks for opening this. I'd like to see the numbers on the performance benefits before implementing, tho. |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
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 |
This comment has been minimized.
This comment has been minimized.
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.
|
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
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 |
This comment has been minimized.
This comment has been minimized.
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 |
This comment has been minimized.
This comment has been minimized.
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 |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
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? |
This comment has been minimized.
This comment has been minimized.
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 |
This comment has been minimized.
This comment has been minimized.
If they were done in that order, the second handler would also ignore preventDefault since the two handlers would both be multiplexed off the |
This comment has been minimized.
This comment has been minimized.
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 |
This comment has been minimized.
This comment has been minimized.
I feel like my position has been misconstrued. |
This comment has been minimized.
This comment has been minimized.
@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 comment has been minimized.
This comment has been minimized.
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 was marked as outdated.
This comment was marked as outdated.
Why not just introduce a new syntax to the events? |
This comment was marked as off-topic.
This comment was marked as off-topic.
Fixed it for when SEO runs on google light house, but reverted due to concerns about wider effects. |
This comment was marked as off-topic.
This comment was marked as off-topic.
What is the status on this? |
This comment has been minimized.
This comment has been minimized.
Still planned for 4.0, a PR to refactor the event system is not ready yet.
--
Michał Gołębiowski-Owczarek
|
This comment was marked as off-topic.
This comment was marked as off-topic.
Who is this issue? Will passive be added? |
This comment was marked as off-topic.
This comment was marked as off-topic.
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 |
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 was marked as off-topic.
This comment was marked as off-topic.
Sorry for being stupid. |
This comment was marked as off-topic.
This comment was marked as off-topic.
First of all, i can clearly understand where you are coming from and totally appreciate the work being poured into maintaining this library. But, jQuery is meant to ease developer's life and many enterprises are still using this library and what we expect is consistency across browsers. |
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 was marked as off-topic.
This comment was marked as off-topic.
Breaking changes or not - this is a must-have feature for jQuery to continue to exist. If Google are warning website owners that non-passive listeners are bad (especially on scroll listeners) then it's only a matter of time until website owners start questioning their developers. What are the developers are going to say? "We can't help it - it's how jQuery works and their team are claiming it's too much work to fix it" ? As both a business person and a developer I can tell you, with some certainty, that most business owners are likely to tell their developers to find an alternative... and with the likes of VueJS, and with native JavaScript getting better all the time there are plenty of alternatives around once developers are pressured into dropping jQuery. Once businesses stop buying themes and sites that rely on jQuery, those developers will stop using jQuery too. By not providing a solution to this jQuery is in danger of becoming obsolete. |
This comment was marked as off-topic.
This comment was marked as off-topic.
@hades200082 you took the words of my mouth! Sinceraly, I am ditching jquery on many projects, not only because of this scroll thing (that is veery important) but because of its lack to use much better and more efficient native browse selectors of the most modern browsers. jquery was once a great library, nowadays it's just getting annoying with so many limitations. |
This comment was marked as off-topic.
This comment was marked as off-topic.
No one is saying that. It’s just that this requires big, potentially breaking changes so it can only happen in a major update. And it is planned for jQuery 4.0. I’m not sure what you’re trying to achieve with this comment.
I’m not sure what you’re claiming but jQuery uses native querySelectorAll when it works. |
This comment was marked as off-topic.
This comment was marked as off-topic.
@mgol Just google a little bit and you will see how jquery performance is much slower when compared to native browser performance for many types of selectors. |
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 was marked as off-topic.
This comment was marked as off-topic.
When is 4.0.0 due for release? The reason you're getting so many visits and comments are because Google is now using Lighthouse as one of their main checks for a site's performance. Since Lighthouse is built into all WebKit browsers, developers are able to run it for themselves and one of the top things that have an effect the performance score in Lighthouse (and therefore a sites Google ranking) is not using passive listeners ... especially for scroll listeners. Additionally, non-passive scroll listeners are horrible and cause janky scrolling on many sites that use them. Now... when you combine this with the fact that many CMS (including Wordpress, Kentico and others) use jQuery by default.... as do many Wordpress themes... then you end up in a situation where a lot of websites are starting to drop in Google rankings due to poor performance. Naturally, those websites' owners are poking their developers asking "why?" and the developers are doing their research and identifying the points from the Lighthouse reports as being contributing factors. Digging a little deeper they discover that jQuery event listeners are not using passive and start searching around for a solution, invariably leading them here. |
This comment was marked as off-topic.
This comment was marked as off-topic.
As I said, it's unlikely that a 4.0 release is a panacea for web site developers. Even after its release they will need to change additional code, very often it will be code that is part of their theme, or a third-party plugin that they do not understand. It will be hard. Most people will not do it. Most sites are still using jQuery 1.x which will never get a fix for this. However, the code snippet above might even work on jQuery 1.12--I haven't tried it. If you are one of the people complaining, use the solution I showed above and see if it makes Lighthouse happy. |
This comment was marked as off-topic.
This comment was marked as off-topic.
With the addition of passive listeners there's going to be a requirement for developers to make changes even if sites are run on native JS. The problem with jQuery at present is that there is no way to make those changes where there is a mix of listeners. Surely it would make sense to add an optional parameter to the relevant APIs to take a simple boolean value to indicate that we need a passive listener? this way developers could update their code without having to drop jQuery. |
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. |
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.