WordPressで「左利きのユーザーほど遭遇しやすいバグ」が7年越しに修正へ

「touchstart」と「click」って、どう違うの？タップするときに両方発動するわけじゃなくて、どちらか一方が選ばれるってこと？

touchstart と click は、同じタップ動作でも「発火するタイミング」が大きく異なります。touchstart は指が画面に触れた瞬間、つまり「タッチダウン」の時点で即座に発火します。一方、click は指を離した後に発火するイベントです。 ここが重要で、両方が発火するわけではなく、むしろ「どちらを使うか」で挙動が変わってしまうんです。touchstart を設定していれば、ユーザーがまだ指を動かすかどうか決めていない段階で処理が走ります。記事の場合、左手でスクロール開始しようと指を置いた瞬間に、返信欄が開いてしまった。ユーザーの意図を確認する前に動いてしまうわけです。 click に統一すれば、指を離すという「明確なタップ完了」を待ってから処理するため、スクロール途中での誤反応が起きにくくなります。昔は古いブラウザの遅延回避のため touchstart が必要でしたが、今のブラウザなら click で十分。むしろ touchstart の方が余計なトラブルを呼び込む存在になってしまってたのかもしれません。

WordPressでブログやメディアサイト運営してる自分のサイト、もしかして今この不具合が発生してたりする？自分が気づいてないだけで、左手ユーザーからのクレームが届いてるのかもしれない。

実は、あなたが気づいていない可能性は結構高いと言えそうです。 なぜなら、このバグは「使い方が一致した人だけに起こる」からです。記事に出てくるテレンス・イーデン氏が7年間気づかなかったのは、彼が右手でスクロールしていたから。自分のサイトを毎日確認していても、自分の操作パターンと違えば問題は見えません。 左手ユーザーがクレームを送っているかどうかは、あなたのサイトへのコメントやお問い合わせを見返すとわかるかもしれません。「コメント欄が勝手に開く」「返信ボタンを押した覚えがない」といった指摘がないか。WordPressのバージョンを確認すれば、7.1以降なら既に修正されています。 ただ、気づかないクレームもあります。スマートフォンで閲覧中に不快なことが起きても、わざわざメールで報告するのは手間です。その人は単に「このサイト使いづらい」と感じて二度と来なくなっているかもしれません。その損失は数字には表れにくいのかもしれません。

なぜ2019年に報告されてから7年も放置されてたの？バグ報告があっても優先度が低かったのか、それとも誰も重大視しなかったのか。

オープンソースのバグ報告というのは、実はボランティアで動いてる側面が大きいんですよね。WordPressも企業からの支援を受けていますが、全機能を完全に監視する専任チームがいるわけではない。報告があっても、その修正案が「簡潔で、テストしやすく、他に影響を与えない」という条件を揃えて初めて、開発ロードマップに乗りやすくなる。 このバグの場合、問題自体は確認されていたのに、修正が提出されなかったのが大きい。「スクロール時にコメント欄が開く」という現象は確かに不便ですが、右手で操作する大多数のユーザーには関係ないバグで、影響範囲が限定的に見えたのかもしれません。修正の優先順位は「影響の大きさ × 修正の難しさ」で決まることが多く、このバグは「影響は小さい」と判定されていた可能性があります。 決定的だったのは、イーデン氏が実際に修正コードを用意したこと。数行削除するだけという簡潔な解決案があれば、開発チームの判断も変わる。ボランティア主体のプロジェクトでは、問題提起よりも「完成度の高い解決策を差し出す側」の声の方が、結果として大きく響く構図になりやすいと言えそうです。

これって『当事者じゃない開発者には見えないバグ』という話だけど、世の中には他にも『特定の使い方をしてる少数派だけに起きる問題』がたくさんあるんじゃないの？

その通りですね。このバグが7年も見落とされた理由は、開発チームが「多数派の使い方」を基準に設計・テストしているからに他なりません。 WordPressの開発者たちにとって、右手でスクロールするのは当たり前の動作。だからコードをレビューするときも、テストするときも、その前提でしか考えていない。左手でスマートフォンを触る使い方は「想定外」だったわけです。 似た問題は至る所にあると言えそうです。たとえば、画面の拡大率が150%以上の利用者だけが見える表示崩れ、古いOSやブラウザ環境での不具合、視覚障害者が使うスクリーンリーダー対応の漏れ。高速な通信環境を前提としたアプリは、低速回線で潜在的なバグを抱えているかもしれません。 ここで気づくべきは、「見える化できるかどうか」の問題だということです。左利きユーザーの報告がなければ、このバグは永遠に存在しないことになっていた。つまり、少数派の声がなければ、多数派向けに最適化されたシステムは、実は穴だらけなのに気付かないまま進み続けるということになります。 完全に網羅するのは不可能ですが、開発側が意識的に「想定外」を想定する姿勢が、実はかなり重要な気がします。

7年放置された不具合の修正コードがわずか数行の削除だったなら、なぜこの修正にここまで時間がかかったの？修正を難しくしてた何か別の理由があったのか、単に誰も着手しなかっただけなのか。

オープンソースプロジェクトの宿命みたいな話だと思います。 修正自体は簡単だから、むしろ「簡単だから後回しにされやすい」という逆説があるんですよ。緊急性が高い不具合なら優先度が上がりますが、これはスクロール時に時々発生する邪魔な問題くらい。困ってはいるけど、サイトが壊れたわけじゃない。 WordPressの開発には無数の課題があって、限られたメンテナナーの時間を取り合う状況です。修正の難易度が低いほど、修正の価値も低く見積もられやすい。着手するなら難しくて重要な問題から、という優先順位の付け方で自然と後回しになってしまう。 興味深いのは、7年経ってイーデン氏が「自分で修正を出す」という動きをしたこと。報告しても動かない課題を自分で解決する。これはオープンソース特有の構図で、ユーザーが開発者になる瞬間でもあります。修正が通った背景には、誰かが「これ自分で直そう」と動いたことが絶対的に必要だった、ということなのかもしれません。小さな修正こそ、誰かの主体的な一歩を待ってたのかもしれません。