Latest topics 近況報告

UxUの使い方の簡単な解説を書きました - Jun 13, 2008

会社のサイトのコンテンツが一新され、コンテンツにブログが加わりました。何をやってる会社なのか（何ができるのか）分からんと言われがちなようなので、みんながちまちまやってる内容をここに書いていって、「当社ではこういうことができます」的な宣伝材料にする、というのが一応の目的のようです。

で、自分もアドオン開発者向けの自動テストツールであるUxUの使い方の解説なんかを書いてみました。ツールの使い方というよりは、「はじめての自動テスト」みたいな感じになってしまってますが。自分自身がまだ自動テストのことをよく分かってなくて須藤さんとかにしょっちゅう「何考えてんだ（全然分かってねえな）……」的な指摘を受けてばかりなので、自分の理解レベルに合わせるとこんな感じになってしまいました。技術力とか実績とかのアピールの場のはずなのに、こんな低レベルな記事を載せてしまうと却って会社の印象に泥を塗ってしまうんじゃなかろうか、ということをamachangのエントリとか見て思いもしましたが、もう後の祭りです。

UxUのマニュアルのつもりで、またそのうちXUL/Migemoのテストでの利用例の解説の続きを書くかもしれません。

あと、サービス→Mozillaサポート　実績紹介→Thunderbird用アドオンと辿ったページでThunderbird用の地味なパッチもいくつか公開しています。中にはもしかしたら同種のアドオンがすでに世の中にある車輪の再発明な物もあるのかもしれませんが、探すより作った方が早かったんで……

Mac版Firefox 3正式版に、日本人ユーザにとって結構致命的な問題が残ってしまいそうな件について - Jun 10, 2008

• norah'# : みんなガンガン Vote しようぜ!!
• Re: みんなガンガン Vote しようぜ!! - WebStudio
• kozawa のたまに気になること | Firefox3.0リリースとMac上でFlash問題について
• Re: Firefox3.0リリースとMac上でFlash問題について - WebStudio

norahさんやkozawaさんはあくまで、「Firefox 3正式版」と銘打ってリリースされる記念すべき＆世間の注目度も非常に高い＆日本でのシェア拡大を考える際に重要な意味合いを持つと考えられるバージョンにおいて、一般のライトユーザ（特にMacではSafariで問題が起こるサイトがあるからFirefoxを使っているという人すらいる状況（つまり「Firefoxの方がマシ」という評価がある）であることに注意）が「あ、こりゃ使い物にならんわ」と判断を下してそれ以後も評価の対象にすらしなくなる、そんな事態になりかねないような致命的なバグを抱えたままリリースすることの、マーケティング上の問題の重大さを考えて、こう発言しているということは分かる。そもそもnorahさん自身はMac使ってないはずだし（kozawaさんはどうか知らない）。

「Netscape 6正式版」が公開されたことが皮肉にもNetscapeブランドの死を決定付けた、という過去をこの界隈の人なら憶えていないはずはないだろう。その同じ轍を踏むことを恐れているのだと思う。であるならば、僕もそこは全く同じ気持ちだ。

個人的には、ライバルのOperaもSafariも対応してる状況で:nth-child()等の疑似クラスやtext-shadowが間に合わなくて（まぁ過去の状況とかを見るに、今物凄いスピードで進展していて、年末リリース予定といわれているFirefox 3.1にはまあ多分入るだろう、という風な所にまでこぎ着けていることが驚きなんだけど）、CSSのサポートでカタログスペック上は一歩も二歩も取り残されてしまっている（でも実装の堅実さではGeckoは優れてると思う。Safariはこのページをまともにレンダリングできないんですぜ？）という事も残念だなあと思う。というのは余談なのでさておき。

今回問題になっている件は、RC1でやっと問題が修正されたものの、その修正によって逆に新たな深刻な問題が発生してしまったために修正取り消しとなって、RC1までは問題なかった（修正済になってた）のにRC2の段階でその修正が取り消されてしまって、タイミング的に正式リリースまでの再修正が絶望的になってしまったという、非常に間の悪い事故という感じのケースなので、これについては誰を責めてもしょうがないなあと僕は思う。

