879791 - Unexpected empty event queue in processEventBlock - java.lang.Exception in TouchEventHandler

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: Toolbar, defect)

Description

[Aaron Train [:aaronmt]]

Currently on attempts to invoke the virtual keyboard in content, such as the <input> on about:config, I sometimes receive the following exception (and as a result not properly invoking the virtual keyboard at all) on each attempt to focus:

E/GeckoTouchEventHandler(12831): java.lang.Exception
E/GeckoTouchEventHandler(12831): 	at org.mozilla.gecko.gfx.TouchEventHandler.processEventBlock(TouchEventHandler.java:251)
E/GeckoTouchEventHandler(12831): 	at org.mozilla.gecko.gfx.TouchEventHandler.handleEventListenerAction(TouchEventHandler.java:204)
E/GeckoTouchEventHandler(12831): 	at org.mozilla.gecko.gfx.JavaPanZoomController.notifyDefaultActionPrevented(JavaPanZoomController.java:333)
E/GeckoTouchEventHandler(12831): 	at org.mozilla.gecko.GeckoAppShell$10.run(GeckoAppShell.java:1470)
E/GeckoTouchEventHandler(12831): 	at android.os.Handler.handleCallback(Handler.java:725)
E/GeckoTouchEventHandler(12831): 	at android.os.Handler.dispatchMessage(Handler.java:92)
E/GeckoTouchEventHandler(12831): 	at android.os.Looper.loop(Looper.java:137)
E/GeckoTouchEventHandler(12831): 	at android.app.ActivityThread.main(ActivityThread.java:5041)
E/GeckoTouchEventHandler(12831): 	at java.lang.reflect.Method.invokeNative(Native Method)
E/GeckoTouchEventHandler(12831): 	at java.lang.reflect.Method.invoke(Method.java:511)
E/GeckoTouchEventHandler(12831): 	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:793)
E/GeckoTouchEventHandler(12831): 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:560)
E/GeckoTouchEventHandler(12831): 	at dalvik.system.NativeStart.main(Native Method)

I'm not sure of the exact conditions to raise this; adding steps-wanted for assistance.

--
LG Nexus 4 (Android 4.2.2)
Nightly (06/05)

Comment 1

[Brad Lassey [:blassey] (use needinfo?)]

filter on [mass-p5]

Comment 2

[Kartikaya Gupta (email:[e-mail])]

Aaron, have you seen this recently? I haven't seen any other bugs reported on this, so it might be WFM now.

Comment 3

[Ralf]

I get this when scrolling through any website. Every touch triggers the following error:


E/GeckoTouchEventHandler(25629): Unexpected empty event queue in processEventBlock!
E/GeckoTouchEventHandler(25629): java.lang.Exception
E/GeckoTouchEventHandler(25629):        at org.mozilla.gecko.gfx.TouchEventHandler.processEventBlock(TouchEventHandler.java:241)
E/GeckoTouchEventHandler(25629):        at org.mozilla.gecko.gfx.JavaPanZoomController.notifyDefaultActionPrevented(JavaPanZoomController.java:363)
E/GeckoTouchEventHandler(25629):        at org.mozilla.gecko.GeckoAppShell$12.run(GeckoAppShell.java:1498)
E/GeckoTouchEventHandler(25629):        at android.os.Handler.handleCallback(Handler.java:725)
E/GeckoTouchEventHandler(25629):        at android.os.Handler.dispatchMessage(Handler.java:92)
E/GeckoTouchEventHandler(25629):        at android.os.Looper.loop(Looper.java:153)
E/GeckoTouchEventHandler(25629):        at android.app.ActivityThread.main(ActivityThread.java:5299)
E/GeckoTouchEventHandler(25629):        at java.lang.reflect.Method.invokeNative(Native Method)
E/GeckoTouchEventHandler(25629):        at java.lang.reflect.Method.invoke(Method.java:511)
E/GeckoTouchEventHandler(25629):        at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:833)
E/GeckoTouchEventHandler(25629):        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:600)
E/GeckoTouchEventHandler(25629):        at de.robv.android.xposed.XposedBridge.main(XposedBridge.java:132)
E/GeckoTouchEventHandler(25629):        at dalvik.system.NativeStart.main(Native Method)


As a side effect links on websites are marked as selected after touched when scrolling, even when released. Another reproducible effect is that the menu (on the upper right) on http://m.heise.de does not function as expected. When touched it opens but the menu-entries cannot be selected.

I tested older versions and found that it happens since Firefox 35 up to version 38.0b8. Version 34 and below works fine. The above error gets not triggered, links are not shown as selected when scrolling and the menu on heise.de works fine.

Android version is 4.2.2.

Comment 4

[Kartikaya Gupta (email:[e-mail])]

Would you be able to use mozregression to get a narrower window as to when this broke for you? The code that is directly related to this error didn't change between 34 and 35, so it must have been a side-effect of some other change, and getting a regression window would be helpful.

http://harthur.github.io/mozregression/

Comment 5

[Ralf]

Thank you for the quick response!

This is the first time I used mozregression. Amazing tool. Here is the result:

11:45.89 LOG: MainThread Bisector INFO Narrowed nightly regression window from [2014-09-23, 2014-09-25] (2 days) to [2014-09-24, 2014-09-25] (1 days) (~0 steps left)
11:45.89 LOG: MainThread Bisector INFO Got as far as we can go bisecting nightlies...
11:45.89 LOG: MainThread Bisector INFO Last good revision: 1e2993c99323
11:45.89 LOG: MainThread Bisector INFO First bad revision: 1735ff2bb23e
11:45.89 LOG: MainThread Bisector INFO Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1e2993c99323&tochange=1735ff2bb23e

11:45.89 LOG: MainThread Bisector INFO ... attempting to bisect inbound builds (starting from 4 days ago, to make sure no inbound revision is missed)
11:48.11 LOG: MainThread Bisector INFO Getting inbound builds between 27253887d2cc and 1735ff2bb23e
11:56.70 LOG: MainThread Bisector INFO No inbound data found.
11:56.70 LOG: MainThread Bisector INFO There are no build dirs on inbound for these changesets.

Comment 6

[Ralf]

Reverting changeset 84b81989aa76 seems to fix it.
https://hg.mozilla.org/mozilla-central/rev/84b81989aa76

I reverted it on 35.0b1 since I had problems building the sources after hg clone mozilla-central and going back to 1735ff2bb23e.

Hope this helps.

Comment 7

[Kartikaya Gupta (email:[e-mail])]

Thanks, that does help a lot! I think what's happening is that there's a mismatch between the C++ code [1] and Java code [2] in terms of what gets treated as a touch-start event which causes the TouchEventHandler code to get out of sync. I'll put together a patch for you to try against the latest mozilla-central code.

[1] http://mxr.mozilla.org/mozilla-central/source/widget/android/AndroidJavaWrappers.cpp?rev=085956254fe4#694
[2] http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/gfx/TouchEventHandler.java?rev=c2cd82f2d911#209

Comment 8

[Kartikaya Gupta (email:[e-mail])]

Attachment: Possible fix

Can you try with this patch to see if it fixes the problem for you?

Comment 9

[Ralf]

Sorry to say that this patch does not fix the problem.

Do you think it makes sense if I would split changeset 84b81989aa76 and test which of the different diffs is fixing the issue when reverted?

Comment 10

[Kartikaya Gupta (email:[e-mail])]

Sure. I suspected it was the hunk at https://hg.mozilla.org/mozilla-central/rev/84b81989aa76#l6.57 but I could be wrong.

Comment 11

[Ralf]

Bingo! Thank you very much!

Reverting this hunk only fixes the issue. Just to be clear, I only reverted the following:

