Troika: [troika-tres-texto] Problemas de carga de IOS Safari

¡Gracias por informar esto! No eres el primero en describir problemas como este en iOS Safari, pero no pude reproducirlo anteriormente. Probaré con su sitio y espero poder reproducirlo.

¿Lo estás usando a través drei por casualidad? ¿O directamente?

Hola @lojjic , ​​estoy usando este paquete directamente con three.js. Y la razón por la que tengo tres utilidades es que también uso su función createDerivedMaterial en algunos casos.

¡Gracias por comprobar esto!

Pude reproducir los problemas al cargar su sitio web en un iPhone 8. Todavía no he tenido tiempo de comenzar a depurar, pero solo quería reconocer que el error es reproducible.

@atlmtw @lojjic Tuve el mismo problema en un safari en un proyecto que usaba varias fuentes. La única solución que encontré fue usar una fuente única en todo el sitio web para este navegador.

+1
múltiples fuentes por escena = algunas fuentes nunca aparecen en iPhone X, iPhone SE

Estoy tratando de profundizar en este problema y tengo problemas para reproducirlo ahora. Mismo iPhone 8 que antes. Ya no puedo reproducirlo en designsdalena.com, pero es posible que el sitio haya cambiado para que ya no use troika-tres-texto o solucionado de otra manera.

Así que estoy tratando de crear un caso de prueba mínimo usando varias fuentes, y no puedo hacer que falle:

https://uqgxq.csb.app/

¿Alguien más puede reproducir esto en algún lugar que pueda usar para probar/depurar?

Hola @lojjic

Para confirmar, cambié a otra cosa. Aunque disfruto más la experiencia de usar troika.

@atlmtw Gracias por la confirmación. ¿Supongo que no tiene una versión anterior de su sitio en control de código fuente que podría enviarme? Estoy luchando por reproducir esto y el tuyo parecía una reproducción confiable.

Hola @lojjic
¿Ha habido suerte con esto? También he visto esto cuando se usan > 1 fuentes, en un iPhone (funciona en iPad y macOS). Extrañamente, esto no es replicable todo el tiempo, sucede solo 1-2/10 veces y solo en la primera carga. ¿Quizás relacionado con las descargas de archivos de fuentes?

Por cierto, me encanta el trabajo :100:

@ amitrajput1992 No, todavía no he podido construir un caso de prueba reproducible. ¿Tienes uno que pueda usar?

@lojjic
¿Intentar esto ?
Si abre en un escritorio, debería ver 6 textos diferentes impresos con diferentes colores.
Probé este enlace en algunos dispositivos conmigo y algunos en BrowserStack, todos muestran el problema de renderizado. Actualizar el enlace varias veces hace que funcione, lo cual es muy extraño.

Esto es lo que veo en BrowserStack. Esto es en Iphone 8 + Safari v13

Este en mi iPhone 11 + Safari 14

¿Podría tener algo que ver con el hecho de que los archivos de fuentes se descargan en el trabajador web? Sabemos que el safari puede ser un fastidio con los trabajadores web

@ amitrajput1992 Gracias, de hecho puedo replicar el problema en esa página. Veré si puedo depurar desde allí y/o replicarlo en un caso de prueba local minimizado.

Sabemos que el safari puede ser un fastidio con los trabajadores web

También escuché a otros decir esto, y el uso de un trabajador es definitivamente un culpable plausible, pero no he podido encontrar ningún detalle sobre errores conocidos con trabajadores en Safari. ¿Tienes detalles allí que puedas compartir?

@lojjic
Eso suena bien. Déjame saber si puedo ayudar de alguna manera. Mientras tanto, seguiré depurando e intentaré reducir el problema por mi parte también.

También escuché a otros decir esto, y el uso de un trabajador es definitivamente un culpable plausible, pero no he podido encontrar ningún detalle sobre errores conocidos con trabajadores en Safari. ¿Tienes detalles allí que puedas compartir?