それでも敢えて犯人捜しをするのであれば、件の修正がバックアウトされてしまう原因になった問題がもっと早くに発覚していれば再修正も間に合ったかもしれなくて、リリース直前になるまでその問題が見つからなかった（報告日は5月20日）事が問題なわけで、件の修正自体ももっと早くに行われていればここまでタイミングの悪いことにはならなかったかもしれないわけで、Mac環境でのテストが不十分だったことやコードを書く人が少なかったことが問題なわけで、それはつまりMacユーザからのフィードバックやコードを書ける人の協力が今の今まで無かったからということであって、口をあんぐり開けて待ってさえいれば品質のいいソフトウェアがお上から降って来るものと思ってボサーッとしてたMacの（特にIMEを使用する言語圏の）Firefoxユーザ自身のせいということであって、そこらへんは中野さんの言う通りであって、自業自得なんだと思う。

norahさんやkozawaさんではなく、norahさんのエントリに日本人に対する嫌がらせが酷いですねというコメントを残してるような人、こういうのがよくないなあと思う。「お客様気分」っていうのかなあ。この辺のことはkozawaさんのエントリにあるzzz氏のコメントに書いてあることにただただ頷くばかりだ。

という風に煽り気味に書いてみたけれども、まあ、Macに限らずFirefoxユーザにそういう姿勢の人が多くなるというのは、しょーがないのかなとも思う。単純にエンドユーザが増えればその分、開発に協力するような人の割合は減ってくるし。今までだったら「ボランティアで運営してる？　労力が不足してる？　しょうがねえなあ、ほっとけねえから俺も手伝ってやるよ」という感じで手伝う人が現れてくれてた所、メジャー感が出てくると「ああ、Mozillaって金持ちなんでしょ？　じゃ人手も沢山雇えるだろうし、オフィシャルの人に任せときゃ大丈夫だよね」という感じで手伝う人が減ってくる、そういう所もあるんだろう。

Mozillaの中の人（中野さんとかの技術畑の人じゃなくて、組織の運営やお金の工面を考えるような分野の人）には、そういう所の諸々の問題も解決する方向で色々頑張ってもらいたいものだなあ、と、無責任に希望だけ書き捨てておく僕も前述の類の人と同じ穴の狢か。

追記。今回話題に上っている問題で具体的に誰がどーいう不便を被るのよ？　という例としては、ニコニコ動画でコメントを付けるとかUSTREAMのチャットで発言する時とかに、直接日本語を入力できなくて、必ず他のアプリケーションかネイティブな入力欄に日本語を入力してからそれをコピペしないといけない、という感じです。ニコ動はまあFirefoxの今のメインのユーザ層はあんまり使ってないかもだけど、USTREAMを活用してる層とFirefoxのアーリーアダプター層って結構かぶってる気がするので、組長あたりはご愁傷様ということになりますなあ。ということでこれらのサービスをよく使うマカーな人はRC1を使うか3.0.1を待つかこのバグがFixされたことが確認されているナイトリービルドを使うか、といった感じになるかと思います。

追記。言及された先にコメントとして書いた内容をこっちにも転載しておく。自分としては、この件はあくまで様々な関係者に少しずつ責任があると考えていて、Macユーザ「だけ」が悪いとは思っていないけれども、Macユーザの責任がゼロだとも思っていない。ただ、その事を以ってMacユーザ全員を敵に回して「お前らもっとコミットしやがれ」と居丈高にギャーギャー叫びたいわけでもない。「あなたが使いたい物がどこにもないのなら、あなたが自分で作るしかない。使いたい物があっても作る気が無いのなら、誰にも文句は言えない。作る気がなくても使いたいのなら、賃金なり労力なりのコストを負担するのが当然。あなたのためにタダで働いてくれる都合のいい奴隷は、そうそういない。いまあなたがタダで利益を得られているとしたら、他の人がその人自身のためにやったことのおすそ分けを貰っているからにすぎない。おすそ分けが少ないぞと文句を言う権利はあなたにはあるけれども、それに応じる義務は誰にも無い。なんでおすそ分けをもっとよこさないんだ、と不満を述べる姿はただ滑稽なだけだ。」ということを、今無邪気に要求の声を上げていて自覚していない人には自覚してもらいたい、ということをここでは言いたかった。

対馬が韓国領に！！ - May 29, 2008

Download Dayということで、24時間以内のダウンロード数の世界記録を狙うそうです。まあIEが自動アップデートのアクセス数計測してそれを報告したら一瞬で100倍くらい記録更新されてしまいそうな気がしますが、こういうのは先に言った者勝ちということですね。

