misskey [after 2025.4.1]DeckUIで横スクロールがしにくくなった

💡 Summary

なんかデッキUIで横スクロールができない？

https://misskey.systems/notes/a7bvts9q68

デッキUIのタブ名の部分ではスクロール可能、その下では不可能といった感じっぽそうです

https://misskey.systems/notes/a7bwch5sih

🥰 Expected Behavior

従来通り

🤬 Actual Behavior

スクロールできる判定が狭い

📝 Steps to Reproduce

No response

💻 Frontend Environment

* Model and OS of the device(s):
* Browser:
* Server URL:
* Misskey:

🛰 Backend Environment (for server admin)

* Installation Method or Hosting Service:
* Misskey:
* Node:
* PostgreSQL:
* Redis:
* OS and Architecture:

Do you want to address this bug yourself?

[ ] Yes, I will patch the bug myself and send a pull request

May 03 '25 14:05 fruitriin

これか？ https://misskey.systems/notes/a7bwmms5ni

これを無効化したらうまく行った https://misskey.systems/notes/a7bwmz6nny

May 03 '25 14:05 fruitriin

横方向にスクロールしたいときのマウス操作がPullToRefreash用のイベントハンドラに吸われるのではないか？というのが現状の考察です

May 03 '25 14:05 fruitriin

仮説が正しければ、develop最新でないと起きなさそうなのでタイトル変えておきます　なんかあったらまた変えてください

May 03 '25 15:05 fruitriin

PullToRefresh有効時は、PullToRefreshエリア上での横スクロールは不可となります

May 03 '25 20:05 syuilo

スマホ環境で試したらデッキを横にスクロール出来なくてびっくりしました (ブラウザにおいて、通常のサイトは大体どこでも横スクロールが可能(拡大時など特に)なので、TL部分をスワイプすることでの横スクロールは普段頻繁に用いています)

このままは良くない気がします…

May 08 '25 05:05 Sayamame-beans

dev最新だと解消済みのような？それか環境のデバイス識別をデスクトップ→自動かスマホへ

マウスで引っ張って更新が入った影響でスクロール処理の乗っ取りが起きてたのをミドルクリックに移動したのが2025.5.0には入ってると思う

May 08 '25 05:05 fruitriin

確認した環境

Model and OS of the device(s): AQUOS zero2 (Android 12)
Browser: Chrome 135.0.7049.101
Server URL: https://nekolobby.niri.la/
Misskey: 2025.5.0-kinel.1

May 08 '25 05:05 Sayamame-beans

デスクトップ水平スクロールができない問題自体は残ってたと思います(帰ったら再確認します) (macOS トラックパッド)https://nekolobby.niri.la/

May 08 '25 05:05 anatawa12

それか環境のデバイス識別をデスクトップ→自動かスマホへ

試してみましたが、環境識別の変更では変化が見られませんでした。

May 08 '25 05:05 Sayamame-beans

デスクトップ水平スクロール、Shift＋マウススクロールでも（TL領域にマウスカーソルが被っていると）PullToRefresh無効でもできないですね windows chrome, firefox

May 08 '25 05:05 tai-cha

一回この機能抜いた方が良いかもしれない…と思うなどしています、いかがでしょうか? (実装/挙動が安定しない状態のままで何らかの問題を踏むなどし、一度無効化されてしまうと、実装が改善した後に再度有効化される可能性が低いと思うので、一旦無かったことにしてしまった方が、結果的に(改善した実装を再投入することで)機能を使ってもらえる可能性が高くなるのではないかな、と思いました)

May 08 '25 06:05 Sayamame-beans

カラム内の縦スクロール領域を横にスクロールしてデッキをスクロールすることは挙動の一貫性がなく、意図していないので変更は考えていません

May 08 '25 07:05 syuilo

横にスクロール移動する領域が横スクロールできないほうが挙動の一貫性(というか直感性)がないと思います

May 08 '25 07:05 anatawa12

しゅいろさんにお聞きしたいのですが、スマホ等のデバイスでのデッキ環境において、横スクロールの際に想定される操作はどのようになりますか?

(使うデバイス等にも左右されると思いますが、)私の場合、端末を持っている状態では手が下の方にあり、画面最上部にあるタブ部分でのスクロールは(領域の狭さも相まって)使い勝手としてかなり不便になってしまう状態です。 (実質的に横スクロールが出来なくなるのに近しいほどの負担があります。)

May 08 '25 23:05 Sayamame-beans

スマホでDeckが使われることはそこまで想定していませんが、使う場合はカラムのヘッダー部分もしくはカラム間のスペースを少し広げてスクロールすることを想定しています

May 08 '25 23:05 syuilo

横スクロールできないのがひっぱって更新のせい、少し下にスクロールすれば横にスクロールできる　っていうことがユーザーには全くわからないと思うので、そこをもうちょっとフォローできると良さそうな気がする (今だと横スクロールできるときとできないときがわからなくてびっくりしそう)

May 09 '25 13:05 fruitriin

タイムライン上で横スクロールできないのは仕様で、引っ張って更新は関係しないわね

May 09 '25 13:05 syuilo

カラム間のスペースを少し広げてスクロール

ヘッダーでのスクロールは前述の通りでしたので、マージンを使用する方法を試してみました。(感想を上手く言語化出来ずに置いていました)

私の場合、現実的に操作可能な幅にしようと思うとマージンを50程度にする必要がありました。(値は端末に依ると思いますが、カラムの左右に指半分程度以上の余白がある状態です) この場合、殆ど1画面1カラム状態になってしまって、デッキの強みが失われている感じがしました。 (並び順が自由に出来るだけのデフォルトUIという感じになりますし、表示範囲も狭くなっているので、寧ろデメリットが発生していました) また、これより余白を狭くすると、操作出来る場合と出来ない場合が不安定に存在するような形になり、不便でした。

May 09 '25 14:05 Sayamame-beans

私なりに状況を整理してみました。

Pull to Refresh

タイムライン等を上端で引っ張って更新する機能
- 単純にリロードしたい場合や、No Webwocketモード時などにあると便利
スマホやタブレットなどのタッチ環境では嬉しい操作(かも)
マウス利用時などではどのように発火させるかが課題となる
- 現在はホイールクリックでのドラッグが採用されている
- (上端で更にスクロールしようとすることによる発火が出来ると直感性が高まりそうだが、実現可能性が不明)

デッキUIにおける横スクロール

そもそも横スクロールについて

マウス利用時は、Shift+ホイール、ホイールを横に倒す、制御ソフトで設定されたショートカット操作(デフォルトで有効な場合あり)を使用するなどで横スクロールが可能
トラックパッド利用時は、2本指で横にスワイプすることで横スクロールが可能
スマホ/タブレット利用時は、横にスワイプして横スクロールが可能

これらの操作は一般的な操作であり、スクロール可能な殆どの場合に利用可能な操作である。

デッキUI

デッキUIは複数のカラムを横に自由に並べることが出来るUIである。(TweetDeckなどに近い形式のUI) カラム単体は、縦にスクロールすることが想定される要素である。スマホでの利用はあまり想定されていないようであるが、ユーザー自体はそれなりに存在すると認識している。(PC環境でもMisskeyを利用している場合は、同じカラム配置が利用出来るメリットが大きい?) ※Twitterにおいても、かつてはスマホでTweetDeck形式のUIが扱えるMarinDeck等のアプリの利用者が一定数居たことから、需要は存在していると考えられる。

デッキUI上でのスクロールに関しては、

