Troika: [troika-three-text]IOSSafariの読み込みの問題

これを報告してくれてありがとう！ iOS Safariでこのような問題を最初に説明したのはあなたではありませんが、以前は再現できませんでした。 私はあなたのサイトで試してみます、そしてうまくいけば私はそれを再現することができるでしょう。

たまたまdrei経由で使っていますか？ または直接？

ねえ@lojjic私はこのパッケージをthree.jsで直接使用しています。 そして、私が3つのユーティリティを持っている理由は、場合によってはcreateDerivedMaterial関数も使用するためです。

これをチェックしてくれてありがとう！

あなたのウェブサイトをiPhone8にロードする際の問題を再現することができました。まだデバッグを開始する時間がありませんが、バグが再現可能であることを認めたかっただけです。

@atlmtw@ lojjic複数のフォントを使用しているプロジェクトのサファリで同じ問題が発生しました。 私が見つけた唯一の修正は、このブラウザのWebサイト全体で一意のフォントを使用することでした。

+1
シーンごとに複数のフォント=一部のフォントはiphoneX、iphoneSEに表示されません

私はこの問題を掘り下げようとしていますが、現在それを再現するのに問題があります。 以前と同じiPhone8。 もうdesignsdalena.comで再現することはできませんが、サイトがtroika-three-textを使用しないように変更されたか、別の方法で回避された可能性があります。

したがって、複数のフォントを使用して最小限のテストケースを作成しようとしていますが、失敗することはありません。

https://uqgxq.csb.app/

テスト/デバッグに使用できる場所でこれを再現できる人は他にいますか？

ねえ@lojjic

確認するために、私は別のものに切り替えました。 私はトロイカをもっと使う経験を楽しんでいますが。

@atlmtw確認ありがとうございます。 ソース管理に古いバージョンのサイトがあり、私に送信できるとは思いませんか？ 私はこれを再現するのに苦労していて、あなたは信頼できる再現のようでした。

ねえ@lojjic
これで運がいいですか？ iPhoneで1つ以上のフォントが使用されている場合にもこれが見られます（iPadおよびmacOSで動作します）。 奇妙なことに、これは常に複製可能ではなく、1〜2 / 10回だけ、最初のロードでのみ発生します。 フォントファイルのダウンロードに関連しているのでしょうか？

ところで、仕事が大好きです：100：

@ amitrajput1992いいえ、再現可能なテストケースを作成することはまだできていません。 使えるものはありますか？

@lojjic
これを試してみませんか？
デスクトップで開くと、6つの異なるテキストが異なる色で印刷されているはずです。
このリンクをいくつかのデバイスでテストし、いくつかのデバイスでBrowserStackでテストしましたが、すべてレンダリングの問題が示されています。 リンクを数回更新すると機能しますが、これは非常に奇妙なことです。

これは私がBrowserStackで見るものです。 これはiPhone8+Safariv13にあります

これは私のiPhone11+Safari14にあります

フォントファイルがWebワーカーにダウンロードされるという事実と関係があるのでしょうか。 サファリはWebワーカーにとって苦痛になる可能性があることを私たちは知っています

@ amitrajput1992ありがとう、私は確かにそのページで問題を再現することができます。 そこからデバッグしたり、最小化されたローカルテストケースで複製したりできるかどうかを確認します。

サファリはWebワーカーにとって苦痛になる可能性があることを私たちは知っています

他の人もこれを言うのを聞いたことがあり、労働者の使用は間違いなくもっともらしい犯人ですが、Safariの労働者の既知のバグに関する詳細を見つけることができませんでした。 共有できる詳細はありますか？

@lojjic
いいですね。 何かお手伝いできることがあれば教えてください。 その間、私はデバッグを続け、自分の側でも問題を絞り込もうとします。

他の人もこれを言うのを聞いたことがあり、労働者の使用は間違いなくもっともらしい犯人ですが、Safariの労働者の既知のバグに関する詳細を見つけることができませんでした。 共有できる詳細はありますか？

