App bridge is interfering with textarea [New]

Hi all,
My shopify app is facing an issue when loading in app bridge.
When editing any textarea it is not working, pressing backspace anywhere in the textarea is taking cursor to start of the textarea as if values don’t even exist.
Textarea is only working when I am adding anything to the start of textarea (like a whitespace or text).

I have previous solution like disabling “Save-bar” but not does not solve my problem. App is not using save bar feature as per my knowledge.

Hey there @zaheet_dev, thanks for reaching out and flagging this.

We’ve seen similar behaviors in iframes with focus interference, so testing in an isolated minimal page (without other forms or App Bridge components) could help pinpoint if it’s styling, event bubbling, or something else.

To dig a bit deeper, could you share a minimal code snippet of your implementation where you’re seeing this pop up, your App Bridge initialization code, any console errors when it happens, and the browser/version where you’re seeing this? Also, could you confirm if this occurs in modals or standard pages, and whether you’re on the latest App Bridge/Polaris versions? Feel free to check the App Bridge debugging docs here as well in case it’s helpful.

Hope to hear from you soon, happy to look into this for sure.

Hi @Alan_G thank you for your response.
I found that the issue was caused by beforeinput event added to textarea by app-bridge.js.
I am using this.
This is occurring on standard page.

Here is the min repro.

<html>
<head>
    <title>App Bridge Textarea Reproduction</title>
    <script src="https://code.jquery.com/jquery-3.4.1.min.js"></script>
    <!-- 1. Include Shopify App Bridge -->
    <script src="https://cdn.shopify.com/shopifycloud/app-bridge.js"></script>
    <script>
        const apiKey = 'YOUR_SHOPIFY_API_KEY';
    </script>
</head>
<body>

    <h1>App Bridge Textarea Issue</h1>
    <p>
        When App Bridge is initialized, it attaches a "beforeinput" event listener to form elements to track changes for the save bar.
        This can interfere with other JavaScript or cause re-rendering issues.
        Try typing in the textarea below. You may notice input lag or other unexpected behavior.
    </p>

    <!-- The textarea with static content -->
    <textarea id="myTextarea" name="zones" rows="10" cols="50">
    US-CA
    US-TX
    90210
    10001-10090
    </textarea>
</body>
</html>```

Please run this in `/apps` iframe to see the issue.

Thanks @zaheet_dev - looking into this for you now. I’ll loop back with you here once I can share next steps/confirm a fix :slight_smile:

1 Like

Hey @zaheet_dev , I was able to work with our team internally on this and we were unable to replicate the issue, but we did notice that jQuery is being loaded in your code, as well as an id on the textarea appearing. Could you try disabling jQuery if possible and letting us know if the issue persists? Just want to try to narrow down the cause - hope to hear from you soon!

Hi @Alan_G, sorry for the late response.

I’ll try again with jQuery disabled, but in the meantime, could you please follow the steps below to reproduce the issue using the provided snippet?

  1. Go to any store that has apps installed (any app should work).
  2. Open the app.
  3. Open the Developer Tools (right-click > Inspect Element).
  4. Locate the iframe element.
  5. Replace the contents of its html node with the snippet I shared earlier.

You should be able to reproduce the same error using these steps. Let me know if you face any issues while trying this out.

We had the exact same problem. It started one day, out of nowhere, and it affected a regular text area element, that had no other handlers or special behaviour attached.

The only thing that “solved” the problem was to disable the saveBar with <meta name="shopify-disabled-features" content="saveBar" />. If you try that, make sure it’s added ABOVE the script that loads AppBridge.

We never used the saveBar, but it seems to attach event handlers anyway.

I tried to inspect the handler function and it appears to use the defaultValue property at some point, but I couldn’t make much sense of the intended logic due to the code being minified/obfuscated. I just remember noticing it use defaultValue when it could be reading the value at the start. Don’t know if the defaultValue is part of the cause.

Hey @zaheet_dev and @flavio-b - thanks for following up on this. I believe I was able to replicate the issue on my end here. Just wanted to share the below to confirm this is what you’re both seeing on your end:

It looks like if I pre-populate the textarea with values, it does cause the edit cursor to get “bumped” to the initial starting coordinate in the editor. It can be fixed by clicking elsewhere in the box though, but I realize that’s not a great workaround or ideal UI for sure.

Happy to take this to the team on my end to report this at the very least and investigate further, but just wanted to confirm my reproduction is correct here. Hope to speak soon! :slight_smile:

1 Like

Yep, that’s exactly it. I recorded another video to show the same problem:

@Alan_G yes, that is exactly what we are facing. Thank you.

Side note
@flavio-b you can fix this issue temporarily by disabling “beforeinput” event like this

$('textarea').on('beforeinput', function (e) {
		e.stopImmediatePropagation();
})
1 Like

Thanks @zaheet_dev and @flavio-b - I’ll get in touch with some folks internally and investigate further. I’ll circle back with you folks here once I have next steps or a solution/can confirm a fix.

1 Like

Hi @Alan_G, any updates on this?

Hey @zaheet_dev, thanks for following up on this.

I don’t have a fix to share yet, but I’ve escalated this internally to get it prioritized. As well, could you let me know if removing jQuery from your original script changes the behaviour? Just want to see if that’s potentially the issue there so that I can bring a bit more information to our product team.

Hey @zaheet_dev, just looping back with you here. I still don’t have a concete turnaround time, but I just wanted to confirm that I’ve spoken with our product team on this and we are investigating this as a possible bug now.

I’ll keep my eye on things for you and get back in touch as soon as I have a fix/next steps to share. Thanks again for your patience on this as well, really appreciated :slight_smile: