Troika: [troika-three-text] Проблемы с загрузкой IOS Safari

Спасибо, что сообщили об этом! Вы не первый, кто описывает подобные проблемы в iOS Safari, но раньше мне не удавалось воспроизвести это. Я попробую с вашим сайтом, и, надеюсь, я смогу воспроизвести его.

Вы случайно не используете его через drei ? Или напрямую?

Привет , @lojjic , ​​я использую этот пакет напрямую с three.js. И причина, по которой у меня есть three-utils, заключается в том, что в некоторых случаях я также использую вашу функцию createDerivedMaterial.

Спасибо, что проверили это!

Мне удалось воспроизвести проблемы с загрузкой вашего веб-сайта на iPhone 8. У меня еще не было времени начать отладку, но я просто хотел признать, что ошибка воспроизводима.

@atlmtw @lojjic У меня была такая же проблема с сафари в проекте, в котором использовалось несколько шрифтов. Единственным исправлением, которое я нашел, было использование уникального шрифта на всем веб-сайте для этого браузера.

+1
несколько шрифтов на сцену = некоторые шрифты никогда не появляются на iphone X, iphone SE

Я пытаюсь разобраться в этой проблеме, и у меня возникли проблемы с ее воспроизведением сейчас. Тот же iPhone 8, что и раньше. Я больше не могу воспроизвести его на designdalena.com, но, возможно, сайт изменился и больше не использует troika-three-text или обошел его по-другому.

Итак, я пытаюсь создать минимальный тестовый пример с использованием нескольких шрифтов и не могу заставить его потерпеть неудачу:

https://uqgxq.csb.app/

Кто-нибудь еще может воспроизвести это где-нибудь, что я мог бы использовать для тестирования/отладки?

Привет @lojjic

Чтобы подтвердить, я переключился на что-то другое. Хотя мне больше нравится опыт использования тройки.

@atlmtw Спасибо за подтверждение. Я не думаю, что у вас есть старая версия вашего сайта в системе контроля версий, которую вы могли бы отправить мне? Я изо всех сил пытаюсь воспроизвести это, и ваша реплика показалась надежной.

Привет @lojjic
Удачи с этим? Я тоже видел это, когда использовалось > 1 шрифта на iPhone (работает на iPad и macOS). Как ни странно, это не повторяется постоянно, происходит только 1-2/10 раз и только при 1-й загрузке. Возможно, связано с загрузкой файлов шрифтов?

Кстати, работа нравится :100:

@ amitrajput1992 Нет, я до сих пор не смог создать воспроизводимый тестовый пример. У вас есть один, который я мог бы использовать?

@lojjic
Попробуйте это ?
Если вы откроете на рабочем столе, вы должны увидеть 6 разных текстов, напечатанных разными цветами.
Я протестировал эту ссылку на нескольких устройствах со мной и на нескольких в BrowserStack, и все они показывают проблему с рендерингом. Обновление ссылки несколько раз заставляет ее работать, что очень странно.

Это то, что я вижу в BrowserStack. Это на Iphone 8 + Safari v13

Это на моем iPhone 11 + Safari 14

Может ли это быть связано с тем, что файлы шрифтов загружаются в веб-воркере? Мы знаем, что сафари может быть проблемой для веб-воркеров.

@amitrajput1992 @amitrajput1992 Спасибо, я действительно могу воспроизвести проблему на этой странице. Я посмотрю, смогу ли я отладить оттуда и/или воспроизвести его в свернутом локальном тестовом примере.

Мы знаем, что сафари может быть проблемой для веб-воркеров.

Я слышал, что другие тоже говорят об этом, и использование рабочего процесса определенно является вероятным виновником, но я не смог найти никаких подробностей об известных ошибках с рабочими процессами в Safari. У вас есть конкретика, которой вы можете поделиться?

@lojjic
Это звучит неплохо. Дайте мне знать, если я могу помочь в любом случае. Тем временем я продолжу отладку и попытаюсь сузить проблему и со своей стороны.

Я слышал, что другие тоже говорят об этом, и использование рабочего процесса определенно является вероятным виновником, но я не смог найти никаких подробностей об известных ошибках с рабочими процессами в Safari. У вас есть конкретика, которой вы можете поделиться?

