Title: [119862] trunk/Source/WebCore
- Revision
- 119862
- Author
- [email protected]
- Date
- 2012-06-08 13:37:35 -0700 (Fri, 08 Jun 2012)
Log Message
EventHandler shouldn't schedule the fake mousemove event timer when scrolling on devices that don't have a mouse
https://bugs.webkit.org/show_bug.cgi?id=88379
Reviewed by James Robinson.
Patch by Antonio Gomes <[email protected]>
Paraphrasing Andy Estes:
"In <http://trac.webkit.org/changeset/119465> we stopped dispatching fake
mousemove events when scrolling on devices that don't support mice. This event
is dispatched on a timer, so one better would be to not even schedule the
timer (rather than scheduling the timer but making it a no-op).
No new tests, as no functionality has changed. We basically do not
start a timer under a given circumstance instead of fire it, it times out,
and we make the callback no-op when under the given circumstance.
It is still possible though that we have the following scenario:
- Setting::deviceSupportsMouse set as true;
- we fire the timer;
- before its callback gets executed (timed out) the setting gets toggled.
So for sakeness, lets keep the check in both places.
* page/EventHandler.cpp:
(WebCore::EventHandler::dispatchFakeMouseMoveEventSoon):
(WebCore::EventHandler::fakeMouseMoveEventTimerFired):
Modified Paths
Diff
Modified: trunk/Source/WebCore/ChangeLog (119861 => 119862)
--- trunk/Source/WebCore/ChangeLog 2012-06-08 20:31:28 UTC (rev 119861)
+++ trunk/Source/WebCore/ChangeLog 2012-06-08 20:37:35 UTC (rev 119862)
@@ -1,3 +1,30 @@
+2012-06-08 Antonio Gomes <[email protected]>
+
+ EventHandler shouldn't schedule the fake mousemove event timer when scrolling on devices that don't have a mouse
+ https://bugs.webkit.org/show_bug.cgi?id=88379
+
+ Reviewed by James Robinson.
+
+ Paraphrasing Andy Estes:
+ "In <http://trac.webkit.org/changeset/119465> we stopped dispatching fake
+ mousemove events when scrolling on devices that don't support mice. This event
+ is dispatched on a timer, so one better would be to not even schedule the
+ timer (rather than scheduling the timer but making it a no-op).
+
+ No new tests, as no functionality has changed. We basically do not
+ start a timer under a given circumstance instead of fire it, it times out,
+ and we make the callback no-op when under the given circumstance.
+
+ It is still possible though that we have the following scenario:
+ - Setting::deviceSupportsMouse set as true;
+ - we fire the timer;
+ - before its callback gets executed (timed out) the setting gets toggled.
+ So for sakeness, lets keep the check in both places.
+
+ * page/EventHandler.cpp:
+ (WebCore::EventHandler::dispatchFakeMouseMoveEventSoon):
+ (WebCore::EventHandler::fakeMouseMoveEventTimerFired):
+
2012-06-08 James Robinson <[email protected]>
[chromium] Clean up some unnecessary LayerChromium.h includes
Modified: trunk/Source/WebCore/page/EventHandler.cpp (119861 => 119862)
--- trunk/Source/WebCore/page/EventHandler.cpp 2012-06-08 20:31:28 UTC (rev 119861)
+++ trunk/Source/WebCore/page/EventHandler.cpp 2012-06-08 20:37:35 UTC (rev 119862)
@@ -2628,6 +2628,10 @@
if (m_mousePressed)
return;
+ Settings* settings = m_frame->settings();
+ if (settings && !settings->deviceSupportsMouse())
+ return;
+
// If the content has ever taken longer than fakeMouseMoveShortInterval we
// reschedule the timer and use a longer time. This will cause the content
// to receive these moves only after the user is done scrolling, reducing
_______________________________________________
webkit-changes mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-changes