ここで正確な問題についてはわかりません。これは、これらがどこにも見つからない（または人々がログに記録しない）ためですが、これは私がいじくり回しているときに気付いたものです。 react360以前はreact-vr（現在は廃止）はWebワーカー内でreactコード全体を実行するために使用され、メインスレッドへの更新は非常に遅かった。 ワーカースレッドのクリックリスナーに伝播するために、約300ミリ秒から500ミリ秒のどこかでクリックアクションを簡単に実行し、多くの場合、数回のクリックも見逃します。
私は3つのgifレンダラーであるリポジトリを維持しており、最初はオフスクリーンキャンバスで試しましたが、結果はひどく、連続するフレームでテクスチャがブレンドされました。 全体をメインスレッドに移動すると、大幅に改善されました。

これは、ワーカーからメインスレッドに情報を送信するときに使用される構造化クローンアルゴリズムと関係があると思います。 iOSでのこの制限に関する確固たる証拠を見つけることはできませんでしたが

私は最初にこれらのアーティファクトに焦点を当てるべきだと思います。これらは常に表示されるとは限りませんが、時々表示されます。

このような場合、レイアウトとSDFの生成は明らかに完了し、メインスレッドに戻りますが、一部のSDFでは、内側/外側の塗りつぶしが場所によって逆になっているように見えます。 パスセグメントが半分しかないなど、これらの文字のパスデータが不完全な場合にどのように発生するかがわかります。

フォントのロード中にフォントの配列バッファが切り捨てられたり破損したりすることが発生した場合、この症状が発生する可能性があると思います。 同様に、特定の場所で切り捨てられた場合、結果が完全に空になる可能性もあります。

可能性としてそれを調査しますが（XHRが部分的なarraybuffer応答を与える可能性がありますか？）、最初のステップは、これを変更してローカルで実行できる再現可能なテストケースに入れることです。

それは理にかなっている。 ここでは、arraybufferの破損が原因である可能性があります。
このプロセス全体をメインスレッドで実行することについての別の議論を見ました。 それはロードマップにありますか？

また、それが役立つ場合は、以下のバージョンでdreiを使用してtroikaを使用しています。
@ react-three / fibre：6.2.3
@ react-three / drei：6.0.1
トロイカ：0.42.0
3：0.129.0

メインスレッドで実行することは可能ですが、メインスレッドを潜在的に数秒間ブロックするというかなりひどい経験になります。 それは最後の手段にすぎないはずです。

テストページは変更されましたか？ 少なくともiOSでは、現在、すべての異なるテキストオブジェクトに単一のフォントしか使用していないようです...？ ただし、その単一のフォントで文字化けしたSDFが表示されることがあります。これは、複数のフォントによって悪化する可能性があることを意味しますが、これに限定されません。

アプリ全体で単一のフォントのみを使用するように、iOSデバイスのフォールバックを追加しました。 これは私の本番環境なので、そこに物事を壊すことはできません。
ステージング環境で別の例を作成し、できるだけ早くここにリンクを送信します。

これが単一のフォントでもまだ発生していることを見つけるのは面倒です：facepalm：

うーん、実際には、Safari devtoolsに接続したときにのみ、新しいシングルフォントでバグが発生するようですが、そのときはかなり一貫してバグがあります。 それが私たちに手がかりを与えるかどうかはわかりません。

さて、もう少し進歩します...個々のグリフのパスコマンドを切り捨てることで、上記と同じ部分的なグリフアーティファクトを強制できることを確認しました。 元のフォントデータが不完全なためか（部分的なグリフが1つだけ発生し、多くは発生しないため、発生する可能性は低いと思われます）、または何かがforループの原因であるかどうかをまだ判断できていません。早く終了します（これは不可能に思えますが、奇妙なJITバグがあるかもしれません）。

