Tengo que admitir que es súper difícil de reproducir. Es muy inconsistente y no pudimos encontrar un patrón.
@pmusaraj Pregunta rápida: ¿Creemos que está relacionado con Discourse en general o con un tema específico? Aún no he podido determinarlo en un solo componente, pero me pregunto si eso podría solucionarlo.
Creo que no es un tema o componente específico, probablemente tenga que ver con Discourse en general. Lo reproduje a principios de esta semana en un sitio de Discourse que tenía muy pocos componentes instalados.
¡Gracias por compartir! Es frustrante porque la experiencia de usuario es terrible debido a eso y los usuarios tienen que recargar la página o retroceder. Solo estoy tratando de ser proactivo sobre una solución alternativa.
Esto está sucediendo con el nuevo subdominio de descubrimiento de Discourse (Safari en escritorio):
Parece ser aleatorio que ocurra, no con frecuencia. ¿Hay alguna forma de ejecutar una prueba de diagnóstico cuando esto ocurre para descubrir el problema?
Basándonos en nuestro análisis hasta ahora, el subdominio de discurso cree que sigue siendo el host y, por lo tanto, cualquier recurso/enlace relativo está roto. Es decir, a menos que se utilice una ruta absoluta (por ejemplo, discourse.org/css/main.css en lugar de /css/main.css) funcionará. Pero es una solución alternativa bastante loca, ya que incluiría cualquier icono, imagen, href, js, css, etc.
Esto ocurre tanto en escritorio como en móvil, solo para Safari.
- Las partes de página requeridas (dominio externo) todavía aparecen en el registro de Discourse, mientras que deberían haberse registrado en el dominio externo. No pude depurar cuándo ocurre

- Una solución alternativa (en lugar de cambiar todo el CSS/JS/HREF a ruta absoluta) es colocar \\u003cbase href="https://mydomain.com/\"\\u003e en el encabezado de todas las páginas relevantes (en el dominio externo)

