Troika: [troika-three-text] Problemas de carregamento do IOS Safari

Obrigado por relatar isso! Você não é o primeiro a descrever problemas como esse no iOS Safari, mas não consegui reproduzi-lo anteriormente. Vou tentar com seu site e espero conseguir reproduzi-lo.

Você está usando via drei por acaso? Ou diretamente?

Ei @lojjic estou usando este pacote diretamente com three.js. E a razão de eu ter três utils é que eu também uso sua função createDerivedMaterial em alguns casos.

Obrigado por verificar isso!

Consegui reproduzir o(s) problema(s) ao carregar seu site em um iPhone 8. Ainda não tive tempo de iniciar a depuração, mas só queria confirmar que o bug é reproduzível.

@atlmtw @lojjic Eu tive o mesmo problema no safari em um projeto que estava usando várias fontes. A única correção que encontrei foi usar uma fonte exclusiva em todo o site para este navegador.

+1
várias fontes por cena = algumas fontes nunca aparecem no iphone X, iphone SE

Estou tentando investigar esse problema e estou tendo problemas para reproduzi-lo agora. Mesmo iPhone 8 de antes. Não consigo mais reproduzi-lo em designsdalena.com, mas é possível que o site tenha mudado para não usar mais troika-three-text ou contornado de outra maneira.

Então, estou tentando criar um caso de teste mínimo usando várias fontes e não consigo fazer com que ele falhe:

https://uqgxq.csb.app/

Alguém mais é capaz de reproduzir isso em algum lugar que eu possa usar para testar/depurar?

Oi @lojjic

Para confirmar, mudei para outra coisa. Embora eu goste mais da experiência de usar a troika.

@atlmtw Obrigado pela confirmação. Suponho que você não tenha uma versão antiga do seu site no controle de origem que você possa me enviar? Estou lutando para reproduzir isso e o seu parecia uma reprodução confiável.

Oi @lojjic
Alguma sorte com isso? Também tenho visto isso quando > 1 fontes são usadas, em um iPhone (funciona no iPad e no macOS). Estranhamente, isso não é replicável o tempo todo, acontece apenas 1-2/10 vezes e apenas na primeira carga. Relacionado a downloads de arquivos de fonte, talvez?

Btw, adorei o trabalho :100:

@amitrajput1992 Não, ainda não consegui construir um caso de teste reproduzível. Você tem um que eu possa usar?

@lojjic
Tente isso ?
Se você abrir em uma área de trabalho, verá 6 textos diferentes impressos com cores diferentes.
Eu testei este link em alguns dispositivos comigo e alguns no BrowserStack, todos mostram o problema de renderização. Atualizar o link algumas vezes faz com que funcione, o que é muito estranho.

Isso é o que eu vejo no BrowserStack. Isso é no Iphone 8 + Safari v13

Este no meu iPhone 11 + Safari 14

Poderia ter algo a ver com o fato de que os arquivos de fonte são baixados no web-worker? Sabemos que o safári pode ser uma dor para os trabalhadores da web

@amitrajput1992 Obrigado, posso replicar o problema nessa página. Verei se consigo depurar a partir daí e/ou replicá-lo em um caso de teste local minimizado.

Sabemos que o safári pode ser uma dor para os trabalhadores da web

Ouvi outros dizerem isso também, e o uso de um trabalhador é definitivamente um culpado plausível, mas não consegui encontrar nenhum detalhe sobre bugs conhecidos com trabalhadores no Safari. Você tem detalhes lá que você pode compartilhar?

@lojjic
Isso soa bem. Deixe-me saber se eu puder ajudar de alguma forma. Enquanto isso, continuarei depurando e tentarei diminuir o problema do meu lado também.

Ouvi outros dizerem isso também, e o uso de um trabalhador é definitivamente um culpado plausível, mas não consegui encontrar nenhum detalhe sobre bugs conhecidos com trabalhadores no Safari. Você tem detalhes lá que você pode compartilhar?

Eu não sei sobre os problemas exatos aqui, em parte porque não consigo encontrá-los em nenhum lugar (ou as pessoas não os registram), mas isso é algo que notei enquanto mexia. O react360 anteriormente react-vr (abandonado agora) costumava executar todo o código react dentro de um web worker e as atualizações no thread principal eram muito lentas. Levaria facilmente uma ação de clique em qualquer lugar em torno de 300ms a 500ms para propagar para meu ouvinte de clique no thread de trabalho e muitas vezes também perderia alguns cliques.
Eu mantenho um repositório que é um renderizador de gif para três, tentei inicialmente com tela offscreen, mas os resultados foram horríveis e resultaram em uma mistura de texturas em quadros consecutivos. Mover a coisa toda para o thread principal melhorou drasticamente.