いずれにせよ、SafariのUSB接続devtoolsが関連するコードにブレークポイントを設定できないことに悩まされています。 @ amitrajput1992ローカルでビルド/実行できるソースファイルとしてテストアプリを取得することは可能でしょうか。それで、トロイカコードをスワップアウトしてデバッグしてみることができますか？

@lojjic元のアプリコードを共有することはできませんが、本番アプリで使用しているのと同様の構造でストーリーブックリポジトリを設定し、このためのテストレンダリングを追加します。 リンクをまもなく送信します。

@lojjic
ここで、本番アプリと同様の構造の基本的な再現を設定しました： https ://github.com/amitrajput1992/r3f-experiments
これで同じ問題をiPhone11とBrowserStackで再現できます。
また、簡単にアクセスできるようにストーリーブックをここに公開しましたhttps://amitrajput1992.github.io/r3f-experiments

@ amitrajput1992テストケースをありがとう！ ストーリーブックからフォントを提供することで、gmetriサイトからフォントをロードするCORSエラーを修正した後、そこで複製できます。

しかし...それから私のSafaridevtoolsはそれに接続しようとして_crashes_で完全になります！ 🤦🤦🤦🤦🤦🤦だから、console.logステートメントを追加してそれらを表示することさえできません。 このバグは本当に修正されたくないのですね。

欲求不満を感じる; 明日はもっと新鮮な心でこれに戻ろうと思います。 何かアイデアがあれば教えてください。

ねえ@lojjic 、私は今私と一緒にMacシステムを持っていませんが、ローカル転送を使用してbrowserstackでこれをテストしました。 Webワーカーとメインスレッドの内部に記録されたsdfデータが異なるようです。 スレッド通信間のシリアル化-逆シリアル化プロセスが原因である可能性がありますが、完全に確実ではありません。 これをさらにデバッグし続けます。
safari dev-toolsが機能しない場合は、クロスブラウザテストを試すことができます。100分のトライアルが提供されているので便利です。

関連するコードにブレークポイントを設定できない

コードの各行の後にwebworkerからのメッセージをスローし、console.logを作成するという愚かな提案です。これは、バグを再現できるためです。

私のiPhone6/11の画像：

コードとconsole.logの各行の後にwebworkerからのメッセージをスローするというばかげた提案

