ãæå¹ã«ããæ¹æ³ãã覧ãã ããã, å®å¿ãã¦ä½¿ã£ã¦ããã ãããã«, Javascript By following users and tags, you can catch up information on technical fields that you are interested in as a whole, By "stocking" the articles you like, you can search right away.
ブラウザ・Google Chromeで突然日本語入力ができなくなることがあります。日本語入力ができないと、検索やサイトの利用に支障をきたしてしまいますよね。この記事では、Google Chromeで日本語 … インストールしました。 all text restarted by Henkan key is deteled. ホットペッパーのGotoイート終了予告が出ましたが、今から今月の残り日数全てに予約を入れてもポイントは入りますか？ほぼ毎日キャンペーンを利用しているのですが、先ほど予約受付の終了予告が出ました。 身に覚えが無いのでその時は詐欺メールという考えがなく、そのURLを開いてしまいました。
æ¥æ¬èªå
¥åãã«ããè¦ã, Google Japan Developer Relations Blog: æ¥æ¬èªå
¥å, Google
そもそも、そんな不具合があるのなら一部の人さえもアップデートは停止されているだろうと... Windows 10 Version 20H2 通知入るが入れるべき？2020年11月11日、正午過ぎ、Windows UPDATEが入り、
WebフォームでIME状態を制御するということはユーザの知らないうちにモードが切り替わっているということであり、このことをユーザに伝える手段がない場合ユーザを混乱させるだけになってしまう。, 株式会社愛宕はIT技術の提供のみでなく、企画、提案、保守運用などインターネットのあらゆるニーズにお応えいたします. 開いた後は発送状況を確認できるサイトに移動することは無く、ポップアッ... https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q11209649996. * active: IMEをオンにする。ただし、ユーザはオフにする操作ができる。 ããå©ç¨ãã ããã, Windows //!!! この記事をご覧になっている皆さん、普段Googlechrome アップデート終了後 IMEがキャンセルされるが、IMEウィンドウが裏で生きている(※H) IMEが正常にキャンセルされる ※F：focusがTEXTノードのとき、consoleでnode.dataを指定すれば変更前が取れているのがわかるが、単にnodeを指定すると、変更後のテキスト文字列が表示される。おそらくconsoleの実際の表示タイミン … æ¥æ¬èªå
¥å ãã«ããã©ã¼ã©ã, Google æ¥æ¬èªå
¥åéçºèæ¯ï¼ã³ããã¯ï¼.
また、スマートフォンは全く対応していない。 MS Wordなどでも効かないので、アプリがIMEを制御しているような場合にダメなのかなとも思うのですが、ChromeはIMEのON/OFFくらいしか制御してなさそうなんですよね…
関連記事. 時にはtext以外の要素も使いたいので、独自のDOM操作をしたい。そうなると、入力領域はtextareaではなく、contentEditableを設定したdiv等にしたい。このとき、殆どのブラウザではexecCommandでundoとredoができる。しかし、一度でもJavascriptからDOM操作すると、execCommandによるundo/redoは上手く動かなくなる。結局は独自のUndo/Redo機構を作りたくなる。, この際の鬼門がIME入力の検知。ブラウザごとの数々のバグを、試行錯誤して乗り越えたので、情報共有として公開します。間違いもいっぱいあると思いますが、ご容赦ください。ご指摘も大歓迎。, ※この記事は公開しないつもりでしたが、2020年1月にEdgeが生まれということで、一番の鬼門だったEdgeの情報を残したくなり、ここに至ります。, 文字入力をUndo/Redoに対応させることを前提にどこで記憶させるか。基本的にIMEによりcompositionend前であっても、つまりcompositionupdateまでの時点でも、DOMは変更されてしまっている。preventDefault()も効かない。よって、他のキー入力の様にJSで自前でDOM操作できない。よって、compositionendイベント発火のタイミングで、IMEによるDOM操作がどのようなものであったか調べて、Undo/Redo履歴に記録する。IMEによるDOM操作は次のどれか。, 一つ目のケースか、二つ目のケースかを判断するだけなら、TEXT_NODEがfocusNodeになっているので、composition系のイベントハンドラでfocusNode.length===event.data.lengthであるかどうかを調べればよい。trueなら後者である。2番目のケースの場合にはノードが追加されるだけでなく、既存のBRノードが削除される場合がある。これに関しては後述する。, 難しいのは三つ目のケースがあることであり、そもそもこれを他の２ケースと区別することが難しい。, 基本的にはcompositionstart, compositionupdate, compositionendでイベントを取得できる。, compositionstart: IMEの最初の入力の"直前"にイベントが発生。文字入力前のDOMやカーソルの状態を知るにはこれを使う。, compositionupdate: IMEで文字が打たれる、文字が消されるたびに発生。, compositionend: IMEの入力終了時に発生。入力終了のケースは次の3通りあり、どれでもこのイベントが発火する, 入力中および入力終了時のIMEによる文字列は、イベントハンドラの引数のdataプロパティーで取得できる。, (注)ただしEDGEはdataの内容が間違っている場合がある。たとえば「あいうえお」と入力すると「おえいうあ」という文字が返ってくる場合や、決定前にbackspaceを押して削除しても消えていない場合などがある。よって、EDGEではdataの内容を信じて使うことはできない。, まずキー入力に対して発火するイベントは次の表のになる。compositionupdateは文字入力の度に毎回起こる。矢印キーによるフォーカス移動ではcomposition系のイベントは発火しない。しかし、スペースキー等による変換では候補を変える度に発火する。, ※A：おそらくEdgeのバグで、これらの方法でIME入力を完了させた場合には、続けて別の文字入力を行った際に、先のIME入力内容が再びDOMに挿入されてしまう。その時は、compositionstart, compositionupdate, compositionendが一度ずつ発生し、かつ、event.dataには先のIME入力内容の全ての文字列が格納されている。これを利用して、回避動作を実装しなければならない。, ※B：前回のIME入力から一度もカーソルを動かさずにctrl + backspaceを押した場合だけ再入力になる。また、クリックや矢印キーで入力範囲を抜けて完了した場合にもカーソルが動いたとみなされて、再入力はできない。, ※D：2度発火する。1度目は再変換前のfocus位置が取得でき、2度目は再変換領域の末尾のfocus位置が取得できる。, ※E：IME領域を抜けるタイミングだけはkeydownイベントが発火する。ここでpreventDefaultすることで、IME領域から抜けられなくできる。, compositionstartイベントトリガーで取得できる状態、および、可能なプログラマブル操作は次の表の様になる。getSelection()で取得したselectionオブジェクトのcollapseメソッド等を使ってプログラマブルにfocus移動した場合、および、イベントハンドラ内でDOM操作をした場合の動作も記載する。, ※F：focusがTEXTノードのとき、consoleでnode.dataを指定すれば変更前が取れているのがわかるが、単にnodeを指定すると、変更後のテキスト文字列が表示される。おそらくconsoleの実際の表示タイミングではdataの中身が更新された後だからだろう。前者の場合には文字列が渡されていて更新されないのだろうと推測される。, ※G：compositionstart発火に続いて、compositionupdateを飛ばしてcompositionendが発火する。この時のevent.dataの値は空であり、DOMも何も変化しない。, ※H：次にfocusを合わせると、IME入力が復活してしまう。しかもcompositionstartは発火しない。, compositionupdateイベントトリガーで取得できる状態は次の表の様になる。ただし、compositionupdateイベントはキー入力があるたびに起こるので、あるキー入力があってから、次のキー入力の時点では、DOMは変更されている。ここで記述した「変更前のDOM」とはあくまで、直近の1回のキー入力である。また、フォーカス位置に関しては、必ずしもIME入力中の文字列の末尾とは限らない。入力途中で矢印キーによってフォーカスが移動している可能性がある。フォーカス位置に関しては全てのブラウザで動作が異なる。, ※I：間違った内容が格納されている場合がある。おそらくbug。ただし、検証した限りでは、compositionstartに続く一度目のcompositionupdateの発火では正しい値が入る。前述の※Aに対する処理で、クリック等でIME入力を終了させてた、次の入力でのバグ挿入でも、一度目のcompositionupdateではevent.dataに正しい文字列が入っている。ただし、一文字とは限らない。, ※J：IME入力開始の場所が既存のTEXTノードでなかった場合は、新しいTEXTノードが追加されるが、変換候補を変える度にTEXTノードのインスタンスが変わる。IMEの入力開始場所がTEXTノードだった場合は変換候補を変えてもインスタンスは変わらない。, compositionendイベントトリガーで取得できる状態は次の表の様になる。取得できるフォーカス位置に関しては、Edgeは入力完了直後のフォーカス位置である。これは、入力途中で矢印キーによってフォーカスが移動していた場合にはその位置が帰るし、入力領域外をクリックして完了した場合にはクリック場所のフォーカス位置が帰る。一方で、ChromeとFire Foxでは入力完了時のフォーカス位置に依らず、IME入力領域の末尾が帰る。, ※K：クリックや矢印キー移動で入力領域外へ出たことによるcompositionend発火の場合は、取得できるフォーカス位置も領域外の場所となる。, ※L：IME入力領域内で矢印キーでフォーカスを移動させていようが、IME入力領域外をクリックして入力完了させようが、取得できるカーソル位置はIME入力領域の末尾である。, IME入力直後にctrl+backspaceキーを押すと、再変換モードになる。これはIMEソフト自体のショートカットであるもよう。ただし、Chromeは再変換モードにならない。, また、テキストにカーソルがあったいる場合、もしくは領域選択している場合に、「変換」キーを押すと、IME再変換モードに入る。これはIME入力直後である必要はなく、任意の場所で可能。IMEソフト自体のショートカットである。こちらはChromeでも動作する。, ※M：領域選択されていなかった場合、focus位置より前にある文字列だけを再変換することはなく、focus位置直後の文字列か、focus位置を含む文字列の変換となる。よって、取得できるoffsetは絶対に末尾ではない。, ※N：「変換」キーで再変換を開始した際に、compositionstartで取得できるDOMが、それよりもさらに前の状態に巻き戻ることがある。どうやら一つ前の動作がIME入力だった場合に、その直前まで巻き戻るように振る舞う。, 通常の新規入力の場合と、ctrl+backspaceや「変換」キーによる再変換の場合で処理が異なる。新規入力の場合はIMEによるDOM操作は文字列の追加のみであり、それ以外に既存のDOM内容変更はない。よって、入力された文字列を取得して、compositionendイベントハンドラに置いて、英数字と同様の文字列のInsert処理をしたものとしてUndo/Redoの履歴に登録してやればよい。一方で再変換の場合は、既存の文字列の一部が置き換わることとなる。ここで、置き換えの対象となる既存の文字列(の範囲)をEdgeでは取得できそうにない。よって、入力focusを持っているTEXTノードの全内容を置き置換したものとしてUndo/Redoの履歴に登録する。compositionstartイベントハンドラで入力開始時のTEXTノードの全内容を保管しておいて、compositionendイベントハンドラで入力終了時のTEXTノードの全内容を取得、これらが丸々置換されたものとする。必要なメモリが大きくなりがちで残念。, 問題は、新規入力と再変換をどのように見分けるか。少なくともEdgeにおいてはcompositionstartイベントだけで、判別することはできなかった。しかし、compositionupdateと組みあわせて判別することはできた。ここでのcompositionupdateは、compositionstartの発火後から一回目の発火のcompositionupdateイベントとする。この時、判別に必要なプロパティーは以下の表で分かる通り、IME入力開始時点と、最初の更新直後のIME入力領域の文字列長さを比べればよいことがわかる。(c)==1となっていれば新規入力である。, ここで、(b)はcmpositionupdateの初回のevent.dataは壊れていない(経験則)ことから取得できるが、(a)を取得するすべはない。しかし、, (d) = (compositionupdateにおけるTEXTノードの長さ) - (compositionstartにおけるTEXTノードの長さ), とすると(c)==(d)であり、(d)ならばgetSelection().focusNode.lengthの差として取得できる。よって、(b)==1かつ(d)==1が満たされていれば新規入力と判断してよい。, 話は変わって、compositionstart発火時点ではTEXTノードでありながら、compositionend発火時にはそのTEXTノードは既にDOMの一部ではなくなっている場合がある。さらに、その間にcompositionupdateは一度も起きない場合がある。これは、「変換」キーで再変換に入った場合に、TEXTノードの全ての文字列が変換対象となり、かつ、変換候補の変更をせずに、backspaceキー等でIME入力領域の文字を全て消してしまった場合である。この場合の処理をcompostionendで捕まえて、TEXTノードの削除と、場合によりBRノードの追加をUndo/Redo管理に登録しておく必要がある。, IME入力開始のタイミングで、compositionstartが発火する前に、keydownが発火する。そのkeydownイベントハンドラにて、event.key=="Process"かつevent.composed==trueとなっている。この時、event.codeにも（信頼できそうな）キーが入っている。例えば新規入力開始した場合、「あ」をAキーを押して入力したとすると、event.code=="KeyA"となっている。一方で、「変換」キーを押した場合は、event.code=="Convert"となっている。, 全角スペースの問題に関しては、keydownイベントハンドラでevent.key=="Process"かつevent.composed==trueかつevent.code=="Space"をキャッチして自前で全角スペース入力。, 解決(問題１)IME入力のキャンセル方法：this.blur()に加えて、preventDefault()が必要。これで一旦キャンセルできる。しかし、次にクリック等でもう一度カーソルを合わせると、そこでIME入力のサブウィンドが出てきてIME入力を再開してしまう。しかもcompositionstartが発火しない。これを防ぐには、alert()で何らかのメッセージを出す。するとなぜかIME入力が再開しなくなる。結局、IMEのキャンセルはChromeでは次のようなコードになる。, （こんな裏技を使わなければいけないweb開発って、すごい世界ね。早くネイティブC++に戻りたい。。。）, 今のところ、仕様の違いはあれ、特に目立ったバグが無い。おそらく開発経緯によってマヒしているところがあって、Edge→Chrome→Fire Foxという順にIME入力の対策コードを作ってきたので、最初の二つで実装した対応策の流用で何とかなっている。, IMEで入力を行うと、既存のBRノードがDOMから勝手に削除される場合がある。次の場合に起こる。, まず、pタグやliタグなどの中身が空の場合、ブラウザは一般的にbrタグを挿入して、段落やリストが確実に存在するようにする。これはレイアウト上の問題だけでなく、カーソルがそこに合わせられるかどうかという問題にも関係している。具体的には、空のpタグは次のようになっている, ここで、空の段落にカーソルを合わせてIMEであいうえおと入力すると次のようにbrタグが自動で消える。, Undo/Redo対応するには、compositionendイベント発火時に、BRタグの自動削除も検知して、Undo/Redoの記録として残しておく必要がある。, IMEによってBRタグが自動削除されてしまうと、compositionend時にそれをUndo/Redo履歴に残すだけでは済まない問題が起こる。具体的には、削除されてしまったBRが、それ以前のDOM操作でノードとして追加されたものだった場合である。次のような例を挙げる。, さて、ここで最初に起こり得る問題は、2-2の操作でBRノードが消えたことを履歴に残す部分である。消えたことを履歴に残す関数として次のようなものを想定する。, ここで、nodeは消えたBRノードのインスタンス、parentはBRノードの親ノードのインスタンスで、offsetはBRノードの親ノード中での位置である。基本的にはだいたいこのような関数になるだろう。インスタンスを記録するのは、もし消したいノードが子ノードを持っているときに、その子ノードのインスタンスをUndo/Redo履歴の中で保持して、GCによるメモリ開放を防ぐ目的がある。, 問題は、消えたことを記録したいのに、BRノードは既にIMEによってDOMから消えてしまっており、インスタンスを取得することができない点である。幸い、BRノードは子ノードを持たないので、このインスタンスが消去されることがないが、そういうケースも起こるならば怖い。, 暫定的な処理として、ここでは、仕方ないので新規にBRノードを作成し、node引数に渡しておくことにしてみよう。, parentやoffsetはIME入力直後のフォーカス位置から適当に取得しておく。, そもそも最初にBRノードは1-2の操作で追加されており、そこではUndo/Redo履歴に次のように記録されているだろう。, ここでnodeには1-2で作成したBRノードのインスタンスが渡されている。これを基に、4-1の操作では例えば次のように、履歴を取得し、元に戻すDOM操作をするのではないだろうか。, 追加した、BRノードのインスタンスをnodeとして覚えているのだから、それをDOM上から削除(removeChild)すればよいわけだ。しかし、今回はこれで問題が起こる。なぜなら、2-2の操作で、記録されたBRノードの削除履歴では、1-2で追加されたBRノードとは別の、暫定的に新規に作ったBRノードのインスタンスが記録される。それが、3-2の操作によって復元され、DOM上に追加されることになる。よって、4-2の操作の時点では、DOM上に存在するのは2-2で作ったBRノードであり、1-2で作ったBRノードではなくなっているのである。よって上記のremoveChildは失敗する。, エラーメッセージはさておき、offsetを使って取得したtargetは2-2で暫定的に追加したBRノードであり、実際にDOM上にの存在するものである。これをremoveChildすればよい。, ただし、この回避策はIMEによる自動削除の対象があくまでBRノードだったから有効なだけである。もし、子要素を持つようなノードが削除された場合にはこの手は使えない。何とかして削除前のノードのインスタンスを知りたい。, IMEによって自動削除されるまえに、BRノードのインスタンスを取得して、何らかの変数に保持しておきたい。しかし、compositionendやcompositionupdateイベントの発火時には既にDOM上からBRノードは消えて決まっている。一方で、compositionstartイベントの発火時には、DOM上にBRノードが残っている(少なくともEDGE, Chrome,Fire Foxでは)。そこで、compositionstartイベントのイベントハンドラで次のような処理を行う。, つまり、IME入力の直前のカーソル位置にBRノードがあれば、それを保護用の変数に格納しておいてインスタンスがGCされないように保持しておくのである。, そして、先の操作手順の2-2で、BRノードの削除の履歴を残す際、先程までは暫定処理として新規のBRノードを行うのではなく、ここで保護したオリジナルのBRノードを引数に渡す。つまり、次のようになる。, この様にすれば、一貫してオリジナルのBRノードのインスタンスが履歴に残り、手順4-2においてtargetとなるBRノードもオリジナルのままであるので問題が起こらない。, 今のところChrome,EDGE,Fire Foxではこの方法で上手く動いている。特にIMEによってBRノードが自動削除される点は苦労したが、compositionstartイベントでインスタンスを保護することで問題は回避できた。, しかし、この方法が有効であったのは、あくまで開発者側が「IME入力によって、ある条件でBRノードが自動削除される」ことを知った為である。IME入力では、まだこちらの認識していない自動DOM操作が行われている可能性があり、その場合にはまた別の打開策が必要となる。, さて、contentEditableで独自のブラウザのexecCommandに頼らず、独自にUndo/Redo履歴を残す場合を想定して、IME入力の扱い方について纏めた。, どのブラウザも英語圏で作られているためか、IME入力に関してはバグが多い。仕様が決まっていないことも問題だろうが、おそらく仕様が決まったところで実装モチ開発者のモチベーションが上がらないだろうなというのは理解できる。動作チェックできる環境も少ないだろうし、なにより本人がIME入力の方法に慣れていないだろうか。, 結局はブラウザごとにIME部分のコードを作り分けることとなった。本当にきつかった。, 将来、今回の様な回避策が取れない場合には、そもそもUndo/Redo履歴にノードのインスタンスを保持させるという方法自体を変える必要がでてくるかもしれない。たとえば、ユーザー入力の度にDOMをクローンしたりして、ノードおよび子要素ツリーを残しておけば（場合によってはテキスト形式ででも）、そもそもインスタンスが残らない。ただ、インスタンスを残せれば===演算子による比較が使えて楽だったり、利便性は高いので、可能ならインスタンスを残した今の形式を続けたい。, そして、どこかのタイミングで、開発したエディタ「NowType」を公開したいなぁ。。。.
多分、次のバージョン20H２が配信されたからだと思うのですがこの先、windo... Windows10 大型アップデート(20H2)が更新画面に現れました初期は不具合やバグ等考えて1909で放置で良いでしょうか？しばらく, windows 10 20H2にアップデート後 htmlファイルの既定 不具合なのかバッグなのか？ //then original br is kept before input IME//, compositionstart(※C), compositionupdate(※D), 初回に生成された場合のみ、変換候補が変わるたびにインスタンスが変わってしまう(※J)。, 入力直前のフォーカス位置。nodeは必ずTEXT_NODEであり、offsetはIME入力領域の末尾。, DOM操作は実施され、IME入力がキャンセルされる(compositionend発火)。, DOM操作は実施され、IME入力がキャンセルされる(compositionend発火)。また、もう一度「変換」キーを押すと、先の選択領域の変換候補が、新規に追加される形でcompositionstartが新たに発火する。, IME入力領域の末尾。ただし、クリックや矢印キーで入力領域を抜けた場合は、入力領域外になる。, 再入力領域のが選択領域として認識され、anchorが末尾、focusが先頭になる。TEXT_NODEのfocusのoffsetが0の場合は親nodeが返る場合がある。, DOM操作は実施され、その上でIME入力が起こる。ただし、変換中となる文字列は選択領域とは変わっている。, 1度目の発火は再変換直前のfocus位置、2度目以降の発火は常にIME入力領域の末尾, (a)compositionstart時のIME入力領域の長さ(Edgeでは直接取得できない), (b)一回目のcompositionupdate時のIME入力領域の長さ(event.data.lengthで取得), Edge, ver. 元々はIEからMS-IMEを制御するためのMicrosoft独自仕様である。, 非対応ブラウザについても一応の代替手段があるが、全く同じ条件で実装できるわけではない。 日本語入力 確定 … Help us understand the problem. Chrome：75.0.3770.100（64bit） 1．1回目、再起動が自動で行われる。 この入力フォームに対して入力を始める前に入力できる文字種に応じた入力モードになるようにIMEを制御したいという要件が（特に業務アプリでは）ありうる。
Help us understand the problem. ãã®ã½ããã¦ã§ã¢ããã¦ã³ãã¼ãããããã«ã¯ JavaScript ã«å¯¾å¿ãããã©ã¦ã¶ãå¿
è¦ã§ããJavascript
「keyup」時にキーコード「13」が渡され、IME入力中の変数の値がtrueの時はIME入力確定; Chrome. 入力を確定したときの [Enter] かどうかは、keypress イベント が発生したかどうかを見ることで判別できます。 IME変換時 keydown → keyup IME変換しない時 keydown → keypress → keyup. 他にもバッグやエラーの報告あるよです11/11に、アップデートしました。 * inactive: IMEをオフにする。ただし、ユーザはオンにする操作ができる。 個数は2個、手動で作業を行い、1時間弱と要してしまう。
旦那は私の顔を上の中と言います。だったら上の上がいたら私は捨て... ゴートゥーイート 11月中に終了する可能性高いですか？キャンペーンに気付いてなくて最近予約し始めたので 現在の対応ブラウザは、IE11、Edge、FirefoxでChromeとSafariは対応していない。 原因不明だが、再起動が2回連続で行われ... windows10バージョン1909ですが、updateについ最近までversion2004の機能更新プログラム（まもなくwindows10may2020・・・・まだ準備が完了してません・・・・）とメッセージが表示されていたのですが更新までいかずに表示されなくなってます。 Windowsの画面「システム修復が」自動進行する。 文字入力をする際にエンターキーで文字を確定する前にバックスペースキーを使い1文字でも消してしまうと入力したその確定していない文字が消えてしまう&その際に勝手に数行改行されてしまうこともある ... Chromeは最新バージョン、GoogleのIME … @SuiU_ff14 【Chrome+MS-IME】入力した文字が確定時に消える不具合について（BackSpace→Enterで消える現象） これかなー？ Hachi@Typhon鯖(@HHachimaru) - 2019/11. 途中、唸るような音が断続的にしました。 昭和のワープロのように左下に変換候補が出て、確定すると流し込まれる(一部のATOKも似た症状らしい)。 Japanist 10にしたら解決した！ — 西野久好 (@towanoe) 2019年6月7日. 設定もいろいろ見たのですがそれらしいものはなく…