Widget issues with consequent chats

[RLukasevic]

Describe the bug This problem only happens for Android users (seems like ios is ok for now) and most likely is chrome browser issue (iphone users don‘t get this issue + in admin panel browser detects as chrome). First time customer can successfully have a chat with agent – widget refreshes, answers are visible. When the same customer starts second session (or third and later), not at the same time, just new conversation – chat widget buttons stop working correctly. „Start conversation“ and „exit conversation“ doesn‘t refresh window and customer doesn‘t see responses from webview. We checked it many times by deleting customer contact and his conversation history from chatwoot. First chat is always good, next one – no. We are using chatwoot-react-native-widget 0.0.18, react-native 0.66.5 Video recording of a failing chat session on Android https://github.com/chatwoot/chatwoot/assets/118850916/e9f811e5-5ea6-4749-8c46-a3b850397fd3

To Reproduce Open Chat Widget on Android phone, type a message, press „Start conversation“ then „exit conversation“ and close the Chat Widget. If customer does this for the first time, the chat session will succeed. Open Chat Widget on Android phone, using the same customer as in step1, and type a message. Pressing „Start conversation“ will not refresh the Chat Widget and it will look as if nothing has happened. Please see attached video recording in "describe the bug" section.

Expected behavior When returning customer on Android phone presses „Start conversation“, Chat Widget refreshes, thus notifying the customer that the message has been sent.

[imvlat]

Hello @pranavrajs @nithindavid !

It was confirmed on Chatwoot Mobile App developer Discord chat that the issue is reproducible by other users https://discord.com/channels/647412545203994635/1162333290162819112/1163434444091310112

Could you please check React Native chatwoot libraries?

And please respond to sales@chatwoot.com - our customer plans to buy Premium support, but no reaction so far.

Kind regards, Mihails Ivanovs | Belam

[pranavrajs]

@muhsin-k Can you please take a look at this on priority this week?

[pranavrajs]

@imvlat @RLukasevic I'm not sure if this is an issue with the widget or the SDK. We have large customers using ReactNative SDK on Android applications and haven't heard the same feedback from them. It must be something related to the installation. We will confirm this soon and let you know.

On the purchase for premium support, let me see if we have missed any conversation. I will revert to the email.

[muhsin-k]

@RLukasevic @imvlat Based on our investigation, we are unable to reproduce this issue on our end. We have tested it using two different Android phones and everything is working correctly.

https://github.com/chatwoot/chatwoot-react-native-widget/assets/12408980/aca3a6df-df53-4767-9129-557c988aca3b

Could you please provide the setup details for the React Native widget? We will look into this further.

[tobsowo]

I have this same issue when there's a pre-form, it does exactly as in the video attached but when I removed the form, the charts don't send and it shows a retry icon but wouldn't still send.

See a test here https://bluespace.ng

[tobsowo]

This happens not only on mobile but also on web and desktop.

https://discord.com/channels/647412545203994635/1163547031546118154

[imvlat]

Hello @tobsowo ! Your issues look different. There was absolutely no issue for us in a Chrome mobile browser. It is the React Native app on Android that caused issues... This is not a server issue that we have.

[imvlat]

Could you please provide the setup details for the React Native widget? We will look into this further.

Dear @muhsin-k could we have a very short call and the developers of Native React app demonstrate the issue? One important clarification - the issue only happens on Android React Native app when user identity validation is enforced.

What could be your availability time slots?

Kind regards, Mihails

[RLukasevic]

@muhsin-k So pretty much we use 0.0.18 version of the lib, couldnt manage to make it work on android properly (ios was ok), tried forking the lib and upgrading react-native-webview dependency - nothing changed.

For now we managed to to make the chat work implementing our own webview sourcing it with the html containing web script to inject the 'web' widget into the app and using some sdk methods to make it look as it looked with a widget library, for now it seems everything is ok with this solution. If you need any more in-depth info - im willing to try to provide anything you find informative for the case.

For the matter of lib working we also checked if the information we were postMessageing to the widget was correct and was always present, and basically played with it in different manner to try to find the issue on our end but couldnt succeed in doing so, so the only option we saw by making it work for now is using chatwoot's web solution for the time being

[muhsin-k]

@imvlat Sure. Lets continue this discussion here.

[imvlat]

Dear @muhsin-k , thank you for today's session! As a result of the meeting you were able to witness and reproduce the issue from your side. Looking forward to hearing the root-cause analysis and soon resolution of this bug in React Native Android app for authenticated user consecutive chats' initiation.

[muhsin-k]

Thank you for reporting the issue. After conducting a thorough investigation, which involved a comprehensive series of trials and errors, we have been successful in identifying the root cause of the problem that has been reported.

I've started debugging using the web widget, as per the customer's information. This is due to the React Native widget simply presenting it in a web view.

I found out that the identifier_hash was incorrect.

After fixing the identifier_hash value, I tested it again. The problem persisted on Android, but it functioned without any issues on both iOS and Web. From this session, I concluded that the issue is specific to Android, and there are no issues with the widget at all.

Upon further debugging using the inspect view of the Webview, it was found that for every hash change in the URL, the entire webpage reloads. This causes the setting messages to reappear, even if the messages were cleared at the start of a new conversation.

Steps to reproduce the issue

• Start a new conversation using the widget. Please note that the Allow messages after conversation resolved option should be disabled in your widget settings.
• Resolve the conversation from the widget.

• Clicking the "Start new conversation" button will clear the current conversation and messages, redirecting you to the pre-chat form. This function works fine.

• Upon entering the pre-chat form, the messages API is called again, causing the messages to set. This is due to a bug in the React Native WebView.

• When a user types and sends a message, it creates a new conversation. However, the page gets stuck in the pre-chat form. The condition for changing the route only applies when the previous message size is 0. But in our case, it has some values, so the route does not change.

The primary issue is that the injectedJavaScript property in react-native-webview is causing the page to reload when the widget URL hash changes. This problem occurs only on Android, not on iOS.

We are working on this issue. In the meantime, to resolve the issues, we are introducing a route change mechanism based on bus events. So, if a new conversation is successfully created, we will change the route to the message view. This PR will fix the issue.

[imvlat]

Dear @muhsin-k should we wait for some release to test the fix or should we just substitute files in the hosted chatwoot environment?

[muhsin-k]

@imvlat The fix is available in the latest release 3.3.1.