Я не знаю о точных проблемах здесь, отчасти потому, что я нигде не могу их найти (или люди не регистрируют их), но это то, что я заметил, когда возился. react360 ранее react-vr (теперь заброшенный) использовался для запуска всего кода реакции внутри веб-воркера, и обновления основного потока были чертовски медленными. Для распространения на мой прослушиватель кликов в рабочем потоке легко потребовалось бы действие щелчка где-то от 300 мс до 500 мс, и часто также пропускалось бы несколько кликов.
Я поддерживаю репозиторий, который представляет собой средство рендеринга gif для трех, первоначально пробовал с закадровым холстом, но результаты были ужасными и приводили к смешиванию текстур в последовательных кадрах. Перемещение всего этого в основной поток значительно улучшило его.

Я чувствую, что это может быть как-то связано со структурированным алгоритмом клонирования, который используется при передаче информации от работника к основному потоку. Хотя мне не удалось найти убедительных доказательств этого ограничения на iOS.

Я думаю, что мне следует сначала сосредоточиться на этих артефактах, которые не всегда появляются, но иногда появляются:

В этих случаях макет и генерация SDF, очевидно, завершаются и возвращаются в основной поток, но некоторые из SDF, по-видимому, имеют местами перепутанные внутренние и внешние заливки. Я вижу, как это может произойти, если данные пути для этих символов неполные, например, только половина его сегментов пути.

Если что-то происходит во время загрузки шрифта, когда буфер массива шрифта усекается или повреждается, я думаю, что это может привести к этому наблюдаемому симптому. Точно так же это может также привести к совершенно пустым результатам, если оно будет усечено в определенных местах.

Я рассмотрю эту возможность (может быть, XHR дает частичный ответ буфера массива?), но первый шаг — превратить это в воспроизводимый тестовый пример, который я могу изменить и запустить локально.

В этом есть смысл. Причиной может быть повреждение массива буфера.
Я видел еще одно обсуждение о том, чтобы весь этот процесс выполнялся в основном потоке. Это есть в дорожной карте?

Кроме того, если это поможет, я использую troika с использованием drei со следующими версиями:
@реагировать-три/волокно: 6.2.3
@react-three/drei: 6.0.1
тройка: 0.42.0
три: 0,129,0

Запуск в основном потоке возможен, но это приведет к довольно дерьмовой блокировке основного потока на несколько секунд. Это должно быть только последним средством.

Изменилась ли ваша тестовая страница? Кажется, что теперь для всех различных текстовых объектов используется только один шрифт, по крайней мере, на iOS...? Тем не менее, я все еще иногда вижу искаженные файлы SDF с одним шрифтом, что означает, что это может усугубляться несколькими шрифтами, но не ограничивается этим.

Я добавил запасной вариант для устройств iOS, чтобы использовать только один шрифт для всего приложения. Это моя производственная среда, поэтому я не могу ничего там сломать.
Я создам еще один пример в своей тестовой среде и отправлю ссылку сюда как можно скорее.

Трудно обнаружить, что это все еще происходит и с одним шрифтом :facepalm:

Хм, на самом деле кажется, что я могу получить ошибку только с вашим новым одиночным шрифтом при подключении к Safari devtools, и тогда он довольно постоянно глючит. Не уверен, дает ли это нам какую-либо подсказку или нет.

Что ж, еще немного прогресса... Я убедился, что могу вызвать те же частичные артефакты глифов, что и выше, усекая команды пути для отдельных глифов. Я еще не смог определить, связано ли это с тем, что исходные данные шрифта были неполными (я думаю, что это вызовет только один частичный глиф, а не много, так что это маловероятно), или что-то вызывает циклы for выйти раньше (это кажется невозможным, но, возможно, есть какая-то странная ошибка JIT).

В любом случае, я застрял с инструментами разработчика USB-подключения Safari, которые не могут установить точки останова в соответствующем коде. @amitrajput1992 amitrajput1992 Можно ли вообще получить ваше тестовое приложение в виде исходных файлов, которые я могу собрать/запустить локально, чтобы попытаться заменить код тройки для отладки?

@lojjic Хотя я не смогу поделиться исходным кодом приложения, позвольте мне настроить репозиторий сборника рассказов с аналогичной структурой, которую я использую в своем рабочем приложении, и добавить для этого тестовый рендеринг. Скоро пришлю ссылку.

