Bug 82408 – [chromium] Send wheel events to main thread even if we think nothing is scrollable

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[James Robinson]

[chromium] Send wheel events to main thread even if we think nothing is scrollable

[James Robinson]

Created attachment 134192 [details]
Patch

[James Robinson]

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).

[Adrienne Walker]

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?

[James Robinson]

(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.

[WebKit Review Bot]

Comment on attachment 134192 [details]
Patch

Clearing flags on attachment: 134192

Committed r112363: <http://trac.webkit.org/changeset/112363>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.