ばかげた提案ではありません！ それはまさに私がやろうとしていたことですが、ローカルの編集可能なインスタンスを指すと、Safariのdevtoolsがすぐにクラッシュするため、console.logの出力も表示されません。 :(

接続されたiPhoneでローカルホストのURLを開こうとしていますか？ この場合、ポートフォワーディングはどのように機能しますか？

接続されたiPhoneでローカルホストのURLを開こうとしていますか？ この場合、ポートフォワーディングはどのように機能しますか？

iPhoneからローカルネットワークのIPアドレスを介して開発サーバーにアクセスしています。 また、 https：//localhost.runを介して配管してみました。 どちらの場合も、Safaridevtoolsを開くとすぐにクラッシュします。 ページ自体は問題なくレンダリングされます（ただし、バグがある場合もあります）。

私はいくつかのブログで、これが2つのシナリオで発生する可能性があることを読みました。

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;

ただし、HTMLページまたはJSスクリプトからそのdivを作成する必要があります

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

これにより、メインスレッドのすべてのコンソールメッセージが表示されます

@munrocketに感謝します、それはうまくいくかもしれません、私はそれを試してみます。

やあみんな、

申し訳ありませんが、私はこのスレッドからとても離れています。 これがデバッグに役立つ場合はIdkですが、最近のXcode 13バージョン（ベータ版）シミュレーターは、私の3Dローカルホストのものを正常に実行できました！ 以前のバージョンでクラッシュし続ける前に、みんなが話していた問題に遭遇しました。

@lojjicこれで運がいいですか？

これで運がいいですか？

いいえ、残念ながら、私は最近これに多くの時間を割くことができませんでした。

Webワーカーをオフにする可能性はありますか？ チェックのためだけに

こんにちは、みんな、

私はプロジェクトでこれと同じ問題に遭遇し（残念ながらコードを共有できません）、最終的にこの問題のチケットへの道をここで見つけました。 これに関する最後の更新は1か月以上前だったので、今日、プロジェクトの依存関係コードをいじって、何が起こっているのか、どのコード行がこのUXの災害に寄与しているのかを正確に特定することにしました。

先に進む前に、以下の情報と微調整は決してアドバイスされておらず、実際の解決策の検索を支援するためだけにここで共有されていることを強調したいと思います。 以下の情報は解決策ではありません。 あなたは警告されました。

初め。 はい、前に説明したように、これは確かにiOSSafariのWebWorkerのせいであるようです。 Firefox（win10）、Chrome（win10）、Opera（win10）、Safari（macOS big sur）などではこの問題は発生せず、フォントは常に100％正しく読み込まれます。 ただし、Safari（iOS）は、複数のWebWorker間で何らかの競合状態に陥ります（これが完全に正しいかどうか、またどの非同期呼び出しが相互に干渉しているかはわかりません）。

2番。 この競合状態（またはそれが何であれ）が原因で、ロードされているフォントデータを含むバッファーが、TroikaのTypr依存関係のreadShort関数を介してアクセスされたときにいくつかのNaN値を生成します。 それで、問題は実際にTyprにありますか？ 多分。 よくわかりません。 ただし、これらのいくつかのNaN値は、文字通りすべてを台無しにし、最終的にグリフが完全に間違って表示される原因となるコールスタックをカスケードします。

三番。 必要な正確な場所（ Typr / bin.sのこの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];
        return Typr._bin.t.int16[0];
    },

console.log（Typr._bin.t.int16 [0]）を使用しただけでは、アプリケーションは決して表示されるべきではないいくつかのNaNを出力します（アプリケーション全体が印刷物をハングさせる可能性があるため、これを試してみてください-この関数は呼び出されますユースケースに応じて数千回）。 ただし、予想どおり、この関数内の任意の場所でアプリケーションを一時停止すると（デバッガーキーワードまたはブレークポイントを使用するか、コンソールにアクセスすることもできます）、値は自動的に修正され、NaNは生成されません（競合状態を信じるようになりました）。 つまり、従来の方法ではデバッガーの問題を検査できません。

4番目そして最後に。 これは、この問題の実際の解決策を見つける目的ではないにしても、私がアドバイスする部分です。 上記で書いたように、readShort関数内でコンソールを使用すると、NaNが消えます。 したがって、私の独創的なハッカーの考え方は、readShortのreturnステートメントの前にこのスニペットを含めるという素晴らしいアイデアを考えました。

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

そしてそれはうまくいきました！ iOS Safariだけでなく、以前にテストした他のすべてのブラウザーでも、すべてのテキストが正常に表示されるようになりました。 問題は解決しました〜...ちょっと、可能な限り最悪の方法で。 アプリケーションがコンソールにアクセスするために作成する短いウィンドウで、競合状態が解決されることがわかりました。 また、コンソールに接続している場合にのみ機能することに注意してください。

結論は。 これが私がいるところです。 ひどい回避策は機能しますが、ここにいる全員がそうであるように、私はまだこれに対する実際の解決策を探しています。 この問題は、ずっとTyprにあった可能性があるため、またはiOSのWebWorkerの実装（知っている）でさえあるため、Troikaにある場合とない場合があることが判明しました。 いずれにせよ、私はこのすべての情報が調査に役立つことを願っています、そして私たちは皆これを最後まで見ています。

