おさむのひと

Results 212 comments of おさむのひと

mfm.jsの仕様ですね。 https://github.com/misskey-dev/mfm.js/blob/develop/docs/syntax.md#mention > 1文字以上。 A~Z 0~9 _ -が含められる。 1文字目と最後の文字は-にできない。 とのこと。

少なくとも、何の処理か特定できるレベルの情報が欲しいです。 引用元の投稿を見ても、サーバブロック(サスペンド?)かどうかも確実ではなさそうなので

何が起こってるのか調べてみました。 > Bad position 1127835099/11998 上記を見て、想定外の値をAPNGのサイズ情報として読み取っている可能性があると考えました。 そこで、ライブラリにブレークポイントをはり、`1127835099`同様に想定外の数値をサイズ情報として読み取るまでアプリを動かしてみたところ、この現象が発生する画像側に問題があることがわかりました。 どこがおかしいかを分かりやすくするため、正常に表示できているAPNGと表示できていないAPNG(今回は:loading:)を比較してみました。 :ablob_fox_loading:(※) ![image](https://github.com/pantasystem/Milktea/assets/46447427/6b0deb58-e19d-461d-ba05-80209231f5f0) :loading: ![image](https://github.com/pantasystem/Milktea/assets/46447427/1fd360c2-dff1-4d00-8783-e39648175854) ※こういうAPNGです。橙色の輪郭の中で黒い記号が回転しています ![image](https://github.com/pantasystem/Milktea/assets/46447427/0becec71-1180-4fbd-8de0-c232e9f590ff) 正常に表示できているablob_fox_loadingはIENDチャンクでバイナリが終わっているのに対し、loadingはIENDチャンク以降にもバイナリが存在しています(IENDチャンクを選択して反転表示しています)。 ライブラリがこの余剰なバイトを読み込み、画像の要領である11998を大きく超える1127835099にアクセスしようとして本件の現象が発生しているようです。 参考: https://qiita.com/spc_ehara/items/c748ec636283df805926#iend%E3%83%81%E3%83%A3%E3%83%B3%E3%82%AF-1

あと、ライブラリの2.23.0と2.24.0のソースを落としてdiffをとってみましたが、明確に怪しいと思われる差分はありませんでした…

たびたび失礼します。2点ほど… - developの最新(2.23.0を使っているバージョン)でもloadingが表示されず、ログに`Bad position ... `のエラーが出ていました - 直し切る自信が無かったのでアサインのお願いをしなかったのですが、[IENDチャンクより後ろは捨てる](https://github.com/samunohito/Milktea/blob/e2f5f7a2f3701b395ac21ca3c791e8b80d2b46fb/modules/common/src/main/java/net/pantasystem/milktea/common/glide/apng/ApngDecoder.kt#L49)ようにしたところloadingの表示が出来ました。**ただし、アニメーションしません。** 以下の制限事項がありますが、それでもよろしければプルリクエストを発行しようと考えています。 如何でしょうか…(要否問わず遠慮なくお申し付けください) - 上記に記載の通りアニメーションしない(原因不明で直しきれず…) - 画像の末尾よりIENDチャンクを線形探索しているため、わずかにパフォーマンスが落ちることが予想される

@syuilo この件、メンテされたら取り込む意思はありますか?

@mochi-sann syuilo氏からのコメントがついていますので、対応頂ければ幸いです。 また、対応が難しい場合はその旨ご連絡いただければ引き継いで対応します

0000や9999に特別な意味を持たせず、user_profileなどに年齢表示のフラグを持たせて愚直に制御したほうが良いように思えます。 みるかぎり、プラットフォームの穴埋めをする実装をしなければならないようですし…トリッキーな実装が増えると後が大変なので、素直に表現できるところはシンプルに解決したほうが今後も楽になるだろうと考えます。

> 0000で済ました方が それが難しそうなので、フロントの実装を力とパワーで解決するよりは愚直にやったほうがいいのではないかというご提案です

送信要求を間引くのもアリだと思っている(1秒に1件までとか)