No conozco los problemas exactos aquí, en parte porque no puedo encontrarlos en ninguna parte (o la gente no los registra), pero esto es algo que noté mientras jugueteaba. react360 anteriormente react-vr (abandonado ahora) solía ejecutar todo el código de reacción dentro de un trabajador web y las actualizaciones del hilo principal eran demasiado lentas. Tomaría fácilmente una acción de clic en cualquier lugar alrededor de 300ms a 500ms para propagarse a mi oyente de clics en el subproceso de trabajo y, a menudo, también perdería algunos clics.
Mantengo un repositorio que es un renderizador de gif para tres, probé inicialmente con un lienzo fuera de la pantalla, pero los resultados fueron horribles y resultaron en una combinación de texturas en fotogramas consecutivos. Mover todo al hilo principal lo mejoró drásticamente.

Siento que esto podría tener algo que ver con el algoritmo de clonación estructurada que se usa cuando se transmite información del trabajador al hilo principal. Aunque no he podido encontrar una prueba sólida sobre esta limitación en iOS

Creo que primero debería centrarme en estos artefactos, que no siempre aparecen pero a veces sí:

En esos casos, el diseño y la generación de SDF obviamente se completan y regresan al subproceso principal, pero algunos de los SDF parecen tener rellenos internos/externos invertidos en algunos lugares. Puedo ver cómo podría suceder eso si los datos de ruta para esos caracteres están incompletos, como si solo tuvieran la mitad de sus segmentos de ruta.

Si sucede algo durante la carga de la fuente donde el búfer de matriz de la fuente está truncado o dañado, creo que eso podría resultar en este síntoma observado. Del mismo modo, también podría dar como resultado resultados totalmente vacíos si se trunca en ciertos lugares.

Lo investigaré como una posibilidad (¿quizás XHR dando una respuesta parcial de arraybuffer?), pero el primer paso es convertir esto en un caso de prueba reproducible que pueda modificar y ejecutar localmente.

Eso tiene sentido. La corrupción de arraybuffer podría ser un culpable aquí.
Vi otra discusión sobre cómo hacer que todo este proceso se ejecute en el hilo principal. ¿Está eso en la hoja de ruta?

Además, si ayuda, estoy usando troika usando drei con las siguientes versiones:
@react-tres/fibra: 6.2.3
@react-tres/drei: 6.0.1
troika: 0.42.0
tres: 0.129.0

Es posible ejecutar en el hilo principal, pero resultaría en una experiencia bastante mala al bloquear el hilo principal durante potencialmente varios segundos. Eso debería ser solo un último recurso.

¿Ha cambiado su página de prueba? Parece que ahora solo está usando una sola fuente para todos los diferentes objetos de texto, al menos en iOS... Sin embargo, todavía veo SDF distorsionados con esa fuente única a veces, lo que implica que esto puede verse exacerbado por múltiples fuentes, pero no se limita a eso.

Agregué una alternativa para que los dispositivos iOS usen solo una fuente para toda la aplicación. Este es mi entorno de producción, por lo que no puede haber roto cosas allí.
Crearé otro ejemplo en mi entorno de ensayo y enviaré un enlace aquí lo antes posible.

Es problemático descubrir que esto todavía sucede con una sola fuente también :facepalm:

Hmm, en realidad parece que solo puedo hacer que ocurra el error con su nueva fuente única cuando está conectado a las herramientas de desarrollo de Safari, y entonces tiene errores bastante consistentes. No estoy seguro si eso nos da alguna pista o no.

Bueno, un poco más de progreso... He verificado que puedo forzar los mismos artefactos de glifos parciales que se ven arriba al truncar los comandos de ruta para glifos individuales. Todavía no he podido determinar si eso se debe a que los datos de la fuente original están incompletos (creo que eso causaría solo un glifo parcial, no muchos, por lo que parece poco probable), o si algo está causando que los bucles for salga temprano (esto parece imposible, pero tal vez haya algún error JIT extraño).

De cualquier manera, me estoy quedando atascado con las herramientas de desarrollo de conexión USB de Safari que no pueden establecer puntos de interrupción en el código relevante. @ amitrajput1992 ¿Sería posible obtener su aplicación de prueba como archivos de origen que puedo compilar/ejecutar localmente, de modo que pueda intentar intercambiar el código troika para depurar?

@lojjic Si bien no podré compartir el código de la aplicación original, permítanme configurar un repositorio de libro de cuentos con una estructura similar a la que uso en mi aplicación de producción y agregar una representación de prueba para esto. Enviaré el enlace en breve.