ところで人に言われて初めて気がついたけど、地図を拡大してよーく見てみると、対馬が韓国エリアに入ってしまってますね。竹島だったらまだ分かるんだけど、対馬はさすがにないわ……話によるとどうも、使用したフリー素材の地図データがそうなっちゃってたということのようで

追記。Bug 436244 – Tsushima needs to be included in Japan つうことでvoteしときましょう。

6月14日追記。そういえばこの問題については解決済みになったようです。あとは17日（18日）まで裸で正座してwktkして待つだけですね。

Firefox 3 on Mac OS Xのタイトルバーの新機能 - May 29, 2008

誰も書いてないようだったので、activetitlebarcolor属性とinactivetitlebarcolor属性についての説明を勝手に書き加えた。どこにも説明がなかったってことは、これは本当は触っちゃいけないって事なのかもしれんけど、そんなこと知ったこっちゃねえな！（ひどい）

以下、具体的な利用シーンについてちょっと解説。

Mac OS X上では、FinderやSafari、iTunesなどいくつかのアプリケーションで、ウィンドウのタイトルバーとツールバーが結合されたような見た目になっている。これを真似するためにFirefox 3で実装されたのが、activetitlebarcolor属性とinactivetitlebarcolor属性だ。実際には、OS X用デフォルトテーマのバインディングで利用されている。

通常、Mac OS Xではウィンドウのタイトルバーはグラデーションがかかってるんだけど、この属性で #FFF とか #FEFEFE とか gray とかの形で色を指定しておくと、ウィンドウがアクティブな時と非アクティブな時のそれぞれで、タイトルバーの背景がその色一色で塗りつぶされるようになる。と同時に、タイトルバーとウィンドウ内容との間の境界線が表示されなくなる。あとはウィンドウの背景やツールバーの背景をタイトルバーに指定した色と同じ色もしくはそれにつながるグラデーションにしておけば、タイトルバーとツールバーがくっついたデザインのように見えるようになる、というわけ。（逆に、これらの属性をremoveAttribute()で取っ払ってやれば、タイトルバーの表示を強制的に今まで通りの物に戻すことができる）

なお、これらの属性値を変更した場合、ウィンドウのフォーカスが移動するとかウィンドウの大きさが変わるとかしてタイトルバーが再描画されるまでは、見た目は変化しない。動的に変更する時は、属性値を変えた後に window.resizeBy(-1, 0); window.resizeBy(1, 0); とかいう感じで強制的に再描画させるといいと思う。

この機能の残念なところは、グラデーションや半透明や背景色といった派手な指定ができない点。あくまで背景を一色で塗りつぶすことしかできない。CSSのbackgroundプロパティと同等の機能をフル機能で使えれば良かったんだけどなあ。

AutoConfig - May 26, 2008

FirefoxやThunderbirdの設定を一括管理するAutoConfigについて改めてソースコードとか追っかけて調べてみたけど、想像以上に使えない仕組みだった……MDCの方に色々書いたんだけど、lockPrefだけ使う分にはよくてもdefaultPrefとprefはまるで使い物にならない。誰もメンテナンスしてないんだろうなあ、このあたりのコード。Firefox 3でもごく最近までAutoConfigが死んだままになってたらしいし……

Firefox 3での変更点（重箱の隅を突く的な） - May 26, 2008

アナウンスに含まれてるかどうか知らないけどものっそ細かい所での変更点で僕が詰まった所。

• Windowsにおいて、ドラッグ中でもタイマーが機能するようになった
• nsIDocShellTreeItemのchildOffsetプロパティがなくなった

まず一つめ。Firefox 2まででは、何かオブジェクトをドラッグしてる間はsetTimeoutやsetIntervalで設定したタイマーが発火しないという問題があった（ドラッグ＆ドロップ中のタイマーを擬似的に再現する）。これが、いつの時点からかFirefox 3ではWindowsでも普通にタイマーが動作するようになってた。セカンドサーチやツリー型タブで「ドラッグ中に検索バー（タブ）の上でしばらく待つと〜」系の動作がうまく機能しなくなっていたのは、これが原因。Firefox 3以降ではWindows環境でも普通にタイマーを使うようにコードを書き換えたらうまく動くようになった。

