Following my last comment, I just noticed that the AI chatbot sounds do not work with iPhones and iPads (I have not checked other types of mobile devices and tablets).
Can you guys look into this? If the sounds work at your end, please let me know how to troubleshoot and fix them.
Thank you!
Update: The sounds work randomly on mobile devices and tablets. Also, the sounds play after a long delay (say, seconds or even minutes after the chatbox has been opened and closed). Not good. Tried everything.
In addition to what I provided above, please incorporate a feature into your configurator that will allow us to mute sounds in any combination for desktops, tablets, and mobile devices.
You’ve brought up some really interesting points, and I’ve discussed them with our devs. Here’s what they shared:
We chose sounds that are quite universal, so each of them can work well for any of the 3 available actions.
Since the sounds are pretty versatile, any of them can fit different use cases. That said, here are a couple of combinations our devs personally recommend:
a) Open Window - No Sound, Messages - Bubble
b) Open Window - Soft 2, Messages - Click
We’d also like to mention that having no sound can be a perfectly good choice too. You don’t necessarily need to set a sound for every action.
For messages, we’d especially recommend Bubble, Click, and Soft. They’re short, gentle, and easy to recognize.
Just to make sure I understood this part correctly, do you mean cases where the Greeting appears above the chat bubble after a delay?
@Petar_Dietrich 's statement is true, I tested this early on when the feature come out and thought it was a issue with my device now hearing it from his side I can display my findings:
The delay on mobile appears to be a buffer potentially it has to grab the sound file to play it? we know the buffer is true at least because i noticed the Send Message Arrow took time to load a second later then usual.
After Opening Window, Using A Message, & Agent Message is delivered will then the browser recognize all the sound files and play consistently without a buffer.
Question:
Is the agent message sound supposed to trigger when the message is starting, midway, or at the done? I’ve gotten mixed triggers, potentially due to some JS intervening.
I like these sounds you have chosen, I personally would go with User Message having the “Click” personally I like the be consistent if messages are going to have audio all of them should have it.
That’s why I’d like it for Welcome Message / Greeting to have it when it pops up after delay
should I send over another AI Chatbot’s example of sounds for welcome message popup? I think it might help also solve the issue for the sound file buffer on mobile.
After additional testing, this does not appear to primarily be a permissions issue.
The behavior is more consistent with mobile browser audio initialization and asset loading, specifically on iOS Safari. On PC Chrome the issue does not appear present, which points more toward platform/browser handling differences rather than the chatbot feature itself failing.
Observed behavior:
First sound playback on mobile has a noticeable delay/buffer
After interaction and message activity, sounds begin playing consistently
The entire chatbot window appears to initialize more slowly during the first audio trigger
Once assets appear cached/initialized, the issue becomes much less noticeable
Most likely technical causes:
Audio assets are not preloaded on mobile
If the sound file is fetched only when first triggered, iOS Safari can introduce a delay before playback begins.
iOS Safari audio context initialization
Safari on iOS is known for stricter media handling. Audio systems often remain suspended until a user interaction initializes them. The first interaction may effectively be “unlocking” the audio pipeline.
Mobile caching behavior differs from desktop
Chrome on PC is generally more aggressive with preloading and caching assets, which could explain why the issue is difficult or impossible to reproduce there.
Most likely areas worth investigating:
preload sound assets during chatbot initialization
initialize/unlock audio context immediately after first user interaction
cache sounds in memory instead of loading on-demand
specifically test iOS Safari behavior against desktop browsers
At this point the evidence points more toward iOS Safari/mobile browser audio handling combined with initialization timing, rather than a permissions configuration problem.
@Adore is spot on! I can assure you, there’s an issue with sounds on iPhones and iPads.
We’re using iPhone 14 Pro Max phones, iPhone 16 Pro Max phones, and iPad Pro tablets. All devices loaded with the latest Apple software update: iOS 26.5 (effective May 11, 2026). What iPhone models and software are you using?
Also, can you tell us on what devices and operating systems your new sound feature was tested? Is there any way to disable the sound on mobile devices and tablets via JS/CSS?
So you know, we tested the sound features with the above devices under many Safari configurations (i.e., settings) and, of course, cleared cache prior to testing. Also, the tests were conducted using Wi-Fi (optimum case), but are still experiencing the issue.
Final action taken (for now): We disabled the new Sounds feature. This will ensure a consistent and equally-predictable chatbot behavior across all platforms, devices, and operating systems.
On PC there can still be interference if you click a Quick Reply/Suggested Message immediately after opening the chatbot window. This may be related to the same initial caching/loading behavior when the audio files are accessed for the first time.
If you wait a couple of seconds for the Opening Window sound to finish, then click a Quick Reply/Suggested Message, the audio usually plays correctly.
This seems similar to what is happening on mobile devices, except mobile behavior is noticeably worse and can remain buggy even in Incognito Mode or out of it.
Another possible cause could be how the browser is handling the sound library itself. Many AI chatbots only use one default audio file, but this chatbot allows users to choose from many different sounds. Because of that, the browser may be treating the audio assets as dynamic/changing files instead of static cached assets, which could cause additional loading or validation behavior on first playback.
Okay final idea, I’ll add on below :
Another possible factor could be the way the sound system is designed to support multiple states and user-selectable options.
Since the chatbot allows users to switch between many different sounds — including a “No Sound” option — the browser may be handling the audio assets more dynamically instead of treating them as permanently cached/static files. Depending on how the system initializes audio, the browser could be rechecking, loading, or validating sound assets during first use rather than keeping them persistently ready in memory.
That could help explain why the first playback after opening the chatbot is the most delayed, while later interactions become much smoother once the audio assets appear initialized or cached for the session.
I did some research and found that the following may help fix the “buggy” behavior of the Sounds feature on mobile devices and tablets. Please forward this to your developers.
Ensure all sound files are low-bitrate MP3 (around 20kb to 50kb) and are also using M4A Compressing the sound files and providing browser sound file type options is imperative.
Ensure selected sound files are pre-loaded. If pre-loaded, are the chatbot sounds pre-loaded as Base64 strings or external files? Base64 strings play much faster on mobile devices because they don’t require a separate download.
Are the sound files embedded into each widget’s code or are they hosted as a separate file? Embedding the sound files into each widget’s code will help minimize the issue.
Use HTML code that is compatible across multiple browser and operating systems.
Could Elfsight’s current widget installation code be part of the problem? It uses Async and Lazyload (Note: I did some testing at my end and it did not help).
Consider developing a JS script that we can add to the chatbot configurator that will help improve the reported condition.
I hope this leads to a fix (or improvement) for the reported sound behavior on mobile devices and tablets.
@Petar_Dietrich The suggestions you shared are already implemented. The issue seems to be caused by Safari’s strict restrictions. Our developers need a bit more time to investigate, and I’ll update you here as soon as I have news.
Thanks, @Max! Much appreciated. I will give the codes a spin and report back if any issues. Also, it would be great if your developers can eventually integrate into the AI chatbot configurator the codes you provided in the form of toggle switches. Cheers!
I tested both the CSS rules and JS code you provided above. They did not work for tablets and mobile phones. Also, the JS code you provided is invalid (per the AI Chatbot’s configurator).
Below is what worked for me. Also, please note that sounds will not play initially when using Firefox (natural behavior), only after user interaction with the chatbot.
Can you please ask your developers to triple-check? Note: Device emulators should not be used for testing, only real devices.
Glad your developers confirmed my JS code works. Perhaps the original one needs to be updated?
The CSS code you initially provided did not work for our iPhones and iPads (given the uniqueness of these devices). Mainly, iPads usually behave like Desktops so I had to adjust the code. Using your original CSS rules, the sound icon was still appearing on iPads (i..e, tablets), so I adjusted it.
From my end, using Firefox (latest revision, no alterations), the Open Window sound does not work. Only the Agent Message and User Message sounds work after the chatbot processes information.
I see that you’ve disabled sounds on tablet and mobile, so I’ve tested the Firefox issue on my laptop and the Open window sound is working fine there:
Do I get it right that you were referring to the issue on desktop? Or did you mean tablet and mobile?
If the issue occurs on desktop, please send me a video screencast of the issue and specify the exact device model.
Dell Core Services app (installed via Dell Display and Peripheral Manager app). It was creating other issues on our Dell laptops/desktops, so I deleted the apps.
My JS code above introduced a custom function (noted below) that broke Firefox’s sound behavior.
In Firefox, HTMLMediaElement.prototype.play() is expected to return the browser’s native Promise from the original implementation. My custom function broke it.
So, to fix the above and still retain the requirements for iOS devices, I updated the JS code. Use code below. If you agree, you’re welcome to “sanitize” this post by deleting all information that may confuse other readers/users. I’m OK with that.
I hope this helps. Thank you so much for your assistance and keeping me honest