--- a/widget/android/AndroidJavaWrappers.cpp
+++ b/widget/android/AndroidJavaWrappers.cpp
@@ -684,25 +687,40 @@ AndroidGeckoEvent::MakeTouchEvent(nsIWid
         return mApzInput.ToWidgetTouchEvent(widget);
     }
 
     int type = NS_EVENT_NULL;
     int startIndex = 0;
     int endIndex = Count();
 
     switch (Action()) {
+        case AndroidMotionEvent::ACTION_HOVER_ENTER: {
+            if (ToolTypes()[0] == AndroidMotionEvent::TOOL_TYPE_MOUSE) {
+                break;
+            }
+        }
         case AndroidMotionEvent::ACTION_DOWN:
         case AndroidMotionEvent::ACTION_POINTER_DOWN: {
             type = NS_TOUCH_START;
             break;
         }
+        case AndroidMotionEvent::ACTION_HOVER_MOVE: {
+            if (ToolTypes()[0] == AndroidMotionEvent::TOOL_TYPE_MOUSE) {
+                break;
+            }
+        }
         case AndroidMotionEvent::ACTION_MOVE: {
             type = NS_TOUCH_MOVE;
             break;
         }
+        case AndroidMotionEvent::ACTION_HOVER_EXIT: {
+            if (ToolTypes()[0] == AndroidMotionEvent::TOOL_TYPE_MOUSE) {
+                break;
+            }
+        }
         case AndroidMotionEvent::ACTION_UP:
         case AndroidMotionEvent::ACTION_POINTER_UP: {
             type = NS_TOUCH_END;
             // for pointer-up events we only want the data from
             // the one pointer that went up
             startIndex = PointerIndex();
             endIndex = startIndex + 1;
             break;


Can I hope this will go into one of the following firefox releases?

Comment 12

[Kartikaya Gupta (email:[e-mail])]

Just reverting this hunk will break accessibility features. The patch I attached was trying to fix this properly. I'll have to think a bit more about why it didn't work.

Comment 13

[Ralf]

Attachment: Test with current release

This is the result when the bug is triggered in current relases

Comment 14

[Ralf]

Attachment: Test with reverted changeset 84b81989aa76

This is the result when reverting changeset 84b81989aa76

Comment 15

[Ralf]

I looked deeper in when the exception is thrown and how touches are registered. Test site:

http://www.snappymaria.com/canvas/TouchEventTest.html


logcat says that the exception is thrown right after releasing the finger from touch screen.

Comment 16

[Kartikaya Gupta (email:[e-mail])]

Attachment: Possible fix v2

Here's a different approach to fixing it - can you try this to see if it works?

Comment 17

[Ralf]

Thanks for the patch. It does not fix the bug completely but I can see improvement. 

Fixed:
Links on websites are no longer marked as selected when scrolling.

Still not working:
The menu (top right) at http://m.heise.de 
It opens when touched but the entries cannot be selected and it cannot be closed.

TouchEventTest.html shows that there is still one "touch start" event after releasing the finger from the touch screen. It looks completely like on https://bugzilla.mozilla.org/attachment.cgi?id=8601146

Not sure if this may help you but I found that it is sufficient to revert the first hunk (ACTION_HOVER_ENTER) only. The result from TouchEventTest.html then looks exactly the same like when testing with Chrome. I'll attach another screenshot.

     int type = NS_EVENT_NULL;
     int startIndex = 0;
     int endIndex = Count();
 
     switch (Action()) {
+        case AndroidMotionEvent::ACTION_HOVER_ENTER: {
+            if (ToolTypes()[0] == AndroidMotionEvent::TOOL_TYPE_MOUSE) {
+                break;
+            }
+        }
         case AndroidMotionEvent::ACTION_DOWN:
         case AndroidMotionEvent::ACTION_POINTER_DOWN: {
             type = NS_TOUCH_START;
             break;

Comment 18

[Ralf]

Attachment: Test with only first hunk reverted (ACTION_HOVER_ENTER)

Comment 19

[Kartikaya Gupta (email:[e-mail])]

So it sounds like the remaining issue is not related to the exception in comment 3 but is the change in bug 969512 interfering with actual non-accessibility input on a real device. Eitan, can you look into this? I'm not sure I'll have time to continue poking around here specially since I don't have a device that can reproduce the problem. Sounds like some devices are generating hover events which we are improperly turning into touch events which get dispatched to content and screw things up.

Comment 20

[Eitan Isaacson [:eeejay]]

I'm trying to reproduce this with no success. It is very strange that gecko is receiving hover events without accessibility enabled, and without any mouse attached (i am assuming). Two questions:

1. What kind of device is this?
2. Is it possible you have any installed app that is activating the accessibility service?

Comment 21

[Ralf]

Hi Eitan,

as far as I can see the accessibility service gets not activated by one of the installed apps.

The device is a Mediatek based device, the Fairphone:

CPU:      mt6589m
Display:  4.3" 960x540
Android:  4.2.2

May be it is a Mediatek related issue?

I have tested http://www.snappymaria.com/canvas/TouchEventTest.html with Chrome, the stock browser and Opera which all do not show this behaviour. The result looks like in https://bug879791.bugzilla.mozilla.org/attachment.cgi?id=8601546

Other users of this device can confirm the problem with Firefox.

Comment 22

[Ralf]

Would it break accessibility features on other devices if the order of the "case AndroidMotionEvent" statements in AndroidJavaWrappers.cpp is changed? With the following patch applied the problem disappears.

--- a/widget/android/AndroidJavaWrappers.cpp    2015-05-08 13:26:44.895919107 +0200
+++ b/widget/android/AndroidJavaWrappers.cpp    2015-05-08 13:03:42.780271354 +0200
@@ -691,16 +691,16 @@
     int endIndex = Count();
 
     switch (Action()) {
-        case AndroidMotionEvent::ACTION_HOVER_ENTER: {
-            if (ToolTypes()[0] == AndroidMotionEvent::TOOL_TYPE_MOUSE) {
-                break;
-            }
-        }
         case AndroidMotionEvent::ACTION_DOWN:
         case AndroidMotionEvent::ACTION_POINTER_DOWN: {
             type = NS_TOUCH_START;
             break;
         }
+        case AndroidMotionEvent::ACTION_HOVER_ENTER: {
+            if (ToolTypes()[0] == AndroidMotionEvent::TOOL_TYPE_MOUSE) {
+                break;
+            }
+        }
         case AndroidMotionEvent::ACTION_HOVER_MOVE: {
             if (ToolTypes()[0] == AndroidMotionEvent::TOOL_TYPE_MOUSE) {
                 break;

Comment 23

[Kartikaya Gupta (email:[e-mail])]

That would likely break stuff, because then the hover-enter event will get treated as a touchmove rather than a touchstart. But Eitan would know more about that.

Comment 24

[Eitan Isaacson [:eeejay]]

Yes, that would break it. That blog is meant to fall through to the ACTION_DOWN/ACTION_POINTER_DOWN case if the tool type is not MOUSE.

But this is telling us something if that's what you need for it to work. Could you add an ALOG line in the ACTION_HOVER_ENTER block to see what the tooltype is?

Comment 25

[Ralf]

I tried inserting an ALOG line but nothing is printed. Could you please give an example how to get the tooltype printed so I could grab it via logcat? Sorry, I'm not a developer.

Comment 26

[Ralf]

Ok, I had to uncomment #define FORCE_ALOG 1, now it woks.

case AndroidMotionEvent::ACTION_HOVER_ENTER: {
     ALOG("DEBUG: ToolType is: %d", ToolTypes()[0]);

gives 1.
Looking at AndroidJavaWrappers.h let me assume it corresponds with TOOL_TYPE_FINGER.


So this fixes the issue, too (but for sure will also break the accessibility features):

--- widget/android/AndroidJavaWrappers.cpp.orig 2015-05-08 20:43:58.215786061 +0200
+++ widget/android/AndroidJavaWrappers.cpp      2015-05-09 21:59:44.504913039 +0200
@@ -692,7 +692,8 @@
 
     switch (Action()) {
         case AndroidMotionEvent::ACTION_HOVER_ENTER: {
-            if (ToolTypes()[0] == AndroidMotionEvent::TOOL_TYPE_MOUSE) {
+            if (ToolTypes()[0] == AndroidMotionEvent::TOOL_TYPE_MOUSE ||
+                  ToolTypes()[0] == AndroidMotionEvent::TOOL_TYPE_FINGER) {
                 break;
             }
         }


How to fix it without breaking anything else is beyond my knowledge.

Comment 27

[Eitan Isaacson [:eeejay]]

(In reply to Ralf from comment #26)
> Ok, I had to uncomment #define FORCE_ALOG 1, now it woks.
> 
> case AndroidMotionEvent::ACTION_HOVER_ENTER: {
>      ALOG("DEBUG: ToolType is: %d", ToolTypes()[0]);
> 
> gives 1.
> Looking at AndroidJavaWrappers.h let me assume it corresponds with
> TOOL_TYPE_FINGER.
> 
> 
> So this fixes the issue, too (but for sure will also break the accessibility
> features):
> 
> --- widget/android/AndroidJavaWrappers.cpp.orig 2015-05-08
> 20:43:58.215786061 +0200
> +++ widget/android/AndroidJavaWrappers.cpp      2015-05-09
> 21:59:44.504913039 +0200
> @@ -692,7 +692,8 @@
>  
>      switch (Action()) {
>          case AndroidMotionEvent::ACTION_HOVER_ENTER: {
> -            if (ToolTypes()[0] == AndroidMotionEvent::TOOL_TYPE_MOUSE) {
> +            if (ToolTypes()[0] == AndroidMotionEvent::TOOL_TYPE_MOUSE ||
> +                  ToolTypes()[0] == AndroidMotionEvent::TOOL_TYPE_FINGER) {
>                  break;
>              }
>          }
> 
> 
> How to fix it without breaking anything else is beyond my knowledge.

OK, that is really interesting. Your device is sending finger hover events.

And, you are right, we rely on finger hover events to only exist in an accessibility context.

Comment 28

[Ralf]

Any ideas how to fix this problem?
Even though Chrome and other browsers work without problems I wish to continue to use Firefox.

Comment 29

[Kartikaya Gupta (email:[e-mail])]

Is there any API we can use to detect if accessibility mode is enabled? Then we could throw away finger hover events if it is disabled.

Comment 30

[Eitan Isaacson [:eeejay]]

Yes, I am working on a patch that will do exactly that, sorry for the delay. I got distracted by other work.

Comment 31

[Eitan Isaacson [:eeejay]]

Attachment: Don't send touchscreen hover events to gecko when accessibility is disabled.

Comment 32

[Eitan Isaacson [:eeejay]]

Comment on attachment 8611034 [details] [diff] [review]
Don't send touchscreen hover events to gecko when accessibility is disabled.

Hey Ralf,

Could you test this patch and see if it resolves the issues you see? Sorry for the delay.

Comment 33

[Kartikaya Gupta (email:[e-mail])]

Comment on attachment 8611034 [details] [diff] [review]
Don't send touchscreen hover events to gecko when accessibility is disabled.

Review of attachment 8611034 [details] [diff] [review]:
-----------------------------------------------------------------

r+ with comments fixed

::: mobile/android/base/gfx/LayerView.java
@@ +47,3 @@
>  import android.widget.FrameLayout;
>  
> +

remove newline

@@ +246,5 @@
>      @Override
>      public boolean onHoverEvent(MotionEvent event) {
> +        // If we get a touchscreen hover event, and accessibility is not enabled,
> +        // don't send it to gecko.
> +        if ((event.getSource() & InputDevice.SOURCE_TOUCHSCREEN) != 0 &&

I think this needs to be (event.getSource() == InputDevice.SOURCE_TOUCHSCREEN). SOURCE_TOUCHSCREEN is 0x1002 and so using & will match anything in SOURCE_CLASS_POINTER as well.

Comment 34

[Eitan Isaacson [:eeejay]]

Attachment: Don't send touchscreen hover events to gecko when accessibility is disabled. r=kats

Carrying over review, still waiting for feedback.

Comment 35

[Ralf]

Hi Eitan and Kartikaya,

thank you very much!
This patch resolves the issue.

Comment 36

[David Bolter [:davidb] (NeedInfo me for attention)]

Adding an NI for Eitan so he sees comment 35 (which I think equals an f+).

Comment 37

[Eitan Isaacson [:eeejay]]

Landed. Thanks for the NI, didn't see the positive feedback.

Comment 38

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/81fe755dfd47

Comment 39

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/81fe755dfd47

Comment 40

[Felix Dagenais]

Moving at word level granularity using accessibility a couple of times (and reaching border of the screen) crash the geckoview with the same stack :

E/GeckoTouchEventHandler(10450): Unexpected empty event queue in processEventBlock!
E/GeckoTouchEventHandler(10450): java.lang.Exception
E/GeckoTouchEventHandler(10450): 	at org.mozilla.gecko.gfx.TouchEventHandler.processEventBlock(TouchEventHandler.java:241)
E/GeckoTouchEventHandler(10450): 	at org.mozilla.gecko.gfx.TouchEventHandler.handleEventListenerAction(TouchEventHandler.java:199)
E/GeckoTouchEventHandler(10450): 	at org.mozilla.gecko.gfx.JavaPanZoomController.notifyDefaultActionPrevented(JavaPanZoomController.java:360)
E/GeckoTouchEventHandler(10450): 	at org.mozilla.gecko.GeckoAppShell$12.run(GeckoAppShell.java:1567)
E/GeckoTouchEventHandler(10450): 	at android.os.Handler.handleCallback(Handler.java:733)
E/GeckoTouchEventHandler(10450): 	at android.os.Handler.dispatchMessage(Handler.java:95)
E/GeckoTouchEventHandler(10450): 	at android.os.Looper.loop(Looper.java:136)
E/GeckoTouchEventHandler(10450): 	at android.app.ActivityThread.main(ActivityThread.java:5017)
E/GeckoTouchEventHandler(10450): 	at java.lang.reflect.Method.invokeNative(Native Method)
E/GeckoTouchEventHandler(10450): 	at java.lang.reflect.Method.invoke(Method.java:515)
E/GeckoTouchEventHandler(10450): 	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:779)
E/GeckoTouchEventHandler(10450): 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:595)
E/GeckoTouchEventHandler(10450): 	at dalvik.system.NativeStart.main(Native Method)

Comment 41

[Kartikaya Gupta (email:[e-mail])]

It would be better to file a new bug for the issue you're seeing, as the patches on this bug have already landed.

Comment 42

[Felix Dagenais]

Created a new bug : https://bugzilla.mozilla.org/show_bug.cgi?id=1208146

Comment 43

[Chris Peterson [:cpeterson]]

Removing steps-wanted keyword because this bug has been resolved.