しゅいろさんは、縦にスクロールする想定の要素であるカラム上で横スクロール操作が可能になることは一貫性がないと認識している
- 横スクロールしたい場合は、カラムのヘッダ部分か、カラム間のマージンを広くしてその部分でスクロールすることを想定している
私などは、デッキという横スクロール可能な画面の中に、縦スクロールを行えるカラムが含まれているという認識であり、タイムライン上のノート等の領域においても横スクロールが可能であることが自然である(そうでない方がUIとして一貫性がない)と認識している
- また、スマホ環境などではヘッダ部分は遠いほか、マージンを広く取るとデッキUIの強みが半減すると感じている
- (ただし、これを実現しようと思うとスクロールイベントを伝搬させるのが若干複雑なのかも)

(微off-topic: デッキとカラムの関係では横と縦で直交していますが、同じ方向にスクロール可能な要素が二層になっている場合でも、内側の要素がスクロール限界まで行くと、次いでそのまま外側がスクロールされる…のような動きが通常のスクロールであるという認識があります。)

現在の状況

マウス/トラックパッド: Pull to Refreshの状態に依らず、任意の横スクロールがカラム上で不可能(空白領域のみ可能)
- Pull to Refreshにかかわらず、縦/横スクロール可能な領域が固定されていると思われる
  - 追記: Pull to Refresh無効時の挙動を開発者ツールで確認していたら、急に無効時は横スクロール出来るようになってしまったので謎、有効時は依然不可です
スマホ/タブレット(iOS系列): どの領域でも常に横スクロールが可能
スマホ/タブレット(Android): Pull to Refreshが有効な場合のみ、横スクロールがカラム上で不可能(空白領域のみ可能)

なお、Pull to Refreshと横スクロールの可否は(厳密には)実装上は関係がなく、単に現状の仕様であるとのこと。

解決策の検討

Pull to Refresh
- マウス利用時により良い操作が実装出来そうであれば検討したい
デッキUIにおける横スクロール
- 横スクロールの可否はオプションで切り替え可能にする
  - スクロール出来る自然さと、スクロール出来ない自然さの意見の溝が埋まらなさそうであるため、このまま平行線であれば、個人の好みによるものとして扱いたい
  - (デフォルトは従来の挙動である横スクロール可が望ましいと私は思いますが、オプションさえあればどちらでも構わないと思います)
  - 代わりに、Pull to Refreshの切り替えによる横スクロールの挙動の差を無くす (横スクロールの可否はこのオプションでのみ決定されるようにする)

いかがでしょうか?

May 19 '25 13:05 Sayamame-beans

スワイプでのタブ切り替えと干渉する問題もあるわねどっちを優先するか

May 22 '25 11:05 syuilo

スワイプでのタブ切り替え

メインカラム用の機能とかです? (あまり存在を認識しておらず…タブってなんでしょう)

May 22 '25 11:05 Sayamame-beans

主にメインカラムになりそうだけどそこに限らなそう

May 22 '25 11:05 syuilo

タブはなんか見出しが上に並んでてコンテンツを切り替えられるやつ

May 22 '25 11:05 syuilo

スワイプでのタブ切り替えと干渉する問題もあるわねどっちを優先するか

スマホかつデッキというユースケースがどれくらいあるかによるけど、デッキのときは横スワイプオフみたいな設定を追加してそれをデフォルトにするのもありかも

May 22 '25 11:05 kakkokari-gtyih

タブはなんか見出しが上に並んでてコンテンツを切り替えられるやつ

ユーザーページとかのやつです?

May 22 '25 11:05 Sayamame-beans

デッキ環境における"カラム"においては、少なくとも現段階ではメインカラムしか該当しなさそうです。 (今後何かが追加される可能性も加味するなら更に悩ましいですが…)

May 22 '25 11:05 Sayamame-beans

個人的には、そのようなカラムは(他と違って)"横スクロールも想定されたカラム"になるので、そのカラムの領域内ではカラムに対する横スクロールが優先されるような感覚はあります。 (が、サイトやアプリによっては、「外側の横スクロール(スワイプ)用の判定が、表示されている領域の端の方にだけある」といった作りで両立している場合もあるイメージはあります。これは余白部分ではなく、実際に内容が表示されている領域内の端の方です。)

May 22 '25 11:05 Sayamame-beans