This is a regression from http://trac.webkit.org/changeset/172832/trunk/Source/WebCore/dom/Element.cpp We should not be sending wheel events to the DOM with a delta of 0. This affects webmail.apple.com rdar://problem/18903118
Created attachment 246478 [details] Patch
Comment on attachment 246478 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=246478&action=review > Source/WebCore/dom/Element.cpp:282 > + if (!(event.deltaX() || event.deltaY())) This would be clearer as if (!deltaX && !deltaY()) I think.
http://trac.webkit.org/changeset/180018
Re-baselined tests in: http://trac.webkit.org/changeset/180021
This change breaks snap scroll points, but you couldn't have known that since I have not gotten around to making suitable tests!
(In reply to comment #5) > This change breaks snap scroll points, but you couldn't have known that > since I have not gotten around to making suitable tests! I wonder why snap scroll points rely on getting a delta of 0?
(In reply to comment #6) > (In reply to comment #5) > > This change breaks snap scroll points, but you couldn't have known that > > since I have not gotten around to making suitable tests! > > I wonder why snap scroll points rely on getting a delta of 0? I'm not sure. I'm debugging the code now to see why it matters. I think we have some kind of edge case where the user has ended the wheel motion and the snap animation is about to start. If we return 'false' in this case, the event is treated as unhandled and the animation never starts. I'll know more once I finish debugging.