参照呼び出しスタック：
Typr / bin.js-readShort
Typr / glyf.js-_parseGlyf
Typr / Typr.U.js-_drawGlyf
Typr /Typr.U.js-glyphToPath
Troika / FontParser_Typr.js-（匿名）forEachGlyph
Troika / FontParser_Typr.js-wrapFontObj
Troika/FontParser_Typr.js-解析
...労働者のもの

そして@lojjic 、MacOSSafariを使用したUSB経由のiOSSafariデバッグのトラブルシューティングに関して：
MacOS Safari DevToolsが無期限にロードするように要求したり、ページがクラッシュしたかスクリプトをロードしていないなどのメッセージを表示した場合は、ローカルネットワークまたは電話を切断して再接続することをお勧めします。 それか、DevToolsを数回閉じてから再度開いてみてください。 そして、明らかに電話のWebページを更新します。 これは、今日私に数回（痛み）起こり、そのように解決したためです（MacOS BigSurとiOS15.0.1の間の接続）。

OMG @malulleybovo私は休暇から戻って、あなたの発見を見て、それは素晴らしい驚きでした！ 😃これを掘り下げてくれてありがとう。

readShortがNaNを生成していることを知っているだけで、この問題を最終的に理解するための_巨大な_一歩です。ご存知のように、私はかなり長い間完全に立ち往生してきました。 私が仕事を変えて、私が使っていたiOSデバイスへのアクセスを失ったことは助けにはならなかった。

次の質問は、Typr._bin.t.int16[0]の読み取りがNaNを生成している理由を特定できるかどうかです。 バッファの1つ（フォントの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];
    },

アプリケーション内のreadShortでNaNが最初に発生するのを覗いてみると、buff [p]=255とbuff[p+ 1] = 6（両方とも有効なuint8値）であることがわかりました。 そのことを念頭に置いて、Typr._bin.t.uint8の値を調べたところ、期待どおりに[6、255、0、...]であることがわかりました。 次に、Typr._bin.t.int16をのぞいて、[-250、0、...]ではなく誤った[NaN、0、...]を見つけました。 最後に、Typr._bin.t.int8をのぞきましたが、それも間違っていました... [6、-1、0、...]ではなく[6、NaN、0、...]でした。

Typr glyfライブラリは、異なるタイプ（Uint8Array、Int8Array、Int16Arrayなど）の複数の配列で1つの共有ArrayBufferを使用します。 この出来事は、iOS Safari（のみ）で、これらの配列の1つを変更した後、他の配列の値がすぐに更新されない可能性があることを示しました。 理由はわかりませんが、最近の歴史でiOS SafariのArrayBufferに関連する解決済みのバグレポートを見つけました。これにより、これがより信頼できるものになります... 1回の欠陥であることが証明され、2回の欠陥であることが証明される可能性があります（参照：（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 Surv11.3.1）。

*上記のコードスニペットを最適化できる方がいらっしゃいましたら、お気軽にどうぞ〜

結局、この問題はトロイカが原因ではないように私には思えます。 トロイカは実際、より深い問題の結果に苦しんでいるようです。 だから私は個人的にこの問題をTyprに移します。 しかし、私は何を知っていますか...自分でそれをテストし、これが本当に問題の根源であるかどうかを議論しましょう。 ;）

@malulleybovoは賞か何かに値すると思います！ 🥳

これは驚くべきことであり、それを絞り込んで、問題を回避する代替の実装を考え出します！ どうもありがとうございました！

troikaのローカルオーバーライドおよび/またはTyprのアップストリームとして、 readShortソリューションを統合できてうれしいです。 他のreadFooメソッドの代替実装も必要かもしれませんか？

一般に、typed-arrays-sharing-a-bufferパターンに何か問題/危険があるようです。 考えてみると、かなり不思議なパターンです。 DataViewは、uintとJS番号の間の奇妙な値変換やエンディアンの不一致なしに、バイナリからさまざまな数値形式を読み取ることを目的としているようです...それでも問題が解決するのでしょうか。 多分このような何か？ https://gist.github.com/lojjic/94d7b5f5f374598fe0e9761be45ebb2b

