Признаюсь, воспроизвести это крайне сложно! Проблема проявляется крайне непостоянно, и нам не удалось выявить закономерность.
2 лайка
@pmusaraj Быстрый вопрос — как вы думаете, это связано с Discourse в целом или с конкретной темой? Я пока не смог определить, к какому именно компоненту это относится, но думаю, что это может помочь исправить проблему?
Я думаю, что это не связано с конкретной темой или компонентом; скорее всего, проблема касается самого Discourse. Я воспроизвёл её в начале этой недели на сайте Discourse, где практически не было установлено никаких компонентов.
3 лайка
Спасибо за информацию! Это раздражает, потому что из-за этого UX становится ужасным, и пользователям приходится перезагружать страницу или возвращаться назад. Просто пытаюсь заранее найти обходное решение.
1 лайк
Это происходит с новым поддоменом Discourse Discover (Safari для настольных ПК):
Похоже, что это происходит случайно и нечасто. Есть ли возможность запустить диагностический тест, когда это происходит, чтобы выявить проблему?
4 лайка
Согласно нашему анализу на данный момент, поддомен Discourse полагает, что он всё ещё является хостом, и любые относительные ресурсы/ссылки оказываются нерабочими. Это означает, что всё будет работать, только если использовать абсолютный путь (например, discourse.org/css/main.css вместо /css/main.css). Однако это довольно странное решение, так как оно потребует указания абсолютных путей для всех иконок, изображений, ссылок (href), JavaScript-файлов, CSS-файлов и т. д.
1 лайк
Это происходит и на десктопе, и на мобильных устройствах, но только в Safari.
- Необходимые элементы страницы (внешний домен) всё ещё отображаются в логах Discourse, хотя должны регистрироваться на внешнем домене. Не удалось отладить, когда это происходит
- Один из обходных путей (вместо изменения всех CSS/JS/HREF на абсолютные пути) — разместить <base href=“https://mydomain.com/”> в заголовке всех соответствующих страниц (на внешнем домене)
2 лайка
Я только что сообщил о соответствующей проблеме до того, как меня направили сюда, что, похоже, связано с этим.
Мы обновились до Discourse 3.2 два дня назад, и с тех пор нам поступают сообщения о подобной проблеме. Хотя в нашем случае это не связано с CSS, я считаю, что суть проблемы в целом та же.
После перехода по ссылке в Discourse на наш основной веб-сайт браузер всё ещё считает, что находится на форуме: URL-адрес в браузере это подтверждает (!), а иногда (некоторые? вероятно, относительные) ссылки открываются в домене форума, выдавая ошибку о том, что страница форума не существует. Все полученные нами пока сообщения касаются iPhone/iPad. Я не могу воспроизвести это ни разу, но затронутые пользователи сталкиваются с этим несколько раз в день. Просматривая логи Discourse, я могу подтвердить наличие нескольких запросов 404 к страницам, которые существуют только на нашем основном веб-сайте.
Меня довольно озадачивает тот факт, что браузер открывает один сайт, но показывает URL другого (без использования iframe). Если это ошибка Safari, я очень надеюсь, что она ограничена только верхним доменом, поскольку в противном случае последствия для безопасности могут быть довольно серьёзными.
В любом случае, стоит иметь в виду, что это началось только после обновления до Discourse 3.2, значит, что-то изменилось по сравнению с версией 3.1 и вызывает эту проблему.
Возможно, это完全是 гадание, но интересно, не связано ли это каким-то образом с PWA-приложениями и тем, как Safari их обрабатывает? Наш основной веб-сайт объявляет PWA-приложение — и наш форум Discourse тоже. Оба используют режим standalone и указывают start_url: "/" (у нас установлен уникальный id, а у Discourse нет). Насколько мне известно, файлы манифеста PWA не указывают конкретное имя хоста, в котором они работают, поэтому я предполагаю, что они привязаны к тому хосту, где размещены. В нашем случае оба PWA находятся на разных поддоменах, но в рамках одного домена; в том, как браузеры обрабатывают это, может быть пространство для ошибок, которые сбивают браузер с толку. Но, с другой стороны, это лишь чистое предположение.
2 лайка
Если это обычная ссылка (в нашем случае это иконка навигации вверху), то, возможно, target=_blank (или даже target=_top?) может служить временным решением?
Насколько я помню, мы пробовали и это, и замену HREF на JS:function с вызовом ‘window.open’, но результат остался прежним. Помните: внешняя страница действительно загружается — значит, DNS для этого нового домена работает корректно. Однако при выполнении скрипта и загрузке относительных ресурсов этой страницы переключение на этот домен не происходит. Как я уже говорил, внутренний Safari «base» HREF не обновляется/не переключается при загрузке страницы, из-за чего ресурсы загружаются относительно текущего «base» домена → 404.
Возможно ли намеренно загрузить JS или CSS из Discourse?
Я опробовал подход с target=_blank, и все сообщения пока указывают на то, что проблема исчезла. Не идеально, но хорошо иметь временное решение, пока не прояснится ситуация.
К слову, это происходит не только при клике пользователя по ссылке, но и при «перенаправлении» через JavaScript.
Мы используем SSO на нашем форуме и настроили logout redirect с URL основного сайта. Когда пользователь выходит из форума, и Discourse «перенаправляет» его на наш основной сайт, это также вызывает проблему в Safari. Судя по данным консоли, это не настоящее перенаправление 302, возможно, это изменение window.location.
Спасибо всем за обсуждения и отладку здесь.
Этот обходной путь достаточно прост для проверки, поэтому я добавил его на этот сайт (meta.discourse.org) через компонент темы. Если это решит проблему, это будет весьма полезно, так как, полагаю, это может помочь разработчикам Webkit отладить основную причину. (И независимо от этого мы также можем рассмотреть возможность добавления тега base в ядро Discourse по умолчанию.)
Мне кажется, что обходной путь с тегом base может помочь, если применить его на внешнем сайте, так как проблема, похоже, возникает после ухода с сайта на базе Discourse.
Тестирование проводится на Meta для обработки конкретного случая ссылок между двумя разными экземплярами Discourse? Или я где-то запутался (что вполне возможно! 
)?
1 лайк
Да, наша самая частая проблема связана со ссылками между двумя экземплярами Discourse. Я думаю, что обходной путь с тегом base также может помочь, если его использовать на исходном сайте (а целевой не является экземпляром Discourse). Если корень проблемы в том, что Safari/Webkit путают базовые URL (это не так уж далеко от ваших предположений о PWA выше), то добавление другого базового URL на один из сайтов может помочь разрушить ошибочное предположение, лежащее в основе проблемы? Это тоже мои догадки, но попробовать стоит.
1 лайк
Это ломает кнопку личных сообщений?
У меня она не работала, пока я не отключил темы через безопасный режим.
1 лайк
Хорошо подмечено, это действительно его ломает. Я временно отключил компонент с тегом base.
3 лайка
Привет 
Не знаю, новая ли это проблема, но сейчас проверил, что происходит на iPad. Заметил, что это случается каждый раз после смены страницы при навигации в браузере или свайпе. Иногда это происходит и в других случаях. Это очень легко воспроизвести на главной странице с темой Meta Branded, используя кнопки в строке поиска.
На видео: в первый раз переход назад через навигацию браузера, во второй — свайпом, в третий — кликом по логотипу.
7 лайков
Да, точно, эти шаги воспроизводят проблему каждый раз у меня в Safari для настольных ПК. Отлично, @Don 
В текстовом виде:
-
Откройте meta.discourse.org в Safari
-
Нажмите «Guides»
-
Вернитесь назад (используя кнопку, жест, сочетание клавиш или что угодно)
-
Нажмите «Our Hosting» — это ссылка на
discourse.org/pricing -
Обратите внимание на сломанную страницу.
window.locationвсё ещё указывает наmeta.discourse.org, но HTML-код соответствуетdiscourse.org/pricing
9 лайков