[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