[Bug]: Ignored attempt to cancel a touchmove event

[TheDutchCoder]

Braze Web SDK Version

5.1.0

Integration Method

NPM

Browser

Chrome

Steps To Reproduce

Default init of Braze web SDK, no special setup needed. This error has started showing up since the latest version:

Expected Behavior

No error to be thrown

Actual Incorrect Behavior

A client-side error is thrown in the browser.

Verbose Logs

No response

Additional Information

No response

[bealeofsteel]

Hi, unfortunately I'm not able to reproduce that error with just the default init logic. Would you be able to provide a minimal reproduction of the error?

[TheDutchCoder]

It's hard for me to setup a repro for non open source code :) I think all that needs to be added to that logic is an additional && t.cancelable before calling the t.preventDefault().

Not sure where it is in the source, but I would assume in the automaticallyShowInAppMessages export.

Additional info: this so far only seems to occur on Android with Chrome as the browser. We use automaticallyShowInAppMessages after init of Braze and I think it's somewhere in there where the issue arrises.

[bealeofsteel]

We'll go ahead and implement the proposed solution, but if there are any other details or code snippets you're able to share please let us know.

[TheDutchCoder]

Thank you, I will keep an eye on it.

In fact I think some other piece of code might be responsible, as this started happening in two separate projects we use this SDK on, but we didn't update the SDK itself.

Might also be a browser change of course.

[sircelsius]

Hi @TheDutchCoder thanks for reporting and providing all these details 🙏

We have an open PR on our closed source with a proposed fix, but we will hold until you can confirm that this is not caused by a change on your end.

We will also attempt to reproduce again on Chrome for Android.

[TheDutchCoder]

@sircelsius awesome thanks!

So far my investigation shows this only happens on Android Chrome mobile v120, v123, and v124. So I wonder if Chrome for Android has a change in this area.

I would assume the touch event that the error relates to has become uncancelable. Wether that's due to a browser change, or some 3rd party change I'm not sure of. The stack trace is very minimal and only shows Braze tripping over this.

I think it won't hurt to check for cancelable regardless, before attempting to prevent the default, I think that's best practice (though it would be great if it wouldn't throw an error in Chrome).

[bealeofsteel]

Hi @TheDutchCoder, this behavior should be fixed in version 5.3.0, which was just released. Thank you for helping to improve our SDK!

[TheDutchCoder]

@bealeofsteel Thank you so much for doing this. It's pretty rare to see a somewhat larger company actually action this type of thing quickly 😉

I'll update the dep tomorrow and report back!

[TheDutchCoder]

It's been a few hours and I haven't seen the error pop up anymore. I'll keep an eye on it throughout the day/night, but I think this is fixed.

Thanks again!