General > Русский (ru)
У пользователя всплывает пустое окно чата, которое не закрыть
postgres:
Mibew версия 2.0
У пользователя на любой странице сайта всплывает пустое окно чата. Содержимое во фрэйм не заливается, элементы формы тоже, закрыть его по этой причине нет никакой возможности - жать не на что. В окне только фраза "Элемент не найден" - кажется так. Судя по ситуации, пользователь начал диалог, оставил его закрытым и далее эта история началась.
помогите найти способ исправить ситуации на сервере, без необходимости чистить куки клиента в браузерах.
Dmitriy Simushev:
1. На данный момент, было выпущено девять версий Mibew 2.0: пять альфа версий и четыре бета версии. Так какую именно версию Вы используете?
2. Без подробного технического описания проблемы никто (кроме телепатов, которые снова в отпуске) не сможет ответить на Ваш вопрос. Интересуют следующие моменты:
2.1 наличие у клиента антивируса или чего-то что может фильтровать трафик браузера
2.2 содержимое лога ошибок веб сервера
2.3 список браузеров в которых появляется проблема (разумеется с ОС и версиями)
2.4 точное сообщение об ошибке в окне браузера
2.5 используется ли ad-blocker в браузере клиента
2.6 другие факты, которые могут иметь отношение к проблеме (кроссдоменная установка, ...)
UPD: Забыл уточнить еще несколько пунктов:
2.7 ОС сервера
2.8 версии используемого ПО (apache, php, mysql, ...)
2.9 содержимое лога ошибок веб сервера
postgres:
mibew/operator/about
=========================
Информация о системе
Вы используете:
2.0.0-beta.3
Последняя версия:
2.0.0-beta.4, Download 2.0.0-beta.4
Установленные языковые пакеты:
ru
Окружение:
PHP 5.5.17 PDO/1.0.4dev pdo_mysql/1.0.2 gd
====================================
Сервер apache 2.4 + php 5.5 + FPM/FastCGI
Лог сервера:
===============================
81.222.**.156 - - [26/Mar/2015:18:22:47 +0300] "POST /mibew/operator/users/update HTTP/1.1" 200 936
81.222.**.156 - - [26/Mar/2015:18:22:49 +0300] "POST /mibew/operator/users/update HTTP/1.1" 200 932
81.222.**.156 - - [26/Mar/2015:18:22:50 +0300] "POST /mibew/operator/users/update HTTP/1.1" 200 937
81.222.**.156 - - [26/Mar/2015:18:22:52 +0300] "POST /mibew/operator/users/update HTTP/1.1" 200 932
81.222.**.156 - - [26/Mar/2015:18:22:53 +0300] "POST /mibew/operator/users/update HTTP/1.1" 200 936
81.222.**.156 - - [26/Mar/2015:18:22:55 +0300] "POST /mibew/operator/users/update HTTP/1.1" 200 930
81.222.**.156 - - [26/Mar/2015:18:22:56 +0300] "POST /mibew/operator/users/update HTTP/1.1" 200 936
81.222.**.156 - - [26/Mar/2015:18:22:58 +0300] "POST /mibew/operator/users/update HTTP/1.1" 200 932
81.222.**.156 - - [26/Mar/2015:18:22:59 +0300] "POST /mibew/operator/users/update HTTP/1.1" 200 937
81.222.**.156 - - [26/Mar/2015:18:23:01 +0300] "POST /mibew/operator/users/update HTTP/1.1" 200 930
81.222.**.156 - - [26/Mar/2015:18:23:02 +0300] "POST /mibew/operator/users/update HTTP/1.1" 200 937
81.222.**.156 - - [26/Mar/2015:18:23:04 +0300] "POST /mibew/operator/users/update HTTP/1.1" 200 931
81.222.**.156 - - [26/Mar/2015:18:23:05 +0300] "POST /mibew/operator/users/update HTTP/1.1" 200 936
81.222.**.156 - - [26/Mar/2015:18:23:07 +0300] "POST /mibew/operator/users/update HTTP/1.1" 200 931
81.222.**.156 - - [26/Mar/2015:18:23:09 +0300] "POST /mibew/operator/users/update HTTP/1.1" 200 937
81.222.**.156 - - [26/Mar/2015:18:23:10 +0300] "POST /mibew/operator/users/update HTTP/1.1" 200 932
81.222.**.156 - - [26/Mar/2015:18:23:11 +0300] "POST /mibew/operator/users/update HTTP/1.1" 200 937
81.222.**.156 - - [26/Mar/2015:18:23:13 +0300] "POST /mibew/operator/users/update HTTP/1.1" 200 932
81.222.**.156 - - [26/Mar/2015:18:23:14 +0300] "POST /mibew/operator/users/update HTTP/1.1" 200 936
или вот так еще бывает
81.222.**.156 - - [26/Mar/2015:18:23:26 +0300] "POST /mibew/operator/users/update HTTP/1.1" 200 937
81.222.**.156 - - [26/Mar/2015:18:23:27 +0300] "GET /mibew/chat/style/popup HTTP/1.1" 200 103
===========================================================================
в логах ошибок пусто
Клиент сам сообщил о проблеме, самостоятельно сайт коммерческий клиент корпоративный, поэтому важно было срочно проблему устранить.
В связи с этим не успел собрать информацию о проблеме в полной мере, но кое что есть:
1. Проблема решилась чисткой куки.
2. Перед этим пробовал < 2.5 используется ли ad-blocker в браузере клиента > да, но отключение не помогало.
3. Перед этим пробовал другой браузер. Проблема была в Хроме и отсутствовала в эксплорере < список браузеров в которых появляется проблема (разумеется с ОС и версиями) > какая то винда у него стояла.
4. < 2.4 точное сообщение об ошибке в окне браузера > увы, не успел запомнить. или "объект не найден", или "элемент не найден", но точно помню что "не найден" присутствовало.
Возможно это и есть то что возвращал сервер в 103 байтах.
Факторы или обстоятельтва, которые могли вызвать ситуацию:
1. Замена кода кнопки. Как вариант предполагаю это, хотя НА рабочем сайте код кнопки я не менял. Попробую протестировать ситуацию, открытое окно диалога у клиента и замена кнопки на сервере.
2. Пользователь, поскольку корпоративный, был вовлечен в тестирование уполномоченным лицом, оставил диалог открытым. Затем мессенджер был перенесен на рабочий сайт, выставлена другая кнопка, имя рабочего сайта тоже отличается от тестового. Теперь по кукам мессенджер пытается найти ... а тех уж нет.
Скромно полагаю, что
ситуацию надо разруливать на стороне сервера либо как плановое clean-задание по крону, либо удалением кук при респонсе в соответствующих условиях.
Готов подключиться к реализации. Есть ли где описание жизненного цикла окна диалога? Или точки останова контрольные...
Dmitriy Simushev:
--- Quote ---1. Проблема решилась чисткой куки.
--- End quote ---
Это многое объясняет.
--- Quote ---3. Перед этим пробовал другой браузер. Проблема была в Хроме и отсутствовала в эксплорере < список браузеров в которых появляется проблема (разумеется с ОС и версиями) > какая то винда у него стояла.
--- End quote ---
А вот это странно. Если я правильно понял проблему, то она должна относится ко всем браузерам, а не только к Chrome. Хотя, это может быть связано с каким-то багом IE.
--- Quote ---4. < 2.4 точное сообщение об ошибке в окне браузера > увы, не успел запомнить. или "объект не найден", или "элемент не найден", но точно помню что "не найден" присутствовало.
Возможно это и есть то что возвращал сервер в 103 байтах.
--- End quote ---
Ничего подобного. В этих 103-х (в Вашем случае) байтах содержится инструкция по загрузке стиля всплывающего окна.
--- Quote ---Есть ли где описание жизненного цикла окна диалога? Или точки останова контрольные...
--- End quote ---
К сожалению, у нас не хватает рук, чтобы заниматься описанием схем и алгоритмов работы чего бы то ни было. Однако ниже я приведу очень обобщенное описание принципа работы всплывающих окон диалога.
1. При генерации кнопки ей присваивается некий уникальный идентификатор.
2. При открытии диалога клиентом у него устанавливается сессионная cookie для домена второго уровня (что делает ее видимой для всех поддоменов). В имя этой cookie включается уникальный код кнопки (см. п.1), к которой она относится.
3. При переходе по страницам проверяется наличие cookie из п.2. Если она есть -- повторно открвается iframe с диалогом. Если нет -- ничего не происходит.
--- Quote ---2. Пользователь, поскольку корпоративный, был вовлечен в тестирование уполномоченным лицом, оставил диалог открытым. Затем мессенджер был перенесен на рабочий сайт, выставлена другая кнопка, имя рабочего сайта тоже отличается от тестового. Теперь по кукам мессенджер пытается найти ... а тех уж нет.
--- End quote ---
Что-то мне подсказвает, что Mibew был перенесен либо в другой каталог того же домена, либо с одного поддомена на другой. А это означает, что cookie, отслеживающая открытость диалога, осталась валидной, в то время как Mibew по прежнему адресу оказался недоступен. Это объясняет ошибку "объект не найден".
--- Quote ---Скромно полагаю, что
ситуацию надо разруливать на стороне сервера либо как плановое clean-задание по крону, либо удалением кук при респонсе в соответствующих условиях.
--- End quote ---
А вот тут Вы не правы. Дело в том, что cookie удалится после закрытия браузера автоматически. Именно поэтому не предусмотрено каких-то дополнительных механизмов очистки. В реальных условиях (я не говорю о тестировании) система работает стабильно и проблем с пустым окном диалога нами замечено не было.
Что же касается конкретно Вашего случая с тестированием и переносом Mibew, то я рекомендую либо использовать разные кнопки для тестового и боевого окружения (разные кнопки -- разные cookie), либо указать тестировщикам на необходимость закрывать браузер (именно браузер а не вкладку) после окончания тестирования (cookie сессионная и будет автоматически уничтожена браузером).
Ну и напоследок, мы всегда рады сторонним разработчикам, уделяющим внимание проекту. Если у Вас будут какие-то конкретные предложения/вопросы по коду -- можете отправлять их нам по электронной почте (см. https://mibew.org/ru/contacts). :)
postgres:
Нечаянно воспроизвели ситуацию, кажется так было дело:
Закрыли диалог со стороны клиента и сразу перешли на другую страницу сайта.
"Not Found!" - вот что там написано было в окне. Вспомнил Чехова.
Вчера я предполагал что куки сессионные и браузер Хром закрывал, однако нет, вчера не помогло. Там у товарища три дня эта ситуация присутствовала.
Здесь и сейчас у нас - помогло. ОТкрыли закрыли - куки сбросились. ПОлагаю что вчерашний случай имеет свои "осложнения", поэтому не буду втягиваться в эту сторону.
Тестовый сайт на домене третьего уровня, а рабочий на втором, то есть куки у них одни и те же получаются в моем случае.
Вывод - "на каждый поддомен - своя база". Верно ли?
--- Quote ---Дело в том, что cookie удалится после закрытия браузера автоматически. Именно поэтому не предусмотрено каких-то дополнительных механизмов очистки.
--- End quote ---
Увы, но я, зная своих пользователей, на это особо не рассчитываю. Без мотивации браузер закрывать? Вот еще.
Поэтому вписываюсь...
Navigation
[0] Message Index
[#] Next page
Go to full version