二つめ。 個々のフレームに対応するnsIDocShellのオブジェクトを取得するなどで触れたnsIDocShellTreeItemインターフェースについて、Firefox 3ではchildOffsetプロパティがなくなってしまった。XUL/MigemoでFirefox 3においてフレームを跨いだ検索ができなくなっていたのはこれが原因（今フォーカスしてるフレームの次のフレーム、を取得するためにこのプロパティを使っていた）。かっこ悪いけど、親フレームの子フレームリストを取ってきてループ回してchildOffsetに相当する値を算出するようにしたらうまく動くようになった。

なんで今更になってこんな所（後者）をいじったんだか……

自分で自分を危険に晒す行為 - May 19, 2008

塞がれたセキュリティホールを開けろという人々

extensions.checkCompatibility（対応バージョンの照合を行うかどうか）とextensions.checkUpdateSecurity（自動アップデートが安全に行われることを求めるかどうか）のうち、前者はまあfalseにしてもいいと思うけど、後者をfalseにするのは僕もいただけない。前者は「気をつけていれば被害を防げる」性質の物だけど、後者は「気をつけていても被害に遭う」性質の物だから。

自分でもよく分かってないものを人に勧めるな、とは言わない。それを言ったら自分も何もできなくなるから。その代わり、良くないことを勧めてしまったことに気がついたのなら、それを広めた時と少なくとも同じだけの労力を割いて訂正情報を広める努力をする（誤情報を伝えたエントリやコメントに正しい情報へのポインタを追記することもその一つ）のが、自分のしたことに対する責任の取り方という物だと僕は思ってる。

本気でやるならprototype.jsやjQueryやYUIは避けてonclickを使うべき - May 18, 2008

タイトルは釣り。

• 本気でやるならonclick属性は避けてライブラリを活用すべき - id:HolyGrailとid:HoryGrailの区別がつかない日記
• 本気でやるならクロスプラットフォームは避けてMozillaアプリを作るべき - hogehoge
• onclick 属性問題について - IT戦記

僕自身はなんだかんだで仕様原理主義者な所が今も強いわけで、その考えに則れば、onclick等のイベントハンドラは一応W3Cの仕様に含まれてるから（HTML4、XHTML 1.0、XHTML 1.1）OKだけど、ライブラリは業界団体の作る標準仕様になってないからNG、と言える。というのはまあ半分冗談だし、そもそもHolyGrailさんの指摘とは次元が違う話なのですが。

しかしこの考えも、権威主義だけじゃなくて、実利的に考えて「そうあるべき」と僕は割と真面目に思っていたりもする。

1. いつでも詳細な取り決めを確認できて、不安無く使える。
2. 特定のベンダの意向や、世間の流行り廃りに振り回されずに、安心して使える。
3. 学んだことが無駄にならず、他の場面でも使える。

この三つの点について、満たしている物が多ければ多いほど、満たしているレベルが高ければ高いほど、それは良い物で学ぶ意義も大きいと僕は思う。

今でこそ僕はFirefox一辺倒だけど、これも「1」と「3」がそれなりに満たされているからという所が大きい。仕様は無いにしても実装がソースコードレベルで公開されているから、必要とあらば「こういう時にどうなるのか」をどこまでも追いかけられる。また、少なくともWindowsとMacとLinuxというマルチプラットフォームで使えて、どれか一つの環境で作り込んでおけば、他の環境でもそのまま使える（最悪でも、それほど大きな労力を掛けずにポーティングできる）。

そして上記三条件それぞれを最も突き詰めた物が、オープンスタンダードであり、デジュールスタンダードであり、デファクトスタンダードだ。

一昔前までは、ことWebについてはデファクトスタンダードとデジュールスタンダードが激しく乖離しているのが当たり前で、GeckoくらいしかまともにW3Cの仕様を実装している物が無い頃には「W3Cの仕様はWeb標準だからこれに則ってればいいことあるよ」と言っても「でもそれって夢物語じゃん」と返されるのが世の風潮だったと思う。でも今は時代が変わった。OperaもSafariも高いレベルでWeb標準に対応してきたし、IEも少しずつだけどWeb標準に合わせてきてる。今だったらはっきりとこう言える。「Web標準の技術を使っていれば、FirefoxでもOperaでもSafariでも動作するし、AirでもGoogleガジェットでもFirefoxの拡張機能でも使えるし、いいことだらけだよ」と。