Eu sinto que isso pode ter algo a ver com o algoritmo de clone estruturado que é usado ao transmitir informações do trabalhador para o thread principal. Embora eu não tenha conseguido encontrar uma prova sólida sobre essa limitação no iOS

Acho que devo focar primeiro nesses artefatos, que nem sempre aparecem, mas às vezes aparecem:

Nesses casos, o layout e a geração do SDF estão obviamente completando e retornando ao thread principal, mas alguns dos SDFs parecem ter preenchimentos internos/externos invertidos em alguns lugares. Eu posso ver como isso pode acontecer se os dados do caminho para esses caracteres estiverem incompletos, como ter apenas metade de seus segmentos de caminho.

Se algo estiver acontecendo durante o carregamento da fonte em que o arraybuffer da fonte está truncado ou corrompido, acho que isso pode resultar nesse sintoma observado. Da mesma forma, também pode resultar em resultados totalmente vazios se truncado em determinados lugares.

Vou investigar isso como uma possibilidade (talvez XHR dando uma resposta parcial do arraybuffer?) mas o primeiro passo é colocar isso em um caso de teste reproduzível que eu possa modificar e executar localmente.

Isso faz sentido. corrupção arraybuffer pode ser um culpado aqui.
Eu vi outra discussão sobre fazer todo esse processo rodar no thread principal. Isso está no roteiro?

Além disso, se ajudar, estou usando troika usando drei com as versões abaixo:
@react-três/fibra: 6.2.3
@react-three/drei: 6.0.1
troika: 0,42,0
três: 0,129,0

A execução no encadeamento principal é possível, mas resultaria em uma experiência muito ruim bloqueando o encadeamento principal por potencialmente vários segundos. Isso deve ser apenas um último recurso.

Sua página de teste mudou? Parece que está usando apenas uma única fonte para todos os diferentes objetos de texto agora, pelo menos no iOS ...? Às vezes, ainda vejo SDFs ilegíveis com essa única fonte, o que implica que isso pode ser exacerbado por várias fontes, mas não se limita a isso.

Eu adicionei um fallback para dispositivos iOS para usar apenas uma única fonte para todo o aplicativo. Este é o meu env de produção, então não pode ter quebrado as coisas lá.
Vou criar outro exemplo no meu env de teste e enviar um link aqui o mais rápido possível.

É problemático descobrir que isso ainda está acontecendo com uma única fonte também :facepalm:

Hmm, na verdade, parece que só consigo fazer com que o bug ocorra com sua nova fonte única quando conectado às ferramentas de desenvolvimento do Safari, e é bastante consistente. Não tenho certeza se isso nos dá alguma pista ou não.

Bem, um pouco mais de progresso... Verifiquei que sou capaz de forçar os mesmos artefatos de glifos parciais vistos acima truncando os comandos de caminho para glifos individuais. Ainda não consegui determinar se isso é devido aos dados da fonte original estarem incompletos (acho que isso causaria apenas um glifo parcial, não muitos, por isso parece improvável) ou se algo está causando o loop for saia cedo (isso parece impossível, mas talvez haja algum bug estranho do JIT).

De qualquer forma, estou ficando preso com as ferramentas de desenvolvimento de conexão USB do Safari, que não conseguem definir pontos de interrupção no código relevante. @amitrajput1992 Seria possível obter seu aplicativo de teste como arquivos de origem que eu possa compilar/executar localmente, para que eu possa tentar trocar o código da troika para depurar?

@lojjic Embora não possa compartilhar o código do aplicativo original, deixe-me configurar um repositório de livro de histórias com uma estrutura semelhante que eu uso no meu aplicativo de produção e adicionar uma renderização de teste para isso. Em breve enviaremos o link.

@lojjic
Configurei uma reprodução básica com uma estrutura semelhante ao meu aplicativo de produção aqui: https://github.com/amitrajput1992/r3f-experiments
Posso replicar o mesmo problema com isso no meu iPhone 11 e no BrowserStack.
Também publicou o livro de histórias aqui para facilitar o acesso https://amitrajput1992.github.io/r3f-experiments

