Tenho que admitir que é super difícil de reproduzir! É muito inconsistente e não conseguimos encontrar um padrão.
2 curtidas
@pmusaraj pergunta rápida -
achamos que isso está relacionado ao discourse como um todo ou a um tema específico? Eu ainda não consegui identificar um componente, mas estou pensando se isso pode resolver?
Acho que não é um tema ou componente específico, provavelmente tem a ver com o Discourse como um todo. Reproduzi isso no início da semana em um site Discourse que não tinha praticamente nenhum componente instalado.
3 curtidas
Obrigado por compartilhar! Frustrante porque a experiência do usuário é terrível por causa disso e os usuários têm que recarregar a página ou voltar. Apenas tentando ser proativo sobre uma solução alternativa.
1 curtida
Isso está acontecendo com o novo subdomínio discourse discover (desktop Safari):
Parece ser aleatório quando acontece, não com frequência. Existe alguma maneira de executar um teste de diagnóstico quando isso ocorre para descobrir o problema?
4 curtidas
Com base em nossa análise até agora, o subdomínio de discurso pensa que ainda é o host e, em seguida, qualquer ativo/link relativo está quebrado. Isso significa que, a menos que você use um caminho absoluto (digamos, discourse.org/css/main.css em vez de /css/main.css), ele funcionará. Mas é uma solução alternativa bastante louca, pois isso incluiria qualquer ícone, imagem, href, js, css, etc.
1 curtida
Isso acontece tanto para Desktop quanto para mobile, apenas no Safari.
- Partes de página necessárias (domínio externo) ainda aparecem no log do Discourse, enquanto deveriam ter sido registradas no domínio externo. Não consegui depurar quando isso acontece
- Uma solução alternativa (em vez de alterar todo o CSS/JS/HREF para caminho absoluto) é colocar \\u003cbase href="https://mydomain.com/\"\\u003e no cabeçalho de todas as páginas relevantes (no domínio externo)
2 curtidas
Acabei de relatar um problema relacionado antes de ser apontado para este, que parece estar relacionado.
Acabamos de atualizar para o Discourse 3.2 há dois dias e, desde então, estamos recebendo relatos de um problema semelhante. Embora não esteja relacionado a CSS no nosso caso, acho que o problema é essencialmente o mesmo.
Após seguir um link no Discourse para o nosso site principal, o navegador ainda pensa que está no Fórum: o URL no navegador diz isso (!), e às vezes links (alguns? provavelmente relativos) abrem no domínio do fórum em vez disso, com um erro dizendo que a página do fórum não existe. Os relatos que temos até agora são todos de iPhone/iPad. Não consigo reproduzir isso de forma alguma, mas aqueles afetados parecem experimentá-lo algumas vezes por dia. Olhando nos logs do Discourse, posso confirmar que há várias requisições 404 para páginas que só existem em nosso site principal.
Estou bastante perplexo com o navegador abrindo um site e mostrando o URL de outro (sem iframes). Sendo um bug do Safari, espero que isso esteja confinado a um domínio principal, pois as implicações de segurança, de outra forma, são bastante desagradáveis.
Em qualquer caso, acho que algo a ter em mente é que isso começou a acontecer apenas depois que atualizamos para o Discourse 3.2, então algo mudou desde o 3.1 que está desencadeando isso.
Talvez um tiro no escuro, mas me pergunto se isso pode estar de alguma forma relacionado a aplicativos PWA e como eles são tratados pelo Safari? Nosso site principal declara um aplicativo PWA – e nosso fórum Discourse também. Ambos standalone e com start_url: \"/\" (o nosso define um id único, mas o Discourse não). Pelo que sei, os arquivos de manifesto PWA não especificam um nome de host específico em que operam, então assumo que ele permanece no nome de host específico em que estão hospedados. No nosso caso, os dois PWAs estão em subdomínios separados, mas no mesmo domínio; na forma como os navegadores processam isso, pode haver espaço para bagunçar as coisas e confundir o navegador. Mas, novamente, isso é apenas um palpite total.
2 curtidas
Se for de um link comum (no nosso caso, é um ícone de navegação no topo), talvez um target=_blank (ou até mesmo target=_top?) possa servir como uma solução temporária?
Pelo que me lembro, tentamos isso, bem como substituir HREF por uma função JS que executava ‘window.open’ e ainda assim o mesmo resultado.
Lembre-se: ele está buscando a página externa - então o DNS para este novo domínio funciona bem, no entanto, ele não muda para esse domínio enquanto executa o script e busca os recursos de caminho relativo dessa página. Portanto, como eu disse, o HREF “base” interno do Safari não é atualizado/alterado pela busca da página - o que faz com que ele carregue em relação ao domínio “base” atual - > 404
É possível carregar JS ou CSS do Discourse intencionalmente?
Tentei a abordagem target=_blank e todos os relatórios até agora indicam que o problema desapareceu. Não é perfeito, mas é bom ter uma solução temporária até que haja mais clareza sobre isso.
Para constar, isso não acontece apenas ao clicar em um link iniciado pelo usuário, mas também em um “redirecionamento” do JavaScript.
Usamos SSO em nosso fórum e configuramos o logout redirect com a URL do site principal. Quando um usuário sai do fórum e o Discourse os “redireciona” para o nosso site principal, isso também aciona o problema no Safari. Pelo que vi no console, não se trata de um redirecionamento 302 real, então talvez seja um window.location.
Obrigado pelas discussões e depuração aqui, pessoal.
Essa solução alternativa é simples o suficiente para experimentar, então a adicionei a este site (meta.discourse.org) por meio de um componente de tema. Se corrigir o problema, seria muito interessante, pois suspeito que possa ajudar os desenvolvedores do Webkit a depurar o problema subjacente. (E, independentemente, também podemos avaliar a adição de uma tag base ao Discourse principal por padrão.)
Meu entendimento é que a solução alternativa da tag base pode ajudar quando aplicada em um site externo, pois o problema parece ocorrer após sair de um site do Discourse.
O teste está sendo feito no meta para lidar com o caso específico de links entre duas instâncias diferentes do Discourse? Ou me perdi em algum lugar (muito possível! 
)?
1 curtida
Sim, nosso problema mais comum tem sido com links entre duas instâncias do Discourse. Acho que é possível que a solução alternativa da tag base também possa ajudar se for usada no site de origem (e o destino não for uma instância do Discourse). Se o problema subjacente for que o Safari/Webkit está confundindo as URLs base (isso não está muito longe de suas especulações sobre PWA acima), então adicionar uma base diferente a qualquer um dos sites pode ajudar a quebrar a suposição errada que está na raiz do problema? Especulação da minha parte também, mas vale a pena tentar.
1 curtida
Isso quebra o botão de DMs?
Não funcionou para mim até que eu desativei os temas usando o modo de segurança.
1 curtida
Boa observação, parece que realmente o quebra. Desabilitei o componente com a tag base temporariamente.
3 curtidas
Olá 
Não sei se é novidade ou não, mas experimentei agora o que está acontecendo no iPad. Notei que isso acontece toda vez após a mudança de página com navegação do navegador ou gesto de deslizar. Às vezes acontece em outros casos também. É muito fácil de reproduzir na página inicial do tema Meta Branded. Com os botões da barra de pesquisa.
No vídeo, a primeira vez volta com a navegação do navegador. A segunda vez volta com o gesto de deslizar. A terceira vez volta clicando no logo.
7 curtidas
Uau, sim, esses passos reproduzem o problema todas as vezes para mim no Safari do desktop. Bom trabalho, @Don 
Em formato de texto:
-
Abra meta.discourse.org no Safari
-
Clique em “Guides”
-
Volte (usando o botão, gesto, atalho de teclado, o que for)
-
Clique em “Our Hosting”, que é um link para
discourse.org/pricing -
Observe a página quebrada.
window.locationainda émeta.discourse.org, mas o HTML é dediscourse.org/pricing
9 curtidas