@lojjic
Я настроил базовое воспроизведение с аналогичной структурой, как и мое производственное приложение, здесь: https://github.com/amitrajput1992/r3f-experiments .
Я могу воспроизвести ту же проблему на своем iPhone 11 и в BrowserStack.
Также опубликован сборник рассказов здесь для легкого доступа https://amitrajput1992.github.io/r3f-experiments

@amitrajput1992 Спасибо за пример! Я могу воспроизвести его там после исправления ошибок CORS при загрузке шрифтов с вашего сайта gmetri, предоставив их из сборника рассказов.

Однако... тогда мой Safari devtools просто полностью _вылетает_, пытаясь подключиться к нему! 🤦🤦🤦🤦🤦🤦 Поэтому я даже не могу добавить операторы console.log и просмотреть их. Этот баг действительно не хочет исправляться, да?

Чувство разочарования; Завтра постараюсь вернуться к этому на свежую голову. Дайте мне знать, если у вас есть идеи.

Привет, @lojjic , ​​у меня сейчас нет системы Mac, но я проверил это в стеке браузера с локальной переадресацией. Похоже, что данные sdf, зарегистрированные внутри веб-воркера и основного потока, отличаются. Это может быть связано с процессом сериализации-десериализации между потоками, но не совсем точно. Я буду продолжать отлаживать это дальше.
Вы можете попробовать кроссбраузерное тестирование, если инструменты разработчика Safari не работают для вас, они предлагают 100-минутную пробную версию, которая может быть полезной.

невозможность установить точки останова в соответствующем коде

Тупое предложение кидать сообщение от webworker после каждой строки кода и console.log его, так как вы, ребята, можете воспроизвести ошибку.

Изображение на моем iPhone 6/11:

Тупое предложение выбрасывать сообщение от webworker после каждой строки кода и console.log его

