What is a practical use case for manually triggering the scroll event?

Replying to [comment:1 snover]:

What is a practical use case for manually triggering the scroll event?

A generic argument: Different parts of an application bind window scroll listeners depending on the particular page. The trigger is used after user behavior modifies the dom such that it is the equivalent of a scroll. Instead of having to track each of those events or bind them as custom events, the code can just say "do what you would have done if a scroll had occurred," so that the part of the app that knows "we need to do the stuff that would have happened if a scroll had occurred" doesn't need to know what exactly that is.

Specifically, this manifested as a bug in infinite-scroll-style pagination. When a user scrolled to within some margin of the bottom, we fetched some more content. When that content was loaded, we triggered the

$(window).scroll()

again, to check if their screen was tall enough that we needed to fetch even more content. In another place, we called

$(window).scroll()

on window load for similar reasons, and in another app I've explicitly triggered

$(window).resize()

to "do whatever would have been done on window resize" on page load.

Of course there are a myriad of alternatives and workarounds, but it was really surprising to me that when using core functionality like the events system there would be *any* differences between browsers, particularly since $.fn.scroll is documented on http://api.jquery.com/scroll . Part of my confidence in using jQuery is the expectation that behavior will be [mostly] consistent across browsers.

Let me first state that I do sympathise with where you're coming from, and we do appreciate your confidence in and usage of jQuery!

A) WRT to your first point: It is generally considered to be a poor practise to use binding anonymous functions to native events as a method of code organisation. If there is logic that needs to happen "when a scroll would have occurred," whether or not a scroll occurred, it makes much more sense to encapsulate that logic in a function and call that function from an actual window scroll, than it does to encapsulate that logic in a window scroll handler and then try to make the app think the window scrolled.

B) You're right, jQuery does normalise a lot of browser quirks, but because of the very different nature of event handling in different browsers, it is in the events system that these types of issues do pop up. For instance, jQuery synthetically bubbles the change and submit events in IE altogether, and certainly we have encountered issues with that over time. I don't know if you've ever tried doing .trigger("click") to simulate click events, but it is not, in fact ,the same as an actual user clicking the element - certain native behaviours (like following a link) simply do not happen. The reasoning that jQuery is a library that normalizes cross-browser issues, therefore if you find a cross-browser issue, jQuery should automatically find a way to normalise it, in a word, circular.

C) Your fix of adding a preventDefault call is a perfectly reasonable fix - for your application. If you want to stop IE8's default behaviour on a synthetic scroll event, it is typical: people have to use event.preventDefault in myriad contexts and applications for just this type of problem. Whether it is an appropriate solution to be added to every single scroll event jQuery ever binds in any application ever cannot be determined readily.

By the same token, if you are indeed willing to look at this issue further to see if you can find a solution that solves the problem and does not have other ramifications, we would surely welcome your effort and input. So for the time being, after conferring with other members of the ticket triage team, I am going to close this ticket with a "patchwelcome" status. Thanks!