不遇の時代を乗り越えて、「Web標準」は今、上記三つの条件を兼ね備えた物にようやくなりつつある。W3CやWHATWGやISOやECMAに仕様があって、仕様が公開されていて、しかもそれをほとんどのベンダがサポートしている。これって凄い事だと思わんかねぇ？（誰ともなく）

Safari風アニメーションの実現方法と、クリック時にスクリーンを表示しない設定について - May 06, 2008

検索がヒットした箇所をハイライト表示していて「次候補」「前候補」を辿る時、フォーカスした要素をアニメーションで強調表示させる機能について、今までは簡易的な実装としてspan要素をposition:relativeにしてtopプロパティをいじることで「ぴょこん」とジャンプするような効果を付けてたんだけど、0.8.4でパクリ元のSafariと同じようなアニメーション効果（フォーカスされた箇所が一瞬拡大される）にするようにした。まああくまで擬似的な物なんですが。

検索にヒットした箇所にアニメーション効果を表示するやり方としては、canvasを使う方法など色々考えられましたが、思いつく限り最も単純なやり方で、要素をコピーして絶対配置するという方法で実装しました。これはText Shadowで折り返されたテキストに影を付ける方法を考えた時に思いついた手法の応用で、こんな風にしてます。

前のテキスト
<span style="position: relative;">
  ハイライトされたテキスト
  <span style="position: absolute;
               top: -0.2em;
               bottom: -0.2em;
               left: -0.2em;
               right: -0.2em;
               font-size: 1.02em;">
    ハイライトされたテキスト<!-- 複製されたノード -->
  </span>
</span>
後のテキスト

position: relativeなインライン要素の中にposition: absoluteな要素を置くと絶対配置の基準がそのインライン要素になる、というCSSのポジショニングの特性を利用して、同じ位置に配置しています。また、top/bottom/left/rightの各プロパティにマイナスの値を設定することで、四辺が親のボックスより大きくなるズームっぽい効果が得られます。フォントサイズも一応いじってますが、あんまり分かりませんね。

手抜きなので、折り返された語句は正しく表示できません。あと、Safariみたいにアニメーションが終わった後もその箇所を特別に強調する、という効果は付けてません（そのうちやるつもり）。

もう一つ、0.8.5での改良点。0.8.2からSafari風強調表示を有効にした状態で半透明のスクリーンの下に隠れているリンクなどをクリックした時にクリックイベントを再送するようにしましたが、この半透明のスクリーンはクリックすると消えてしまうため、ミドルクリックなどで新しいタブでリンクを開いた時にも強調表示が解除されてしまうという欠点がありました。そこで、強調表示を解除しない例外的な操作の設定（正確には「この操作だった場合は一度消した強調表示を自動的に再表示する」という機能なんですが）をできるようにしてみました。

デフォルトでは、ミドルクリック、Ctrl-左クリック（リンクを新しいタブで開く）、Alt-クリック（リンク先を保存）、Shift-クリック（リンクを新しいウィンドウで開く）あたりの操作に対して、強調表示の状態を維持するように設定してあります。他のアドオンを使ってすべてのリンクを常に新しいタブで開いているようにしているから、そういうケースでも強調表示を解除しないようにしたい、という場合には設定をabout:configあたりで編集する必要があります。

この動作を決めている設定はxulmigemo.highlight.hideScreen.restoreButtonsという文字列型の設定です。値は「1,0+1,0+2,0+4,0+8,0+6,0+12」という風なカンマ区切りのリストになっていて、一つ一つが「この場合には強調表示を維持する」という場合の指定になっています。例えば「1」は「ミドルクリック」、「0+2」は「Ctrl-左クリック」を意味しています。プラス記号の左側はボタン番号（0＝左クリック、1＝ミドルクリック、2＝右クリック）で、プラス記号およびその右側の数字はモディファイアキーの指定です（このパートは省略可能）。

モディファイアキーはnsIDOMNSEventの定数プロパティで定義されているフラグで指定します。Altキーは1、Ctrlキーは2、Shiftキーは4、Metaキー（MacのCommandキー）は8で、複数のキーを同時押しした場合を指定するにはそれぞれの数値を足した数を指定します。例えば「0+6」と書いた場合、プラス記号の右側の6は2と4の合計なので、「Ctrl-Shift-左クリック」の意味になります。このフラグ指定の意味がよく分からないという人はビット演算の話を見て下さい。

