I wasn't able to try this locally due to not in kiosk mode. but from the video it looks like the app implements dragging via touch event.
If that's the case, it may related to https://www.chromestatus.com/feature/4764225348042752

Could you check if your app are using ontouch* events, or it may only add touch event listener when window.ontouchstart (or something similar)

eirage@: The repro doesn't mention requiring kiosk mode. Were you able to get the app?

Reporter: Is TestNav in the Chrome Store?

Yes, I downloaded the app from chrome store and tried to log in with the account provided, and it required kiosk mode while logging in.

You should be able to enable kiosk mode with a flag (--enable-consumer-kiosk looks promising?). Could you give that another try? Otherwise we can reach out to someone on ChromeOS to get their help (or reporter, if you know how please chime in).

Please try with the below user id/pwd that can be used on the non-kiosk mode on the same env specified in the defect. 

Username: LGN021756854
pwd: N2JXN7EC

The above user id/pwd will work infinite times. So, feel free to submit the test as many times as needed. 

Thanks. Confirm that it's due to the change with chrome://flags/#touch-events. (https://www.chromestatus.com/feature/4764225348042752)

Reporter, are you able to change your page to avoid using ontouch* events? (try using |addEventListener| for touch events, or navigator.maxTouchPoints for touchscreen detection.

Comments from our developer: 

Not sure if this is what they are suggesting, but I don't think it's realistic to have the app itself listen for touch events and then send them down to the javascript code running inside the webview.  I believe what they are saying is that we can detect the touch events in the current application javascript code (not the app, the stuff Moosas team works on) as long as we use addEventListener instead of ontouch.  Please check with them first to see if they are using ontouch and how much work it would be to switch to the event listeners instead.  I don't think there is anything we can do in the app that would work at an acceptable level.  I've also gotten the feeling the apps are getting less control over events in the webview, as shown by them removing any way for the apps to capture keyboard events.

Thanks!

> I don't think it's realistic to have the app itself listen for touch events and then send them down to the javascript code running inside the webview

I don't believe this is related to app <-> webview integration/differences. the API change should be the same in both contexts. So if the touch listeners are registered using |ontouchstart| in the webview today, those would just have to be converted to addEventListener('touchstart', () => {...}).

There hasn't been any feedback from the reporter. Closing this for now. Reporter if you still hit the issue or have more comments feel free to comment here or file a new issue.

Hi, this has been fixed internally. This can be closed. Thanks!