[Webkit-unassigned] [Bug 77477] [chromium] Process scroll-gesture events from the MT compositor

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Feb 3 11:08:55 PST 2012


https://bugs.webkit.org/show_bug.cgi?id=77477





--- Comment #14 from sadrul at chromium.org  2012-02-03 11:08:55 PST ---
(From update of attachment 125032)
View in context: https://bugs.webkit.org/attachment.cgi?id=125032&action=review

>>>> Source/WebKit/chromium/src/WebCompositorInputHandlerImpl.cpp:155
>>>> +        if (m_scrollStarted) {
>>> 
>>> i think we should ASSERT() on m_scrollStarted, not branch. if we get a scrollupdate without a scrollbegin it means that the caller has broken the contract with us - we should fail fast and loudly, not try to limp along IMO
>> 
>> Indeed. I am using m_expectedScrollUpdateEnd for precisely this purpose (e.g see lines 139, 154, 162). m_scrollStarted is used to make sure we don't call scrollBy or scrollEnd if the call to scrollBegin returned something other than ScrollStarted.
> 
> Right. I'm saying you should NOT do this, you should just ASSERT().

Just to make sure I understand clearly :-) ... consider the following case:
- A GestureScrollBegin event comes in. It triggers a scrollBegin. However, for whatever reason, scrollBegin returns ScrollIgnored, therefore setting m_scrollStarted to false. The caller of the function (i.e. the source of the event) isn't aware that scrolling didn't start successfully.
- The event-source sends a GestureScrollUpdate event. Since scrolling didn't start successfully, i.e. m_scrollStarted is false, this will trip the ASSERT. But should this really cause a crash? The event-source did send a GestureScrollBegin before sending a GestureScrollUpdate, thereby meeting the expectation of WebCompositorInputHandlerImpl.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list