@lojjic
He configurado una reproducción básica con una estructura similar a la de mi aplicación de producción aquí: https://github.com/amitrajput1992/r3f-experiments
Puedo replicar el mismo problema con esto en mi iPhone 11 y en BrowserStack.
También publicó el libro de cuentos aquí para un fácil acceso https://amitrajput1992.github.io/r3f-experiments

@ amitrajput1992 ¡ Gracias por el caso de prueba! Puedo replicarlo allí después de corregir los errores de CORS al cargar las fuentes desde su sitio gmetri sirviéndolas desde el libro de cuentos.

Sin embargo... entonces mis devtools de Safari simplemente _fallan_ al intentar conectarse a él. 🤦🤦🤦🤦🤦🤦 Así que ni siquiera puedo agregar declaraciones de console.log y verlas. Este error realmente no quiere arreglarse, ¿eh?

Sintiendome frustrado; Intentaré volver a esto con una mente más fresca mañana. Avísame si tienes alguna idea.

Hola, @lojjic , ​​no tengo un sistema mac conmigo en este momento, pero probé esto en browserstack con reenvío local. Parece que los datos sdf registrados dentro del web-worker frente al hilo principal son diferentes. Podría deberse al proceso de serialización-deserialización entre la comunicación de subprocesos, pero no del todo seguro. Seguiré depurando esto más.
Puede probar la prueba de navegador cruzado si las herramientas de desarrollo de Safari no funcionan para usted, ofrecen una prueba de 100 minutos que podría ser útil.

no poder establecer puntos de interrupción en el código relevante

Sugerencia tonta para lanzar un mensaje de webworker después de cada línea de código y consola. Regístrelo, ya que ustedes pueden reproducir el error.

Imagen en mi iPhone 6/11:

Sugerencia tonta para lanzar un mensaje del trabajador web después de cada línea de código y consola. Regístrelo

¡No es una sugerencia tonta en absoluto! Y eso es exactamente lo que estaba tratando de hacer, pero las herramientas de desarrollo de Safari se bloquean de inmediato cuando apunto a una instancia editable local, por lo que ni siquiera puedo ver la salida de console.log. :(

¿Estás tratando de abrir una URL de localhost en el iPhone conectado? ¿Cómo funciona el reenvío de puertos en este caso?

¿Estás tratando de abrir una URL de localhost en el iPhone conectado? ¿Cómo funciona el reenvío de puertos en este caso?

Estoy accediendo al servidor de desarrollo desde el iPhone a través de la dirección IP de la red local. También intenté canalizarlo a través de https://localhost.run. En ambos casos, Safari devtools falla tan pronto como lo abro. La página en sí se muestra bien (aunque a veces con el error).

Leí en algunos blogs que esto puede suceder en 2 escenarios:

1. cuando la batería del teléfono está al 100%
2. al depurar a través de la red y no de la conexión por cable

Este es un hilo de larga duración en líneas similares, pero sin resolución https://developer.apple.com/forums/thread/92290

pero las herramientas de desarrollo de Safari se bloquean de inmediato cuando apunto a una instancia editable local, por lo que ni siquiera puedo ver la salida de console.log. :(

Es posible sustituir la función por defecto console.log con algo como esto

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

pero necesita crear ese div en la página html o desde el script JS

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

esto debería mostrar todos los mensajes de la consola en el hilo principal

Gracias @munrocket , eso podría funcionar, lo intentaré.

Oigan todos,

Lo siento, he estado tan lejos de este hilo. ¡No sé si esto ayudaría con la depuración, pero el simulador de versiones recientes de Xcode 13 (en beta) ha podido ejecutar mis cosas de localhost 3D bien! Me encontré con los problemas de los que hablaron antes donde seguía fallando con versiones anteriores.

@lojjic ¿Tuviste suerte con esto?

¿Ha habido suerte con esto?

No, desafortunadamente, no he podido dedicar mucho tiempo a esto recientemente.

¿Hay alguna posibilidad de desactivar los trabajadores web? solo para comprobar

Hola, todos,

Me encontré con este mismo problema en un proyecto (para el cual lamentablemente no puedo compartir el código) y finalmente encontré mi camino hacia este ticket de problema aquí. Dado que la última actualización sobre esto fue hace más de un mes, hoy decidí jugar con el código de dependencia de mi proyecto para, con suerte, identificar qué está sucediendo exactamente y qué líneas de código están contribuyendo a este desastre de UX.

Antes de continuar, quiero resaltar que la información y los ajustes a continuación no se recomiendan de ninguna manera, y se comparten aquí únicamente para ayudar en la búsqueda de una solución real. La siguiente información NO es una solución. Has sido advertido.

Primero. Sí, como se mencionó anteriormente en la discusión, esto parece ser culpa específica de WebWorker en iOS Safari. Firefox (win10), Chrome (win10), Opera (win10), Safari (macOS big sur) y otros no presentan este problema y las fuentes se cargan correctamente el 100 % del tiempo. Safari (iOS), sin embargo, se encuentra con algún tipo de condición de carrera entre varios WebWorkers (no he identificado si esto es completamente cierto ni qué llamadas asincrónicas interfieren entre sí).

Segundo. Esta supuesta condición de carrera (o lo que sea) está causando que el búfer que contiene los datos de la fuente que se está cargando produzca algunos valores NaN cuando se accede a través de la función readShort en la dependencia Typr de Troika. Entonces, ¿el problema está realmente en Typr? Quizás. No estoy seguro. Sin embargo, estos pocos valores de NaN caen en cascada en la pila de llamadas arruinando literalmente todo y finalmente causando que el glifo se muestre completamente incorrecto.

Tercera. Después de identificar la ubicación exacta que necesitaba (esta función readShort en Typr/bin.s ), la modifiqué de varias maneras para comprender lo que estaba sucediendo.

        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];
    },