@amitrajput1992 Obrigado pelo teste! Eu posso replicá-lo lá depois de corrigir os erros CORS ao carregar as fontes do seu site gmetri, servindo-as do livro de histórias.

No entanto ... então meus devtools do Safari apenas _crashes_ completos tentando se conectar a ele! 🤦🤦🤦🤦🤦🤦 Então não consigo nem adicionar comandos console.log e vê-los. Esse bug realmente não quer ser consertado, né?

Sentindo frustrado; Vou tentar voltar a isso com uma mente mais fresca amanhã. Avise-me se você tiver algumas idéias.

Ei @lojjic , não tenho um sistema mac comigo no momento, mas testei isso no browserstack com encaminhamento local. Parece que os dados sdf registrados dentro do web-worker versus o thread principal são diferentes. Pode ser devido ao processo de serialização-desserialização entre a comunicação de thread, mas não tenho certeza. Vou continuar depurando isso ainda mais.
Você pode experimentar o crossbrowsertesting se o safari dev-tools não estiver funcionando para você, eles oferecem um teste de 100 minutos que pode ser útil.

não ser capaz de definir pontos de interrupção no código relevante

Sugestão idiota para lançar mensagem do webworker após cada linha de código e console.log, já que vocês são capazes de reproduzir bug.

Foto no meu iPhone 6/11:

Sugestão idiota para lançar mensagem do webworker após cada linha de código e console.log

