Chrome 65 で Slack の IME がおかしい
◆ IME 変換中の一文字目が自動確定される
◆ ｋおうなる
◆ Chrome 65 の変更点が影響してるみたい
◆ ｋおうなる
◆ Chrome 65 の変更点が影響してるみたい
最初の文字の入力が自動確定してしまいます
「わたしは」って打ったはずが「ｗあたしは」になります
一文字目が母音でも IME の変換対象からはずれるので「明日は」と打とうとしても「あ下は」のように 2 文字目以降だけ変換されます
行の最初の一文字全部がこうなって Shift-Enter などで 2 行目を打つ場合もうまく入力できません
最初の 1 文字だけなので とりあえず半角空白を最初に入れれば対策できます
急に打てなくなってページがおかしいのかな ブラウザがバグったかな IME かも などと思ってリロードしたり IME 切り替えたりしましたが改善しません
他のタブだと問題なくて Slack のみです
他のページいろいろ試したのですが発生しませんでした
メインのチャットだけでなく検索ボックスでも発生します
最初は Chrome のバージョンアップとは疑わなかったのですが ググってみると Twitter で同様の報告がいくつかありました
Chrome のアップデートで起きていると言われていて 私もそう言えばアップデートしたばかりだったので Chrome が原因のようです
常に機能追加しているモダンブラウザはこういう既存機能が動かなくなるのが困りどころですよね
そのせいで逆に更新を全くしない IE が好まれたりということもあります
なにをしたら起こるのか興味があるので今日は調べていたのですが結局わかりませんでした
Slack ほどの大きなアプリケーションだと devtools を開いてもソースが重すぎて Source タブで開くと Chrome が応答不能になって何も出来ません
コードは見ないで DOM を変えたりリスナをつけてどういう処理が行われてるかを想像するくらいしか出来ません
minify で人に読みづらく改行もない状態にして rollup 等でファイルをまとめて devtools からは重くて開けないようにしておくのが現在のページの解析を防ぐ良い方法なのかなとか思えるくらいです
単に minify したくらいだと devtools で pretty print してステップ実行すればどうなってるのかは比較的簡単にわかりますし目的のものをみつけるのもそう時間はかかりません
ですが devtools 上コードをまともに見れないならほとんど何も出来ません
ソースを直接ダウンロードしてエディタ上で目で見ていくなんてやり方を minify+bundle された JavaScript でなんてつらすぎます
わかった限りでは メッセージ入力するところは結構特殊な処理がされてるようです
まず今回起きてる動作ですが一文字打ったところで一瞬ポップアップが薄く出てすぐ消えています
入力がキャンセルされてるのか自動確定されてるのかそういう風な動きです
そのまま 2 文字目を打つと 1 文字目は確定されていて 2 文字目は通常の変換候補になります
それ以降は普通に入力して変換できます
IME の変換候補になっているときでも keydown 等のイベントは起きますが IME の確定などは JavaScript では制御出来なかったと思います
EventListener Breakpoints で keydown を監視して文字入力するとブレークポイントで止まります
ですがここでフリーズするので何が起きてるかはわかりません
ありえそうなのは focus の切り替えです
入力中に focus が変化した結果仕方なく IME が途中確定するのではということです
Slack では textarea でなく contenteditable を使っています
ちょっと変わった方法だけあってここが影響してそうな気もします
ですが contenteditable な div に onfocus と onblur をつけてみたのですが 入力中に変化はないようでした
また 入力ボックス全体をクローンして 2 つ並べるとちょっと変わったことが起きました
2 つめをフォーカスして文字を打とうとキーボードを押すと 1 つめにフォーカスが移って 1 つめの入力ボックスに文字が入力されます
blank ページでこの動きを再現しようとしたのですが keydown イベントで異なる contenteditable にフォーカスを移すと入力した文字が表示されません
preventDefault はしていないのですが文字入力が起きなくなっています
Slack の方では半角全角切り替えキーでもフォーカスが移動したので keypress や input ではなく keydown イベントで何らかの処理をしてるように見えます
ですが単純にフォーカスを切り替えるとフォーカス変更時のキーの文字を入力したりバックスペースキーで消したりできません
両方の入力ボックスに keydown リスナを付けると 1 度の入力で 2 回 (それぞれ 1 回) 実行されました
イベントを再発火させているのかと思って 試してみましたがイベントを起こしたところでやっぱり IME の変換候補に文字が追加されたり文字が消えたりはしません
考えてみると普段からイベントを起こしても文字を入力できないですし当然です
一文字目は JavaScript で textContent 等で入れてるとすれば 一文字目が IME の変換候補にならず確定するのはわかりますが その方法では 64 までも動いてないはずなので違うはずです
そもそも実際の処理では 1 つしかなくて focus の切り替えはイベントリスナでみた限り起きていないので直接今回の問題に関係してないように思います
そんな感じで結局よくわからなかったのでこのへんで諦めました
64 のときはリンクの見た目がわかる問題がありましたが JavaScript で動かなくなるような変更はそうはないと思うので単純に Chrome のバグの可能性が高そうですし
続き
「わたしは」って打ったはずが「ｗあたしは」になります
一文字目が母音でも IME の変換対象からはずれるので「明日は」と打とうとしても「あ下は」のように 2 文字目以降だけ変換されます
行の最初の一文字全部がこうなって Shift-Enter などで 2 行目を打つ場合もうまく入力できません
最初の 1 文字だけなので とりあえず半角空白を最初に入れれば対策できます
急に打てなくなってページがおかしいのかな ブラウザがバグったかな IME かも などと思ってリロードしたり IME 切り替えたりしましたが改善しません
他のタブだと問題なくて Slack のみです
他のページいろいろ試したのですが発生しませんでした
メインのチャットだけでなく検索ボックスでも発生します
最初は Chrome のバージョンアップとは疑わなかったのですが ググってみると Twitter で同様の報告がいくつかありました
Chrome のアップデートで起きていると言われていて 私もそう言えばアップデートしたばかりだったので Chrome が原因のようです
常に機能追加しているモダンブラウザはこういう既存機能が動かなくなるのが困りどころですよね
そのせいで逆に更新を全くしない IE が好まれたりということもあります
なにをしたら起こるのか興味があるので今日は調べていたのですが結局わかりませんでした
Slack ほどの大きなアプリケーションだと devtools を開いてもソースが重すぎて Source タブで開くと Chrome が応答不能になって何も出来ません
コードは見ないで DOM を変えたりリスナをつけてどういう処理が行われてるかを想像するくらいしか出来ません
minify で人に読みづらく改行もない状態にして rollup 等でファイルをまとめて devtools からは重くて開けないようにしておくのが現在のページの解析を防ぐ良い方法なのかなとか思えるくらいです
単に minify したくらいだと devtools で pretty print してステップ実行すればどうなってるのかは比較的簡単にわかりますし目的のものをみつけるのもそう時間はかかりません
ですが devtools 上コードをまともに見れないならほとんど何も出来ません
ソースを直接ダウンロードしてエディタ上で目で見ていくなんてやり方を minify+bundle された JavaScript でなんてつらすぎます
わかった限りでは メッセージ入力するところは結構特殊な処理がされてるようです
まず今回起きてる動作ですが一文字打ったところで一瞬ポップアップが薄く出てすぐ消えています
入力がキャンセルされてるのか自動確定されてるのかそういう風な動きです
そのまま 2 文字目を打つと 1 文字目は確定されていて 2 文字目は通常の変換候補になります
それ以降は普通に入力して変換できます
IME の変換候補になっているときでも keydown 等のイベントは起きますが IME の確定などは JavaScript では制御出来なかったと思います
EventListener Breakpoints で keydown を監視して文字入力するとブレークポイントで止まります
ですがここでフリーズするので何が起きてるかはわかりません
ありえそうなのは focus の切り替えです
入力中に focus が変化した結果仕方なく IME が途中確定するのではということです
Slack では textarea でなく contenteditable を使っています
ちょっと変わった方法だけあってここが影響してそうな気もします
ですが contenteditable な div に onfocus と onblur をつけてみたのですが 入力中に変化はないようでした
また 入力ボックス全体をクローンして 2 つ並べるとちょっと変わったことが起きました
2 つめをフォーカスして文字を打とうとキーボードを押すと 1 つめにフォーカスが移って 1 つめの入力ボックスに文字が入力されます
blank ページでこの動きを再現しようとしたのですが keydown イベントで異なる contenteditable にフォーカスを移すと入力した文字が表示されません
preventDefault はしていないのですが文字入力が起きなくなっています
Slack の方では半角全角切り替えキーでもフォーカスが移動したので keypress や input ではなく keydown イベントで何らかの処理をしてるように見えます
ですが単純にフォーカスを切り替えるとフォーカス変更時のキーの文字を入力したりバックスペースキーで消したりできません
両方の入力ボックスに keydown リスナを付けると 1 度の入力で 2 回 (それぞれ 1 回) 実行されました
イベントを再発火させているのかと思って 試してみましたがイベントを起こしたところでやっぱり IME の変換候補に文字が追加されたり文字が消えたりはしません
考えてみると普段からイベントを起こしても文字を入力できないですし当然です
一文字目は JavaScript で textContent 等で入れてるとすれば 一文字目が IME の変換候補にならず確定するのはわかりますが その方法では 64 までも動いてないはずなので違うはずです
そもそも実際の処理では 1 つしかなくて focus の切り替えはイベントリスナでみた限り起きていないので直接今回の問題に関係してないように思います
そんな感じで結局よくわからなかったのでこのへんで諦めました
64 のときはリンクの見た目がわかる問題がありましたが JavaScript で動かなくなるような変更はそうはないと思うので単純に Chrome のバグの可能性が高そうですし
続き