Cuando simplemente usé un archivo console.log(Typr._bin.t.int16[0]), la aplicación imprimía algunos NaN que nunca deberían ser (cuidado al probar esto porque toda la aplicación puede colgar cosas de impresión; esta función se llama miles de veces dependiendo del caso de uso). Sin embargo, como era de esperar, pausar la aplicación en cualquier lugar dentro de esta función (con la palabra clave del depurador o punto de interrupción o incluso acceder a la consola) hace que el valor se corrija solo y no produzca NaN (lo que me llevó a creer en una condición de carrera). Eso significa que no puede inspeccionar el problema con un depurador de manera convencional.

Cuarto y último. Esta es la parte que desaconsejo si no es con el propósito de encontrar la solución real a este problema. Tenga en cuenta que escribí anteriormente que si incluso la consola se usa dentro de la función readShort, el NaN desaparece. Así que mi ingeniosa mentalidad de hacker pensó en la brillante idea de incluir este fragmento antes de la declaración de retorno de readShort:

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

¡Y funcionó! Todo el texto ahora se muestra bien en iOS Safari, así como en todos los demás navegadores que probé antes. Problema resuelto~... más o menos, de la peor manera posible. Resulta que la breve ventana que crea la aplicación para acceder a la consola resuelve la supuesta condición de carrera. Y ten en cuenta que solo lo hace cuando está conectado a la consola.

En conclusión. Aquí es donde estoy. La terrible solución funciona, pero aún busco una solución real para esto, tal como todos aquí también deberían hacerlo. Resultó que el problema puede o no estar en Troika, ya que puede haber estado en Typr todo el tiempo, o incluso en la implementación de WebWorker en iOS (quién sabe). En cualquier caso, espero que toda esta información ayude en la investigación y todos lleguemos hasta el final.

Pila de llamadas de referencia:
Typr/bin.js - lectura corta
Typr/glyf.js - _parseGlyf
Typr/Typr.U.js - _drawGlyf
Typr/Typr.U.js - glyphToPath
Troika/FontParser_Typr.js - (Anónimo) para cada glifo
Troika/FontParser_Typr.js - wrapFontObj
Troika/FontParser_Typr.js - analizar
... cosas de los trabajadores

Y @lojjic , ​​con respecto a la solución de problemas con la depuración de iOS Safari a través de USB usando MacOS Safari:
Aconsejo intentar desconectarse y volver a conectarse a la red local o a su teléfono si MacOS Safari DevTools insiste en cargar indefinidamente o muestra un mensaje que dice que la página se bloqueó o que no carga los scripts o lo que sea. O eso, o intente cerrar y volver a abrir DevTools varias veces. Y luego, obviamente, actualizar la página web en el teléfono. Digo esto porque hoy me pasó un par de veces (dolor) y lo resolví de esa manera (conectando entre MacOS Big Sur e iOS 15.0.1).

