Touch input issues using WebView

Native Development
1

Dear Magic Leap team,

Our app runs in immersive mode. We have an Android WebView that we want to display as a 3D plane.
For this, we create a "hidden" Android WebView that renders a user interface (html/javascript). The content of that WebView is continuously transferred into a texture we render on a 3D plane. Rendering works as expected.

For input, we receive Controller pose and button states from Magic Leap and pass touch input to our WebView with dispatchTouchEvent(event) call. This works for the most part.

However, the problem appears when the WebView continues to receive what seem to be spurious or phantom touch inputs coming directly from ML controller to the WebView. These events always have same 2D coordinates and we can't seem to find a way to block them. We tried blocking them by overriding setOnTouchListener of our Webview.

mWebView.setOnTouchListener(new View.OnTouchListener() {
    @Override
    public boolean onTouch(View v, MotionEvent event) {
        return true;
    }
});

That sample is taken from Disable WebView touch events in Android - Stack Overflow.

The WebView that we create within our Activity continues to receive touch input which is directly received from the controller when pressing the trigger button. We can see the system debug output from ml_input.h in Logcat.

I have attached a sample project that creates a WebView and tries to block these touch inputs. Without success. You can still click on links using the controller. That sample project is working on an Android phone, blocking touch input.
It looks like the Magic Leap Controller bypasses the Activity and sends the touch inputs directly to the WebView.

Is that controller/touch-input behaviour intentional, or is it a bug. Maybe we are missing something?

Thanks in advance,
Richard
CoherentSample.zip (875.1 KB)

ML2 OS version: 1.3.0-dev2
MLSDK version: 1.3.0-dev2
Host OS: MacOS

2

Hello @rp1 Thank you for your question. I'm reaching out to our native development team and I'll report back here asap. Apologies for the delay.

3

Hi @rp1, I spoke to our engineers and they recommended using onGenericMotionEvent() instead of onTouchEvent() to avoid receiving a touch event while pressing the controller trigger.

The issue may be when pressing the trigger, a scroll event can be sent continuously, which might not be avoided by onTouchEvent.

Please reference this:

Please let me know if this unblocks you.

4

Sorry for my late reply,
I will test your engineers suggestion.
Hopefully this will fix it.

Thanks,
Richard

5

Hi @kdowney,
I have tried to block GenericMotionEvents for this WebView, but without success.

The strange thing is that the x and y coordinates for these unwanted touch events always stay the same over the lifetime of the app. It's the last position where I pointed the controller before initializing the web view.

Another thing is when pause and resume our app, the web view does not receive these spurious touch events anymore, and everything works as expected.

Thanks,
Richard

6

Thank you for the update @rp1, I will talk to the team about this and report back.

7

Hi @rp1, we tested by adding the below code in your sample app. I believe this blocks the touch event:

        mWebView.setOnGenericMotionListener(new View.OnGenericMotionListener() {
            @Override
            public boolean onGenericMotion(View v, MotionEvent motionEvent) {
                return true;
            }
        });

Can you please let us know if this works for you?

8

Hi @kdowney ,

Yes, this was working for the sample app. But, did not work for our App.

I found a solution, which completely disables touches for the whole activity. We are still able to programatically pass touches to our WebView.

By adding this to our Activity:

getWindow().setFlags(WindowManager.LayoutParams.FLAG_NOT_TOUCHABLE,
                WindowManager.LayoutParams.FLAG_NOT_TOUCHABLE);

taken from java - Disable Touch for the whole Activity - Stack Overflow

Thanks a lot for your support,
Richard.

9

Thank you for the update @rp1. Glad to hear you found a solution.