In bug 1172171, I added a very simple mechanism to fire a chrome-only "scrollend" event when scrolling ends on an nsGfxScrollFrame. That mechanism worked by waiting until nsGfxScrollFrame had computed that scrolling had completed, and just firing the event at that point. The problem is that "scroll" events are fired by appending them to a queue that the refresh driver flushes periodically off of frame ticks. This means we could get into cases where we'd fire a scrollend event, and then the refresh driver would flush more scroll events after the fact. We should probably append scrollend events to the refresh driver queue instead of firing them immediately.

Comment on attachment 8932567 [details] Bug 1421351 - Queue chrome-only scrollend event in refresh driver scroll event queue instead of firing immediately. https://reviewboard.mozilla.org/r/203624/#review209070 Looks reasonable to me. Were you able to confirm that this solves the problem you were seeing?

Comment on attachment 8932567 [details] Bug 1421351 - Queue chrome-only scrollend event in refresh driver scroll event queue instead of firing immediately. https://reviewboard.mozilla.org/r/203624/#review209070 Yep, I was able to confirm with a bunch of logging. I tested both the mousewheel and trackpad case.

Comment on attachment 8932567 [details] Bug 1421351 - Queue chrome-only scrollend event in refresh driver scroll event queue instead of firing immediately. https://reviewboard.mozilla.org/r/203624/#review209070 Thanks for the fast review!

Pushed by mconley@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/b7d7bb45c063 Queue chrome-only scrollend event in refresh driver scroll event queue instead of firing immediately. r=kats