OMG @malulleybovo Regresé de vacaciones y vi tus hallazgos y ¡guau, fue una sorpresa maravillosa! 😃 Muchas gracias por profundizar en esto.

El solo hecho de saber que readShort está produciendo NaN es un _enorme_ paso adelante para quizás finalmente comprender este problema, que, como saben, me había atascado por completo durante bastante tiempo. No ayudó que cambié de trabajo y perdí el acceso al dispositivo iOS que estaba usando.

Mi próxima pregunta sería ¿podemos determinar _por qué_ la lectura Typr._bin.t.int16[0] está produciendo un NaN? Parece que debe estar obteniendo un valor incorrecto en uno de los búferes (ya sea buff de la fuente o buff Typr._bin.t.buff la utilidad), pero ayudaría saber exactamente qué valores tiene buff/uint8/int16 están en ese momento versus lo que deberían ser.

El hecho de que pueda insertar el archivo console.log() allí para evitar el error es curioso. No estoy seguro si eso indica una condición de carrera, o tal vez acceder a la consola lo saca del modo JIT. Esperaría lo primero, ya que suena más fácil de detectar y solucionar.

@lojjic felicidades por el cambio de trabajo!

Acabo de profundizar un poco más en este tema en este momento y obtuve noticias más interesantes y extrañas sobre esto. Volviendo al fragmento de código readShort que compartí antes, intenté echar un vistazo a los valores de la matriz (con el búfer de matriz compartido) y encontré la cosa más extraña que he visto en mi carrera de ingeniería de software hasta ahora.

        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];
    },

Mientras miraba la primera aparición de NaN en readShort dentro de mi aplicación, descubrí que buff[p]=255 y buff[p+1]=6 (ambos valores uint8 válidos). Con eso en mente, miré los valores de Typr._bin.t.uint8 y descubrí que tenía [6, 255, 0, ...] como se esperaba. Luego eché un vistazo a Typr._bin.t.int16 y encontré el erróneo [NaN, 0, ...] en lugar de [-250, 0, ...]. Por último, eché un vistazo a Typr._bin.t.int8 y... también estaba mal... era [6, NaN, 0, ...] en lugar de [6, -1, 0, ...] .

La biblioteca Typr glyf usa un ArrayBuffer compartido en varios Arrays de diferentes tipos (Uint8Array, Int8Array, Int16Array, etc.). Esta ocurrencia me mostró que en iOS Safari (solo), después de modificar una de estas matrices, es posible que los valores de las otras no se actualicen de inmediato. No tengo idea de por qué, pero encontré un informe de error resuelto que involucra a ArrayBuffer en iOS Safari en la historia reciente, lo que hace que esto sea más creíble... se demostró que tiene fallas una vez, bien puede tener fallas dos veces (ref: (https://bugs.webkit .org/show_bug.cgi?id=194268)[https://bugs.webkit.org/show_bug.cgi?id=194268]).

Habiendo descubierto esto, decidí probar una implementación alternativa de la conversión (uint8,uint8) to int16 . Esta vez usando operaciones bit a bit. El código que utilicé es el siguiente:

        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;
    },

Y ahí lo tienes. Todo el texto con la fuente ahora se muestra correctamente siempre (incluso sin estar conectado a devtools; consulte mi comentario anterior sobre el elemento console.log para comprender este descargo de responsabilidad) Esta solución alternativa solucionó el problema en iOS Safari (probado en iOS 15.0.2) , y continúa funcionando en los navegadores anteriores que probé antes, como Chrome v95.0.4638.54 (win10), Firefox v93.0 (win10), Opera v80.0.4170.63 (win10) y Mac OS Safari (Mac OS Big Sur v11.3.1).

*Si alguien puede optimizar mi fragmento de código anterior, no dude en hacerlo~

Al final, me parece que este problema no es causado por la troika. De hecho, la troika parece estar sufriendo las consecuencias de un problema más profundo. Así que personalmente trasladaría este problema a Typr. Pero qué se yo... pruébenlo ustedes mismos y discutamos si esta es realmente la raíz del problema. ;)

¡Creo que @malulleybovo merece un premio o algo así! 🥳

¡Esto es increíble, reducirlo y proponer una implementación alternativa que evita el problema! ¡Muchas gracias!

Estoy feliz de integrar su solución readShort , como una anulación local en troika y/o upstream en Typr. ¿Podríamos querer implementaciones alternativas para los otros métodos readFoo también?