Acabo de reportar un problema relacionado antes de que me señalaran este, que parece estar relacionado.
Acabamos de actualizar a Discourse 3.2 hace dos días y desde entonces estamos recibiendo informes de un problema similar. Aunque en nuestro caso no está relacionado con CSS, creo que el problema es esencialmente el mismo.
Después de seguir un enlace en Discourse a nuestro sitio web principal, el navegador todavía piensa que está en el foro: la URL en el navegador así lo indica (!), y a veces los enlaces (¿algunos? probablemente relativos) se abren en el dominio del foro en su lugar, con un error que dice que la página del foro no existe. Los informes que tenemos hasta ahora son todos en iPhone/iPad. No puedo reproducirlo en absoluto, pero los afectados parecen experimentarlo varias veces al día. Mirando los registros de Discourse, puedo confirmar que hay varias solicitudes 404 a páginas que solo existen en nuestro sitio web principal.
Me desconcierta bastante que el navegador abra un sitio web y muestre la URL de otro (sin iframes). Al ser un error de Safari, espero que esto solo esté confinado dentro de un dominio superior, ya que las implicaciones de seguridad de lo contrario son bastante desagradables.
En cualquier caso, creo que algo a tener en cuenta es que esto solo comenzó a suceder después de que actualizamos a Discourse 3.2, por lo que algo cambió desde la 3.1 que está provocando esto.
Quizás una suposición completamente al azar, pero me pregunto si esto podría estar relacionado de alguna manera con las aplicaciones PWA y cómo son manejadas por Safari. Nuestro sitio web principal declara una aplicación PWA, y nuestro foro de Discourse también. Ambos son standalone y con start_url: "/". (el nuestro establece un id único, pero Discourse no). Por lo que sé, los archivos manifest de PWA no especifican un nombre de host particular en el que operan, por lo que supongo que se adhiere al específico en el que están alojados. En nuestro caso, las dos PWA están en subdominios separados pero en el mismo dominio; en cómo los navegadores procesan eso, podría haber margen para equivocarse y confundir al navegador. Pero de nuevo, esto es solo una suposición total.
Si se trata de un enlace común (en nuestro caso es un icono de navegación en la parte superior), ¿quizás un target=_blank (o incluso target=_top?) pueda servir como solución temporal?
Por lo que recuerdo, intentamos eso, así como reemplazar HREF con una función JS que hacía ‘window.open’ y todavía el mismo resultado.
Recuerda: sí está obteniendo la página externa, por lo que el DNS a este nuevo dominio funciona bien; sin embargo, no cambia a ese dominio mientras ejecuta el script y obtiene los recursos de ruta relativa de esa página. Así que, como dije, el HREF “base” interno de Safari no se actualiza/cambia con la obtención de la página, lo que hace que se cargue en relación con el dominio “base” actual → 404.
¿Es posible cargar JS o CSS de Discourse intencionalmente?
He probado el enfoque target=_blank y todos los informes hasta ahora indican que el problema ha desaparecido. No es perfecto, pero es bueno tener una solución temporal hasta que haya más claridad al respecto.
Para que conste, esto no solo ocurre al hacer clic en un enlace iniciado por el usuario, sino también en una “redirección” de javascript.
Usamos SSO en nuestro foro y configuramos la redirección de cierre de sesión con la URL del sitio web principal. Cuando un usuario cierra sesión en el foro y Discourse lo “redirige” a nuestro sitio web principal, esto también activa el problema en Safari. Por lo que veo en la consola, no es una redirección 302 real, así que quizás sea un window.location.
Gracias por las discusiones y la depuración aquí, gente.
Esta solución alternativa es lo suficientemente simple como para probarla, así que la he añadido a este sitio (meta.discourse.org) a través de un componente temático. Si soluciona el problema, sería bastante bueno porque sospecho que puede ayudar a los desarrolladores de Webkit a depurar el problema subyacente. (E, independientemente, también podemos evaluar agregar una etiqueta base al núcleo de Discourse por defecto).
Entiendo que la solución alternativa de la etiqueta base puede ayudar cuando se aplica en un sitio externo, ya que el problema parece ocurrir después de salir de un sitio web de Discourse.
¿Se está realizando la prueba en meta para manejar el caso específico de enlaces entre dos instancias diferentes de Discourse? ¿O me he perdido en algún punto (¡bastante posible!
)?
Sí, nuestro problema más común ha sido con los enlaces entre dos instancias de Discourse. Creo que es posible que la solución alternativa de la etiqueta base también pueda ayudar si se usa en el sitio de origen (y el destino no es una instancia de Discourse). Si el problema subyacente es que Safari/Webkit están confundiendo las URL base (esto no está muy lejos de sus especulaciones sobre PWA anteriores), ¿agregar una base diferente a cualquiera de los sitios podría ayudar a romper la suposición incorrecta que está en la raíz del problema? Especulación de mi parte también, pero vale la pena intentarlo.
Buena observación, de hecho, parece que lo rompe. He deshabilitado temporalmente el componente con la etiqueta base.
Hola
No sé si es nuevo o no, pero lo probé ahora en el iPad. Noté que sucede cada vez después de cambiar de página con la navegación del navegador o el gesto de deslizar. A veces sucede en otros casos también. Es muy fácil de reproducir en la página de inicio del tema Meta Branded. Con los botones de la barra de búsqueda.
En el video, la primera vez retrocede con la navegación del navegador. La segunda vez retrocede con el gesto de deslizar. La tercera vez retrocede al hacer clic en el logo.
Wow sí, esos pasos reproducen el problema cada vez en Safari de escritorio. Bien hecho @Don ![]()
En formato de texto:
-
Abre meta.discourse.org en Safari
-
Haz clic en “Guides”
-
Regresa (usando el botón, gesto, atajo de teclado, lo que sea)
-
Haz clic en “Our Hosting”, que es un enlace a
discourse.org/pricing -
Observa la página rota.
window.locationsigue siendometa.discourse.org, pero el HTML es dediscourse.org/pricing

