[chromium] Send wheel events to main thread even if we think nothing is scrollable
Created attachment 134192 [details] Patch
This is a conservative fix for http://code.google.com/p/chromium/issues/detail?id=119984, see http://code.google.com/p/chromium/issues/detail?id=119984#c17, and meant as a quick fix. The behavior with DidNotHandle is never worse than if we didn't have the thread, since without the thread these events would have gone to the main thread anyway. We don't have webkit_unit_test coverage for wheel handling (which is another bug that should be fixed).
Comment on attachment 134192 [details] Patch R=me. This seems quite reasonable as a short-term fix. Sending the event to the main thread that we think won't get handled isn't going to hurt anything. Could this happen if we get input before we finish the first commit?
(In reply to comment #3) > (From update of attachment 134192 [details]) > R=me. This seems quite reasonable as a short-term fix. Sending the event to the main thread that we think won't get handled isn't going to hurt anything. > > Could this happen if we get input before we finish the first commit? I'm not entirely sure. From the trace on the crbug there were many many frames of ScrollIgnored, not just a one-off. I think what I'll do is add a bit of state tracking locally to compare the compositor thread results to the main thread results for each input event and see if I can repro, then backtrack from there.
Comment on attachment 134192 [details] Patch Clearing flags on attachment: 134192 Committed r112363: <http://trac.webkit.org/changeset/112363>
All reviewed patches have been landed. Closing bug.