Parece que hay algo malo/peligroso con el patrón typed-arrays-sharing-a-buffer en general. Es un patrón bastante curioso ahora que lo pienso. Parece que DataView tiene exactamente el propósito de leer varios formatos de números binarios, sin ninguna conversión de valor extraño entre uints y números JS o inconsistencias endianness... Me pregunto si eso también resolvería el problema. ¿Algo como esto tal vez? https://gist.github.com/lojjic/94d7b5f5f374598fe0e9761be45ebb2b

Gracias por el cumplido @lojjic~ Me alegro de haber sido útil.

Su solución propuesta parecía prometedora, así que la probé y adivinen qué, ¡también funciona (en todos los navegadores que mencioné antes)!
Usar DataView parece una forma concisa y adecuada de implementar esto en JS si me preguntas. Bonita.

Mi aplicación depende del script glyf de Typr, que utiliza readInt8, readShort, readUshort y readBytes de Typr. Aunque he incluido su solución completa con fines de prueba, solo la he probado en estas funciones. Y todo funciona por lo que parece.

Para una mirada más profunda a la efectividad de esta solución, probaría los otros escenarios. Pero me faltan ejemplos concretos para probarlos (además de las pruebas unitarias).

Creo que readFixed, readF2dot14, readUshorts, readUint64, readASCII, readUnicode, readUTF8, readBytes y readASCIIArray de bin.js de Typr no deberían cambiarse, ya que no usan directamente las matrices escritas. Por lo tanto, solo las funciones en su esencia tendrían que modificarse dentro de Typr. Además, junto con este cambio, el ArrayBuffer compartido de Typr y las matrices escritas quedarán obsoletas.

Si más desarrolladores pueden probar y aprobar esto, tendremos aún más confianza en la solución. Esto se debe a que tengo un número limitado de casos de prueba y dispositivos de prueba a mi disposición y existe una pequeña posibilidad de que el resultado de la prueba esté sesgado.

Su solución propuesta parecía prometedora, así que la probé y adivinen qué, ¡también funciona (en todos los navegadores que mencioné antes)!
Usar DataView parece una forma concisa y adecuada de implementar esto en JS si me preguntas. Bonita.

¡¡¡Asombroso!!! Casi no puedo creerlo. 🎉 🥳

Probaré esto un poco más para ver si puedo validar las otras funciones y hacer una comparación básica de rendimiento. A menos que surja algo desagradable, lo integraré lo antes posible. Estoy bastante seguro de incluir esto en un lanzamiento de tres textos de la troika para que la gente pueda probarlo; la comunidad nos informará si surge algún problema. Una vez que haya estado un poco en libertad, lo enviaré a Typr.

El rendimiento parece comparable, incluso un poco más rápido en algunos casos. ¡Ganancia adicional! 😄

He verificado que las otras funciones también funcionan. Tuve que modificar ligeramente el ayudante _view para manejar casos en fuentes CFF donde Typr pasa buff como una matriz JS simple en lugar de Uint8Array.

He publicado la versión de troika-tres-pruebas 0.43.1-alpha.0 con la corrección de DataView (actualmente usando una bifurcación privada de Typr - compromiso relevante )

Cualquiera que pueda (@amitrajput1992? @strangerintheq? @atlmtw?), agradecería mucho probar con esta versión para verificar que soluciona el problema en sus aplicaciones específicas. Intentaré hacer lo mismo con Browserstack o buscando un iPhone para pedir prestado. ¡Gracias por adelantado!

Hola, @lojjic , ​​es bueno saber que hay una solución para esto. Déjame probar esto rápidamente y te responderé.

@amitrajput1992 Hola, ¿ya tuviste la oportunidad de probar el alfa? Quiero que se publique esto y me encantaría la validación adicional. :)

@lojjic Hola, acabo de tener tiempo para probar esto. ¡¡Parece que ya está funcionando!!

Consulte los cambios aquí: https://amitrajput1992.github.io/r3f-experiments/?path=/story/testers --text-tester

Lancé la versión 0.44.0 con la corrección de este desagradable error. ¡Estoy tan feliz de finalmente tener esto arreglado! Gracias a todos por la ayuda, y especialmente a @malulleybovo por profundizar donde no pude y encontrar la causa raíz. ¡Estoy muy agradecido! 🥳