Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit fc0bcdd9 authored by Ben Murdoch's avatar Ben Murdoch
Browse files

If the user performed a very quick touch sequence without a response 

from WebCore, then we would enter the ACTION_UP handler and cancel
pending touch events in WebCore's message queue. This cancellation
was orginally needed for Flash but the touch model for Flash has now changed
and it's no longer necessary. In the case of the layout test controller
the events do come very fast, and we were hitting this case so
WebCore was losing the events that got cancelled meaning that the
JS touch callbacks weren't getting invoked.

This was exposed by fast/events/basic-single-touch-events.html.

Change-Id: Icea09fb55a5b77f7ab9c19473cfa5ae272867a9a
parent b1b96c90

core/java/android/webkit/WebView.java

+13 −3
Original line number Diff line number Diff line
@@ -4763,9 +4763,11 @@ public class WebView extends AbsoluteLayout 
                        invalidate();

                        break;

                    }



                    if (!mConfirmMove) {

                        break;

                    }



                    if (mPreventDefault == PREVENT_DEFAULT_MAYBE_YES

                            || mPreventDefault == PREVENT_DEFAULT_NO_FROM_TOUCH_DOWN) {

                        // track mLastTouchTime as we may need to do fling at
@@ -4933,9 +4935,17 @@ public class WebView extends AbsoluteLayout 
                            if (mPreventDefault != PREVENT_DEFAULT_YES

                                    && (computeMaxScrollX() > 0

                                            || computeMaxScrollY() > 0)) {

                                // UI takes control back, cancel WebCore touch

                                cancelWebCoreTouchEvent(contentX, contentY,

                                        true);

                                // If the user has performed a very quick touch

                                // sequence it is possible that we may get here

                                // before WebCore has had a chance to process the events.

                                // In this case, any call to preventDefault in the

                                // JS touch handler will not have been executed yet.

                                // Hence we will see both the UI (now) and WebCore

                                // (when context switches) handling the event,

                                // regardless of whether the web developer actually

                                // doeses preventDefault in their touch handler. This

                                // is the nature of our asynchronous touch model.



                                // we will not rewrite drag code here, but we

                                // will try fling if it applies.

                                WebViewCore.reducePriority();