お褒めの言葉をありがとう@lojjic〜お役に立ててうれしいです。

あなたの提案した解決策は有望であるように思われたので、私はそれをテストして何を推測しました、それはまた（私が前にリストしたすべてのブラウザで）動作します！
DataViewを使用することは、私に言わせれば、JSでこれを実装するための簡潔で適切な方法のように思えます。 良いですね。

私のアプリケーションは、TyprのreadInt8、readShort、readUshort、およびreadBytesを使用するTyprのglyfスクリプトに依存しています。 テスト目的で完全なソリューションを含めましたが、これらの関数でのみテストしました。 そして、すべてがそれの外見によって機能します。

このソリューションの有効性をさらに詳しく調べるために、他のシナリオをテストします。 しかし、これらをテストするための具体的な例はありません（単体テストだけでなく）。

TyprのreadFixed、readF2dot14、readUshorts、readUint64、readASCII、readUnicode、readUTF8、readBytes、およびbin.jsのreadASCIIArrayは、型付き配列を直接使用しないため、変更する必要はないと思います。 したがって、要点の機能のみをTypr内で変更する必要があります。 さらに、この変更に伴い、Typrの共有ArrayBufferと型付き配列は廃止されます。

より多くの開発者がこれをテストして承認できれば、ソリューションにさらに自信が持てるようになります。 これは、使用できるテストケースとテストデバイスの数が限られており、テスト結果に偏りが生じる可能性がわずかにあるためです。

あなたの提案した解決策は有望であるように思われたので、私はそれをテストして何を推測しました、それはまた（私が前にリストしたすべてのブラウザで）動作します！
DataViewを使用することは、私に言わせれば、JSでこれを実装するための簡潔で適切な方法のように思えます。 良いですね。

すばらしい！！！ 信じられない。 🎉🥳

これをさらにテストして、他の関数を検証できるかどうかを確認し、基本的なパフォーマンスの比較を行います。 何か厄介なものが現れない限り、私はこの統合されたものをできるだけ早く手に入れます。 人々が試してみることができるように、これをtroika-three-textリリースに含めることにかなり自信があります。 コミュニティは、問題が発生した場合に通知します。 少し公開されたら、Typrのアップストリームに送信します。

パフォーマンスは同等のようですが、場合によっては少し速くなります。 余分な勝利！ 😄

他の機能も動作することを確認しました。 TyprがbuffをUint8ArrayではなくプレーンJS配列として渡すCFFフォントのケースを処理するために、 _viewヘルパーを少し変更する必要がありました。

DataView修正を含むtroika-three-testバージョン0.43.1-alpha.0を公開しました（現在、Typrのプライベートフォークを使用しています-関連するコミット）

できる人なら誰でも（@ amitrajput1992？@strangerintheq？@atlmtw？）、このバージョンでテストして、特定のアプリケーションの問題が修正されることを確認していただければ幸いです。 Browserstackを使って、または借りるiPhoneを見つけて、同じことをしようと思います。 前もって感謝します！

ねえ@lojjicそれに対する修正があると聞いてうれしいです。 これをすばやくテストして、返信します。

@ amitrajput1992こんにちは、アルファをテストする機会はもうありましたか？ これをリリースしたいので、追加の検証が必要です。 :)

@lojjicねえ、私はちょうどこれをテストする時間がありました。 今は動いているようです!!

ここで変更を確認してください： https ：//amitrajput1992.github.io/r3f-experiments/？path = / story / testers --text-tester

この厄介なバグを修正したバージョン0.44.0をリリースしました。 ついにこれが修正されてとてもうれしいです！ 皆さんの支援に感謝します。特に@malulleybovoは、私ができなかった場所を深く掘り下げ、根本的な原因を見つけてくれました。 とてもありがたいです！ 🥳