Não é uma sugestão idiota! E isso é exatamente o que eu estava tentando fazer, mas o devtools do Safari trava imediatamente para mim ao apontar para uma instância editável local, então nem consigo ver a saída console.log. :(

Você está tentando abrir um URL de host local no iPhone conectado? Como funciona o encaminhamento de porta neste caso?

Você está tentando abrir um URL de host local no iPhone conectado? Como funciona o encaminhamento de porta neste caso?

Estou acessando o servidor dev do iPhone através do endereço IP da rede local. Eu também tentei canalizá-lo através de https://localhost.run. Em ambos os casos, o Safari devtools trava assim que eu o abro. A página em si renderiza bem (embora com o bug às vezes.)

Li em alguns blogs que isso pode acontecer em 2 cenários:

1. quando a bateria do telefone está em 100%
2. ao depurar via rede e não conexão a cabo

Este é um tópico de longa duração em linhas semelhantes, mas sem resolução https://developer.apple.com/forums/thread/92290

mas o devtools do Safari trava imediatamente para mim ao apontar para uma instância editável local, então nem consigo ver a saída do console.log. :(

É possível substituir a função console.log padrão por algo assim

console.log = (msg) => document.getElementById("my_ios_console").innerHTML += msg;

mas você precisa criar esse div na página html ou no script JS

<div id="my_ios_console" style="position: absolute; top:0; left: 0; background: white"></div>

isso deve mostrar todas as mensagens do console no thread principal

Obrigado @munrocket , isso pode funcionar, vou tentar.

Olá a todos,

Desculpe, estive tão longe deste tópico. Eu não sei se isso ajudaria na depuração, mas o simulador de versões recentes do Xcode 13 (em beta) conseguiu executar minhas coisas de host local 3D bem! Eu me deparei com os problemas sobre os quais vocês falaram antes, onde ele continuava travando com as versões anteriores.

@lojjic Alguma sorte com isso?

Alguma sorte com isso?

Não, infelizmente, não pude dedicar muito tempo a isso recentemente.

há alguma possibilidade de desligar os trabalhadores da web? apenas para verificar

Olá a todos,

Eu me deparei com esse mesmo problema em um projeto (para o qual não posso compartilhar código, infelizmente) e, eventualmente, encontrei o caminho para esse ticket de problema aqui. Como a última atualização foi há mais de um mês, decidi hoje mexer no código de dependência do meu projeto para identificar o que exatamente está acontecendo e quais linhas de código estão contribuindo para esse desastre de UX.

Antes de prosseguir, quero destacar que as informações e ajustes abaixo não são de forma alguma aconselhados e são compartilhados aqui apenas para ajudar na busca de uma solução real. As informações abaixo NÃO são uma solução. Voce foi avisado.

Primeiro. Sim, como mencionado anteriormente na discussão, isso parece ser culpa do WebWorker no iOS Safari em específico. Firefox (win10), Chrome (win10), Opera (win10), Safari (macOS big sur) e outros não apresentam esse problema e as fontes são carregadas corretamente 100% do tempo. O Safari (iOS), no entanto, se depara com algum tipo de condição de corrida entre vários WebWorkers (não identifiquei se isso é completamente verdade nem quais chamadas assíncronas estão interferindo umas nas outras).

Segundo. Essa suposta condição de corrida (ou o que quer que seja) está fazendo com que o buffer contendo os dados da fonte sendo carregados produza alguns valores NaN quando acessados ​​pela função readShort na dependência Typr da Troika. Então, o problema está realmente em Typr? Talvez. Eu não tenho certeza. No entanto, esses poucos valores NaN cascateiam a pilha de chamadas, arruinando literalmente tudo e, finalmente, fazendo com que o glifo seja mostrado completamente errado.

Terceiro. Depois de identificar a localização exata que eu precisava (esta função readShort em Typr/bin.s ), eu a ajustei de algumas maneiras para entender o que está acontecendo.

        readShort : function(buff, p)
    {
        //if(p>=buff.length) throw "error";
        var a = Typr._bin.t.uint8;
        a[1] = buff[p]; a[0] = buff[p+1];
        return Typr._bin.t.int16[0];
    },

Quando eu simplesmente usei um console.log(Typr._bin.t.int16[0]), o aplicativo imprimiria alguns NaN que nunca deveriam ser (cuidado ao tentar isso porque o aplicativo inteiro pode travar coisas de impressão - essa função é chamada milhares de vezes, dependendo do caso de uso). Porém, como esperado, pausar a aplicação em qualquer lugar dentro dessa função (com palavra-chave ou breakpoint do debugger ou mesmo acessando o console) faz com que o valor se corrija e não produza NaN (o que me levou a acreditar em uma race condition). Isso significa que você não pode inspecionar o problema com um depurador de maneira convencional.

Quarta e finalmente. Esta é a parte que eu desaconselho, se não com o objetivo de encontrar a solução real para este problema. Note que eu escrevi acima que se mesmo o console for usado dentro da função readShort, o NaN desaparecerá. Então, minha engenhosa mentalidade de hacker pensou na brilhante ideia de incluir este trecho antes da declaração de retorno de readShort:

if (Number.isNaN(Typr._bin.t.int16[0])) {
    console.log()
}

E funcionou! Todo o texto agora aparece bem no iOS Safari, bem como em todos os outros navegadores que testei antes. Problema resolvido~... meio que, da pior maneira possível. Acontece que a janela breve que o aplicativo cria para acessar o console resolve a suposta condição de corrida. E observe que isso só acontece quando conectado ao console.

Para concluir. É aqui que estou. A terrível solução alternativa funciona, mas ainda procuro uma solução real para isso, assim como todos aqui deveriam também. Descobriu-se que o problema pode ou não estar na Troika, já que pode estar no Typr o tempo todo, ou mesmo na implementação do WebWorker no iOS (quem sabe). De qualquer forma, espero que todas essas informações ajudem na investigação e todos nós vejamos isso até o fim.

Pilha de chamadas de referência:
Typr/bin.js - readShort
Typr/glyf.js - _parseGlyf
Typr/Typr.U.js - _drawGlyf
Typr/Typr.U.js - glyphToPath
Troika/FontParser_Typr.js - (Anônimo) forEachGlyph
Troika/FontParser_Typr.js - wrapFontObj
Troika/FontParser_Typr.js - analisar
...coisas de trabalhador

E @lojjic , sobre a solução de problemas com a depuração do iOS Safari via USB usando um MacOS Safari:
Aconselho tentar desconectar e reconectar à rede local ou ao seu telefone se o MacOS Safari DevTools insistir em carregar indefinidamente ou exibir uma mensagem dizendo que a página travou ou não está carregando scripts ou o que não. Ou isso, ou tente fechar e reabrir o DevTools algumas vezes. E, em seguida, atualizando a página da Web no telefone, obviamente. Digo isso porque isso aconteceu comigo hoje algumas vezes (dor) e resolvi dessa forma (conectando entre MacOS Big Sur e iOS 15.0.1).

OMG @malulleybovo Voltei de férias e vi suas descobertas e uau que surpresa maravilhosa! 😃 Muito obrigado por se aprofundar nisso.

Apenas saber que o readShort está produzindo NaNs é um _enorme_ passo à frente para talvez finalmente entender esse problema, que, como você sabe, eu estava totalmente preso há algum tempo. Não ajudou o fato de eu ter mudado de emprego e perdido o acesso ao dispositivo iOS que estava usando.

Minha próxima pergunta seria: podemos determinar _por que_ a leitura de Typr._bin.t.int16[0] está produzindo um NaN? Parece que deve estar recebendo um valor incorreto em um dos buffers (o buff da fonte ou o utilitário Typr._bin.t.buff ), mas ajudaria saber exatamente quais os valores de buff/uint8/int16 estão naquele momento versus o que deveriam ser.

O fato de você poder inserir o console.log() lá para evitar o bug é curioso. Não tenho certeza se isso indica uma condição de corrida, ou talvez acessar o console o tire do modo JIT. Eu esperaria pelo primeiro, pois parece mais fácil de detectar e contornar.

@lojjic parabéns pela mudança de emprego!

Acabei de pesquisar mais sobre esse problema agora e recebi notícias mais interessantes e estranhas sobre isso. Voltando ao trecho de código readShort que compartilhei antes, tentei espiar os valores do array (com buffer de array compartilhado) e encontrei a coisa mais bizarra que já vi na minha carreira de engenharia de software até agora.

        readShort : function(buff, p)
    {
        //if(p>=buff.length) throw "error";
        var a = Typr._bin.t.uint8;
        a[1] = buff[p]; a[0] = buff[p+1];
        /***** Right here, I peeked at Typr._bin.t.int16, Typr._bin.t.int8, and Typr._bin.t.uint8 ******/
        return Typr._bin.t.int16[0];
    },

Ao espiar a primeira ocorrência de NaN em readShort dentro do meu aplicativo, descobri que buff[p]=255 e buff[p+1]=6 (ambos valores uint8 válidos). Com isso em mente, dei uma olhada nos valores de Typr._bin.t.uint8 e descobri que tinha [6, 255, 0, ...] como esperado. Então eu espiei Typr._bin.t.int16 e encontrei o [NaN, 0, ...] errado em vez de [-250, 0, ...]. Por fim, dei uma espiada em Typr._bin.t.int8 e... também estava errado... era [6, NaN, 0, ...] em vez de [6, -1, 0, ...] .

A biblioteca Typr glyf usa um ArrayBuffer compartilhado em vários Arrays de tipo diferente (Uint8Array, Int8Array, Int16Array, etc.). Essa ocorrência me mostrou que no iOS Safari (somente), após alterar uma dessas matrizes, os valores das outras podem não ser atualizados imediatamente. Não faço ideia do porquê, mas encontrei um relatório de bug resolvido envolvendo ArrayBuffer no iOS Safari na história recente, o que torna isso mais crível ... .org/show_bug.cgi?id=194268)[https://bugs.webkit.org/show_bug.cgi?id=194268]).

Tendo descoberto isso, decidi tentar uma implementação alternativa da conversão (uint8,uint8) to int16 . Desta vez usando operações bit a bit. O código que usei é o seguinte:

        readShort : function(buff, p)
    {
        var a = buff[p + 1] + (buff[p] << 8);
        if (a > 0b0111111111111111) {
            a = (~a) + 1;
        }
        a = (a < 0 ? -1 : 1) * (a & 0b1111111111111111);
        return a;
    },

E aí está. Todo o texto com a fonte agora é exibido corretamente sempre (mesmo sem estar conectado ao devtools - consulte meu comentário anterior sobre o console.log para entender este aviso) Esta solução alternativa corrigiu o problema no iOS Safari (testado no iOS 15.0.2) , e continua a funcionar nos navegadores anteriores em que testei antes, como antes, como Chrome v95.0.4638.54 (win10), Firefox v93.0 (win10), Opera v80.0.4170.63 (win10) e MacOS Safari (MacOS Big Sur v11.3.1).

*Se alguém puder otimizar meu trecho de código acima, fique à vontade~

No final, parece-me que este problema não é causado pela troika. A Troika parece, de facto, sofrer as consequências de uma questão mais profunda. Então, eu pessoalmente mudaria esse problema para Typr. Mas o que eu sei... teste por si mesmo e vamos discutir se esta é realmente a raiz do problema. ;)

Acho que @malulleybovo merece um prêmio ou algo assim! 🥳

Isso é incrível, limitando-o e criando uma implementação alternativa que evita o problema! Muito obrigado!

Fico feliz em integrar sua solução readShort , como uma substituição local na troika e/ou upstream em Typr. Podemos querer implementações alternativas para os outros métodos readFoo também?

Parece que há algo errado/perigoso com o padrão typed-arrays-sharing-a-buffer em geral. É um padrão bastante curioso agora que penso nisso. Parece que DataView se destina exatamente ao propósito de ler vários formatos numéricos do binário, sem nenhuma conversão estranha de valor entre uints e números JS ou inconsistências de endianness... Será que isso também resolveria o problema? Algo assim talvez? https://gist.github.com/lojjic/94d7b5f5f374598fe0e9761be45ebb2b

Obrigado pelo elogio @lojjic~ Estou feliz por ter sido útil.

Sua solução proposta parecia promissora, então eu apenas testei e adivinhe, também funciona (em todos os navegadores que listei antes)!
Usar DataView parece ser uma maneira concisa e adequada de implementar isso em JS, se você me perguntar. Agradável.

Meu aplicativo depende do script glyf do Typr, que usa readInt8, readShort, readUshort e readBytes do Typr. Embora eu tenha incluído sua solução completa para fins de teste, eu a testei apenas nessas funções. E tudo funciona pelo que parece.

Para uma análise mais detalhada da eficácia dessa solução, eu testaria os outros cenários. Mas me faltam exemplos concretos para testá-los (além de apenas testes unitários).

Acredito que readFixed, readF2dot14, readUshorts, readUint64, readASCII, readUnicode, readUTF8, readBytes e readASCIIArray do Typr do bin.js não precisariam ser alterados, pois eles não usam diretamente os arrays tipados. Portanto, apenas as funções em sua essência precisariam ser alteradas no Typr. Além disso, junto com essa mudança, o ArrayBuffer compartilhado do Typr e os arrays tipados se tornarão obsoletos.

Se mais desenvolvedores puderem testar e aprovar isso, ficaremos ainda mais confiantes na solução. Isso ocorre porque tenho um número limitado de casos de teste e dispositivos de teste à minha disposição e há uma pequena chance de o resultado do teste ser tendencioso.

Sua solução proposta parecia promissora, então eu apenas testei e adivinhe, também funciona (em todos os navegadores que listei antes)!
Usar DataView parece ser uma maneira concisa e adequada de implementar isso em JS, se você me perguntar. Agradável.

Incrível!!! Eu mal posso acreditar. 🎉 🥳

Vou fazer mais alguns testes para ver se consigo validar as outras funções e fazer uma comparação básica de desempenho. A menos que algo desagradável apareça, eu vou ter isso integrado o mais rápido possível. Estou bastante confiante em incluir isso em uma versão de três textos da troika para que as pessoas possam experimentá-lo; a comunidade nos informará se algum problema surgir com ele. Assim que estiver um pouco solto, enviarei para Typr.

O desempenho parece comparável, até um pouco mais rápido em alguns casos. Vitória extra! 😄

Verifiquei que as outras funções também funcionam. Eu tive que modificar um pouco o auxiliar _view para lidar com casos em fontes CFF onde Typr passa buff como um array JS simples em vez de um Uint8Array.

Publiquei a versão de três testes da troika 0.43.1-alpha.0 com a correção do DataView (atualmente usando um fork privado de Typr - commit relevante )

Qualquer um que seja capaz (@amitrajput1992? @strangerintheq? @atlmtw?), gostaria muito de testar com esta versão para verificar se ela corrige o problema em seus aplicativos específicos. Vou tentar fazer o mesmo com o Browserstack ou encontrar um iPhone para emprestar. Desde já, obrigado!

Ei @lojjic , ​​é bom saber que há uma correção para isso. Deixe-me testar isso rapidamente e voltar para você.

@amitrajput1992 Oi, você já teve a chance de testar o alfa? Eu quero que isso seja lançado e adoraria a validação extra. :)

@lojjic Ei, acabei de ter tempo para testar isso. Parece que agora está funcionando!!

Confira as mudanças aqui: https://amitrajput1992.github.io/r3f-experiments/?path=/story/testers --text-tester

Eu lancei a versão 0.44.0 com a correção para esse bug desagradável. Estou tão feliz por finalmente ter isso corrigido! Obrigado a todos pela ajuda, e especialmente @malulleybovo por cavar fundo onde não consegui e encontrar a causa raiz. Eu sou muito grato! 🥳