ハイライト表示のためにテキストフィールド内に挿入されたspan要素が邪魔になる件 - May 04, 2008

前のエントリの続き。

Safari風ハイライトに限らず元々、Firefoxの検索での「すべて強調表示」では、背景色と文字色を指定したspan要素を検索がヒットした箇所に動的に埋め込むという形で、ハイライト表示を実現している。これはinput要素やtextarea要素の場合でも全く同じ。実はFirefoxではテキスト入力欄もすべて、内部的には編集可能なHTMLとして実装されていて、それ故にspan要素の埋め込みも可能になっている。

ただ、この時span要素が埋め込まれる先のDOMツリーはchildNodesとかのプロパティでは辿れない場所にあって、アクセスするにはこんな風にする必要がある。

var editable = content.document.getElementsByTagName('textarea')[0];
var nodesInEditable = editable
     .QueryInterface(Components.interfaces.nsIDOMNSEditableElement)
     .editor
     .rootElement
     .childNodes;

textareaでこれをやってみると、改行が内部的にはbr要素で表現されているとかそういうのも見て取れる。nsIFindで検索する時はテキストフィールド内のこうした「隠しDOMツリー」も普通に検索対象になるようで、span要素を埋め込む時も特に変わったことはしなくていいようだ。

しかし、ここで一つ問題がある。こうしてテキストフィールド内に普通のspan要素を埋め込んでしまうと、その要素は、選択も内部の文字の編集もできない、ワープロでいえば埋め込まれた画像みたいな状態になってしまう。普段は特に意識せずに済むけど、常に強調表示を有効にするようにしていると当然テキストフィールド内でハイライト表示が行われることになる場合も多くなり、この問題が目につくようになってくる。というか僕自身がテスト用ドキュメントでテストしていて、いいかげんウザくなってきたのでなんとかしたかった。

理想的には、テキストフィールドにフォーカスされた時に自動的に強調表示を解除するという風な挙動にできるとよかったんだけど、試してみるとどうもなかなか大変そうだということが分かった。挿入されるspan要素にonclickなどの属性でイベントハンドラを設定してみたところ、getAttributeやdispatchEventなどのメソッド、あるいはparentNodeなどのプロパティを参照しようとするとパーミッションエラーが表示されてしまった。これではnode.parentNode.removeChild()という風なことができないし、独自イベントを発行してChrome領域のスクリプトに後の処理を任せるということもできない。

これについては幸いにも、createRangeなどの機能は使うことができるようだったので、deleteContentsやextractContentsを使って自分自身を削除させるようにはできた。強調表示された箇所を選択して「選択範囲のソース」を表示してみれば、こんな風になっていることが分かると思う。

<h1>B.B.S. <span class="sub"><span onmousedown="
  try {
    var xpathResult = this.ownerDocument.evaluate(
        'ancestor::*[contains(&quot; INPUT input TEXTAREA textarea &quot;, concat(&quot; &quot;, local-name(), &quot; &quot;))]',
        this,
        null,
        XPathResult.FIRST_ORDERED_NODE_TYPE,
        null
      );
    if (!xpathResult.singleNodeValue) return;
  }
  catch(e) {
    // permission denied, then this is in the input area!
  }
  var range = document.createRange();
  range.selectNodeContents(this);
  var contents = range.extractContents(true);
  range.selectNode(this);
  range.deleteContents();
  range.insertNode(contents);
  range.detach();
" id="__firefox-findbar-search-id" style="...">掲示板</span></span></h1>

無駄とは分かっていても一応、正攻法の判別処理も入れてある。テキストフィールド以外の部分に挿入されたspanにも全部このイベントハンドラが設定されてしまうのは、挿入先に応じて挿入する内容を変えるのがめんどかったから。まあとりあえず、これがあっても正常に動かなくなるわけではないし、別にいいかなと。

これだとキーボード操作に対して反応させることができない（そもそもカーソルをspanの中に移動できない）し、本当は特にクリック等の操作をしなくても、テキストフィールドにフォーカスが当たった時点で強調表示を解除するという風な挙動を実現したかったわけで、そこら辺まだまだ改善の余地はある。