Topic: Visitor chat window always loading.

[nbtc971]

I have a problem after a new install where, if the visitor clicks "Start Chat" the loading image comes up and never goes away. This is on your latest build 2.1. Everything else seems to function. The user appears in the operator window but nothing changes the loading state. At first, while testing, this wasn't a problem, but after about 20 minutes all of a sudden this popped up and I couldn't make it go away with hard refresh of the browser window or any other means. I can recreate this error in latest builds of Firefox, Edge and Chrome. I'm about to give up hope and move onto something else, but I have this loaded and it does everything I need and would like to get it working.

Any help is appreciated.

Thanks,
Doug

[scalior]

Hello,

I have experienced a similar (but not exact) issue before. I can't consistently reproduce but roughly it happens under these circumstances:
1. Visitor closes their browser without closing the thread.
2. The thread is closed automatically after a period of inactivity.
3. Visitor navigates to the website again. The chat window will be blank and have the loading icon. Only way to recover is to clear browser cache.

Your case is different because if I understand correctly, the user loads clicks the button to start a chat. The chat windows opens up, the user types their name and click start chat. At this point the chat is never started and remains in a loading state.

I had come up with a state diagram for Mibew 1.6.x and haven't updated it for 2.x but it should be a good starting point. If you are a developer then this can help you narrow down the section of code where the state changes from loading to queued. Something is preventing the state transition.
https://github.com/alberto234/mibew/blob/mibewmob-1.6.12/src/mibew/mobile/docs/design/ChatThreadStateDiagram.pdf

Eyong

[nbtc971]

I uninstalled and reinstalled and haven't had this problem any more. But thanks for your reply.

[scalior]

I have had this happen to me again. Attached is a screenshot of what it looks like when this happens, together with a view of the developer tools. The popup window has a "Not Found" text. The developer tools window shows that it is trying to retrieve a thread (that has been automatically closed??) and it can't so the javascript fails at that point.

I still can't reproduce this reliably. If I have a consistent way of reproducing it I will share. What happened this time was that I had a window up for a chat session which was about 2 days old. I wanted to test again in that window and I refreshed the page. Upon refreshing the page, this happened.

Can this new information provide better insight on why this is happening and how to resolve it?

Eyong

[Dmitriy Simushev]

Well, it sounds like something is wrong with keeping current thread id for user. The ID should be kept in cookies so may be it helps to reproduce the problem?

At the moment, I could not fix something that could not be reproduced.

[scalior]

I have narrowed down the problem further to this section of code in UserChatController::indexAction()

        // We have to check that the thread is owned by the user.
        $is_own_thread = isset($_SESSION[SESSION_PREFIX . 'own_threads'])
            && in_array($thread_id, $_SESSION[SESSION_PREFIX . 'own_threads']);
        $thread = Thread::load($thread_id, $token);
        if (!$thread || !$is_own_thread) {
            throw new NotFoundException('The thread is not found.');
        }

What happens here is that.
1. The visitor starts the chat but doesn't close/exit the chat.
2. The visitor closes their browser tab but not the browser so the browser session is still active. Or, in my case, puts the computer to sleep for about a day.
3. On the server, the session is expired or garbage collected since there has been no activity for a long time (e.g session.gc_maxlifetime)
4. When the visitor returns, the thread id is not found in the session in the highlighted code above.
5. This causes the Not Found and always loading behavior

To handle this condition, some client side code could be added that if the server returns a Not Found for the thread, then the frame is closed...

If you can find a way to quickly expire the session then you can reproduce this without waiting for a day. I can open a ticket in GitHub if this is confirmed a bug.

Eyong