Совсем не глупое предложение! И это именно то, что я пытался сделать, но Safari devtools сразу падает для меня, когда я указываю на локальный редактируемый экземпляр, поэтому я даже не могу увидеть вывод console.log. :(

Вы пытаетесь открыть URL-адрес локального хоста на подключенном iPhone? Как в этом случае работает перенаправление портов?

Вы пытаетесь открыть URL-адрес локального хоста на подключенном iPhone? Как в этом случае работает перенаправление портов?

Я получаю доступ к серверу разработки с iPhone через IP-адрес локальной сети. Я также пытался подключить его через https://localhost.run. В обоих случаях Safari devtools падает, как только я его открываю. Сама страница отображается нормально (хотя иногда и с ошибкой).

Я читал в нескольких блогах, что это может произойти в двух сценариях:

1. когда батарея телефона заряжена на 100%
2. при отладке по сети, а не по кабелю

Это длинная тема с похожими строками, но без разрешения https://developer.apple.com/forums/thread/92290.

но Safari devtools сразу падает для меня, когда я указываю на локальный редактируемый экземпляр, поэтому я даже не могу увидеть вывод console.log. :(

Можно заменить функцию console.log по умолчанию чем-то вроде этого

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

но вам нужно создать этот div на странице html или из сценария JS

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

это должно отображать все консольные сообщения в основном потоке

Спасибо @munrocket , это может сработать, я попробую.

Всем привет,

Извините, что был так далеко от этой ветки. Не знаю, поможет ли это с отладкой, но симулятор последних версий Xcode 13 (в бета-версии) смог нормально запускать мои 3D-материалы на локальном хосте! Я столкнулся с проблемами, о которых вы говорили ранее, когда он продолжал падать с более ранними версиями.

@lojjic Повезло с этим?

Удачи с этим?

Нет, к сожалению, в последнее время у меня не было возможности уделять этому много времени.

есть ли возможность выключить webworkers? просто для проверки

Всем привет,

Я наткнулся на эту же проблему в проекте (для которого я, к сожалению, не могу поделиться кодом) и в конце концов нашел свой путь к этой проблеме прямо здесь. Поскольку последнее обновление по этому вопросу было более месяца назад, сегодня я решил повозиться с кодом зависимостей моего проекта, чтобы, надеюсь, точно определить, что именно происходит и какие строки кода способствуют этой UX-катастрофе.

Прежде чем идти дальше, я хочу подчеркнуть, что информация и настройки, приведенные ниже, никоим образом не рекомендуются и публикуются здесь исключительно для того, чтобы помочь в поиске фактического решения. Информация ниже НЕ является решением. Вы были предупреждены.

Первый. Да, как упоминалось ранее в обсуждении, это действительно вина WebWorker в iOS Safari. Firefox (win10), Chrome (win10), Opera (win10), Safari (macOS big sur) и другие не вызывают этой проблемы, и шрифты загружаются правильно в 100% случаев. Safari (iOS), однако, сталкивается с каким-то состоянием гонки между несколькими WebWorkers (я не определил, полностью ли это верно, и какие асинхронные вызовы мешают друг другу).

Второй. Это предполагаемое состояние гонки (или что-то еще) приводит к тому, что буфер, содержащий загружаемые данные шрифта, создает несколько значений NaN при доступе через функцию readShort в зависимости Troika Typr . Итак, действительно ли проблема в Typr? Возможно. Я не уверен. Однако эти несколько значений NaN поднимаются каскадом вверх по стеку вызовов, разрушая буквально все и, наконец, заставляя глиф отображаться совершенно неправильно.

В третьих. После определения точного местоположения, которое мне было нужно (функция readShort в Typr/bin.s ), я подправил ее несколькими способами, чтобы понять, что происходит.

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

Когда я просто использовал console.log(Typr._bin.t.int16[0]), приложение напечатало бы несколько NaN, которых никогда не должно быть (осторожно попробуйте это, потому что все приложение может зависнуть при печати - эта функция называется тысячи раз в зависимости от варианта использования). Однако, как и ожидалось, приостановка приложения в любом месте внутри этой функции (с помощью ключевого слова отладчика или точки останова или даже доступа к консоли) приводит к тому, что значение корректируется само по себе, а не выдает NaN (что заставило меня поверить в состояние гонки). Это означает, что вы не можете проверить проблему с помощью отладчика обычными способами.

Четвертое и последнее. Это та часть, которую я не советую, если не с целью найти фактическое решение этой проблемы. Заметьте, выше я писал, что если внутри функции readShort используется даже консоль, NaN исчезает. Так что мой гениальный хакерский склад ума придумал блестящую идею включения этого фрагмента перед оператором возврата readShort:

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

И это сработало! Весь текст теперь отлично отображается в iOS Safari, а также во всех других браузерах, которые я тестировал ранее. Проблема решена~... как бы, наихудшим образом. Оказывается, короткое окно, которое приложение создает для доступа к консоли, устраняет предполагаемое состояние гонки. И обратите внимание, что это происходит только при подключении к консоли.

В заключение. Вот где я нахожусь. Ужасный обходной путь работает, но я все еще ищу реальное решение этой проблемы, как и все здесь. Выяснилось, что проблема может быть в Тройке, а может и не в ней, поскольку она могла быть все время в Typr или даже в iOS-реализации WebWorker (кто знает). В любом случае, я надеюсь, что вся эта информация поможет расследованию, и мы все доведем его до конца.

Справочный стек вызовов:
Тип/bin.js - readShort
Тип/glyf.js — _parseGlyf
Typr/Typr.U.js — _drawGlyf
Typr/Typr.U.js — glyphToPath
Troika/FontParser_Typr.js - (Аноним) forEachGlyph
Тройка/FontParser_Typr.js - обернутьFontObj
Troika/FontParser_Typr.js - разбор
...Рабочие вещи

И @lojjic относительно устранения неполадок с отладкой iOS Safari через USB с использованием MacOS Safari:
Я советую попробовать отключиться и снова подключиться к локальной сети или вашему телефону, если MacOS Safari DevTools настаивает на бесконечной загрузке или отображает сообщение о сбое страницы, не загружаются скрипты или что-то еще. Либо так, либо попробуйте закрыть и снова открыть DevTools несколько раз. И затем обновление веб-страницы на телефоне, очевидно. Я говорю это, потому что это случилось со мной сегодня несколько раз (боль), и я решил это таким образом (подключение между MacOS Big Sur и iOS 15.0.1).

OMG @malulleybovo Я вернулся из отпуска и увидел ваши находки, и это был чудесный сюрприз! 😃 Большое спасибо за то, что копаетесь в этом.

Просто знание того, что readShort создает NaN, является _огромным_ шагом вперед в, возможно, окончательном понимании этой проблемы, над которой, как вы знаете, я полностью застрял в течение довольно долгого времени. Не помогло то, что я сменил работу и потерял доступ к устройству iOS, которым пользовался.

Мой следующий вопрос: можем ли мы определить, почему чтение Typr._bin.t.int16[0] создает NaN? Кажется, что он должен получить неправильное значение в одном из буферов (либо buff шрифта, либо утилиты Typr._bin.t.buff ), но это помогло бы точно знать, что значения buff/uint8/int16 находятся в данный момент времени по сравнению с тем, чем они должны быть.

Тот факт, что вы можете вставить туда console.log(), чтобы избежать ошибки, любопытен. Я не уверен, указывает ли это на состояние гонки или, возможно, доступ к консоли выводит ее из режима JIT. Я бы надеялся на первое, так как это звучит легче обнаружить и обойти.

@lojjic поздравляю со сменой работы!

Я только что еще немного покопался в этом вопросе и получил более интересные и странные новости об этом. Возвращаясь к фрагменту кода readShort, которым я поделился ранее, я попытался просмотреть значения массива (с общим буфером массива) и обнаружил самую странную вещь, которую я когда-либо видел в своей карьере программиста.

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

Просматривая первое появление NaN в readShort в моем приложении, я обнаружил, что buff[p]=255 и buff[p+1]=6 (оба допустимые значения uint8). Имея это в виду, я взглянул на значения Typr._bin.t.uint8 и обнаружил, что они имеют [6, 255, 0, ...], как и ожидалось. Затем я заглянул в Typr._bin.t.int16 и нашел ошибочное [NaN, 0, ...] вместо [-250, 0, ...]. Наконец, я заглянул в Typr._bin.t.int8 и... это тоже было неправильно... это было [6, NaN, 0, ...] вместо [6, -1, 0, ...] .

Библиотека Typr glyf использует один общий буфер ArrayBuffer для нескольких массивов разного типа (Uint8Array, Int8Array, Int16Array и т. д.). Этот случай показал мне, что в iOS Safari (только) после изменения одного из этих массивов значения в других могут обновляться не сразу. Понятия не имею, почему, но я нашел исправленный отчет об ошибке, связанный с ArrayBuffer в iOS Safari в недавней истории, что делает это более правдоподобным ... один раз было доказано, что оно ошибочно, вполне может оказаться ошибочным дважды (ссылка: (https://bugs.webkit) .org/show_bug.cgi?id=194268)[https://bugs.webkit.org/show_bug.cgi?id=194268]).

Обнаружив это, я решил попробовать альтернативную реализацию преобразования (uint8,uint8) to int16 . На этот раз с использованием побитовых операций. Код, который я использовал, следующий:

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

И вот оно. Весь текст со шрифтом теперь всегда отображается правильно (даже без подключения к devtools — обратитесь к моему предыдущему комментарию о console.log, чтобы понять этот отказ от ответственности). Это альтернативное решение устранило проблему в iOS Safari (проверено на iOS 15.0.2) , и продолжает работать в предыдущих браузерах, которые я тестировал ранее, как и раньше, таких как Chrome v95.0.4638.54 (win10), Firefox v93.0 (win10), Opera v80.0.4170.63 (win10) и MacOS Safari (MacOS Big Sur v11.3.1).

*Если кто-то может оптимизировать мой фрагмент кода выше, не стесняйтесь~

В конце концов, мне кажется, что эта проблема не вызвана тройкой. Тройка, кажется, на самом деле страдает от последствий более глубокой проблемы. Поэтому я бы лично перенес этот вопрос на Typr. Но что мне знать... проверьте сами и давайте поспорим, действительно ли это является корнем проблемы. ;)

Я думаю, что @malulleybovo заслуживает награды или что-то в этом роде! 🥳

Это потрясающе, сузить круг и придумать альтернативную реализацию, позволяющую избежать этой проблемы! Большое спасибо!

Я рад интегрировать ваше решение readShort в качестве локального переопределения в troika и/или восходящего потока в Typr. Возможно, нам нужны альтернативные реализации и для других методов readFoo?

Кажется, что есть что-то неправильное/опасное с шаблоном типизированных массивов, разделяющих буфер в целом. Теперь, когда я думаю об этом, это довольно любопытная закономерность. Похоже, что DataView предназначен именно для чтения различных числовых форматов из двоичного кода, без каких-либо странных преобразований значений между uints и числами JS или несоответствий порядка байтов... Интересно, решит ли это проблему? Что-то вроде этого, может быть? https://gist.github.com/lojjic/94d7b5f5f374598fe0e9761be45ebb2b

Спасибо за комплимент @lojjic~ Я рад, что был полезен.

Предложенное вами решение показалось многообещающим, поэтому я просто протестировал его и угадайте, что оно также работает (во всех браузерах, которые я перечислил ранее)!
Использование DataView кажется кратким и правильным способом реализации этого в JS, если вы спросите меня. Хороший.

Мое приложение зависит от сценария глифа Typr, который использует readInt8, readShort, readUshort и readBytes Typr. Хотя я включил ваше полное решение для целей тестирования, я тестировал его только на этих функциях. И все работает, судя по всему.

Чтобы более подробно изучить эффективность этого решения, я бы протестировал другие сценарии. Но мне не хватает конкретных примеров для проверки (кроме модульного тестирования).

Я считаю, что readFixed, readF2dot14, readUshorts, readUint64, readASCII, readUnicode, readUTF8, readBytes и readASCIIArray Typr из bin.js не нужно менять, поскольку они не используют напрямую типизированные массивы. Таким образом, в Typr нужно будет изменить только те функции, которые указаны в вашей сущности. Кроме того, вместе с этим изменением общий ArrayBuffer и типизированные массивы Typr устареют.

Если больше разработчиков смогут протестировать и одобрить это, мы будем еще более уверены в решении. Это связано с тем, что в моем распоряжении есть ограниченное количество тестовых случаев и тестовых устройств, и есть небольшая вероятность того, что результат теста будет необъективным.

Предложенное вами решение показалось многообещающим, поэтому я просто протестировал его и угадайте, что оно также работает (во всех браузерах, которые я перечислил ранее)!
Использование DataView кажется кратким и правильным способом реализации этого в JS, если вы спросите меня. Хороший.

Удивительно!!! Я с трудом могу в это поверить. 🎉 🥳

Я проведу еще несколько тестов, чтобы проверить, смогу ли я проверить другие функции, и проведу базовое сравнение производительности. Если не появится что-то неприятное, я интегрирую это как можно скорее. Я вполне уверен, что включу это в выпуск тройки-три текста, чтобы люди могли его опробовать; сообщество сообщит нам, если возникнут какие-либо проблемы. Как только он немного побудет в дикой природе, я отправлю его вверх по течению в Typr.

Производительность кажется сопоставимой, в некоторых случаях даже немного выше. Дополнительный выигрыш! 😄

Я проверил, что другие функции тоже работают. Мне пришлось немного изменить хелпер _view , чтобы он обрабатывал случаи в шрифтах CFF, когда Typr передает buff как простой массив JS, а не как Uint8Array.

Я опубликовал версию troika-three-test 0.43.1-alpha.0 с исправлением DataView в ней (в настоящее время используется приватный форк Typr — соответствующий коммит )

Всем, кто может (@amitrajput1992? @strangerintheq? @atlmtw?), я был бы очень признателен за тестирование этой версии, чтобы убедиться, что она устраняет проблему в ваших конкретных приложениях. Я попытаюсь сделать то же самое либо с Browserstack, либо с поиском iPhone, который можно одолжить. Заранее спасибо!

Привет, @lojjic , ​​приятно слышать, что это можно исправить. Позвольте мне проверить это быстро и вернуться к вам.

@amitrajput1992 Привет, у тебя уже была возможность протестировать альфу? Я хочу, чтобы это было выпущено, и мне бы хотелось получить дополнительную проверку. :)

@lojjic Эй, у меня только что появилось время проверить это. Похоже, теперь это работает!!

Ознакомьтесь с изменениями здесь: https://amitrajput1992.github.io/r3f-experiments/?path=/story/testers --text-tester

Я выпустил версию 0.44.0 с исправлением этой неприятной ошибки. Я так счастлив, что наконец это исправлено! Спасибо всем за помощь, и особенно @malulleybovo за то, что копнули глубоко там, где я не смог, и нашли первопричину. Я очень благодарен! 🥳