Latest topics 近況報告

ツリー型タブ - Oct 15, 2008

ツリー型タブ 0.7.2008101501。前の版から4ヶ月も経ってた。使ってて見つけたバグはちまちま直してたんだけど他のユーザの人から英語で寄せられるバグ報告を放置放置でほったらかしてる間にまたずいぶん溜まってしまったのでちょっと頑張って処理してみた。FireGesturesの仕様変更への追従なんてもう何ヶ月も前の変更だから、もう意味が無くなってるかもしれないけど……まあ誰かに言われたら直そう（ぉぃ）。

Menu Editでタブのコンテキストメニューの項目が無限増殖する問題は、多分、分割ブラウザとの組み合わせを見越して各tabbrowser要素ごとにポップアップメニューの項目に一意なid文字列を生成するようにしていたせいだと思う。<tabbrowser id="content"/>なやつだけ特別に固定のidにするようにして、手元で試した限りでは無限増殖の問題は起こってない。マルチプルタブハンドラでも同じ問題が起こってるはずなので（報告すでに受けてたかも。あまりに多すぎて埋もれてしまってる可能性大。）、これは次のリリースで同じ修正を入れます。

Tab Mix Plusとの組み合わせで色々問題が起こってるという報告を受けてるけど、設定項目が多すぎてどの組み合わせで問題が起こるのか分からないのでお手上げです。とりあえず簡単に手元で試して再現しなかった物は放置。

ルーラーバーで折り返された行のカーソル位置を正しく表示できるようになったよ - Oct 11, 2008

ルーラバーだとやっぱり行ったことのある場所に行くあの呪文しか思い浮かばないという声があったので、日本語名をルーラーバーに変えた。

そのルーラーバーなんだけど、Rulerrrrrでもあった「折り返された次の行の先頭にカーソルがある時や行末にカーソルがある時にルーラー上の現在位置表示がおかしくなる（カーソル位置の計算に失敗する）問題」に真面目に取り組んで、0.2.2008101101でだいぶ改善した。

背景

ルーラーバーもRulerrrrrも、現在のカーソルの位置を計算するのには選択範囲を使っている。FirefoxやThunderbirdではカーソル位置をJavaScriptから直接取得することはできないんだけど、現在カーソルがある位置は長さ0の選択範囲として取得できるので、選択範囲が含まれているノードとか選択範囲の開始・終了位置などからどうにかこうにかして「カーソルより前に何文字あるか」を数えて、カーソル位置を割り出している。

行末にカーソルがある時

行末にカーソルがある時にカーソル位置が0（行頭）と判定されてしまっていたのは、この選択範囲から選択範囲が含まれているノードを取得できないせい。どういう事かというと、行末にカーソルがある状態というのは「テキストノード」「改行のBR要素」「テキストノード」という順番にノードが並んでいてBR要素の直前に長さ0のRangeがあるという状態で、「選択範囲が含まれているノード」は前後の要素やテキストノードではなくいきなりBODY要素になってしまう、ということでカーソル位置の求めようがなくなっていた。

そこで、TreeWalkerを使って各行のテキストノードやBR要素を走査し、compareBoundaryPoints()でそのノードがカーソルに隣接しているかどうかを調べる、という風な処理を入れてみた。これにより、行末にカーソルがある時でもカーソルより前にある文字を数えられるようになった。

折り返された行の行頭・行末判別

折り返された行の処理はもうちょっと厄介だった。普通に考えたら、「カーソル位置より前の文字数÷折り返し文字数 の余り」でカーソルの現在位置が分かるはずなんだけど、実際にはこれだけじゃダメだった。FirefoxやThunderbirdのエディタ機能では、折り返された行の行末にカーソルがある時に右キーを押すと、次の文字（折り返された次の行の先頭文字）の後の位置にカーソルが移動するのではなく、次の文字の前・仮想的な改行文字の後にカーソルが移動してしまう。折り返された後の行頭で左キーを押した時も同様。なので、いくら文字数ベースで計算しても、今「折り返された行の折り返し直前にカーソルがある」のか「折り返された後の行の先頭にカーソルがある」のかは分からない。

幸い、選択範囲の変更（＝カーソルの移動）を監視する時にはその選択範囲の変更が発生したユーザの操作の種類がある程度分かる。なので、マウス操作でのカーソル移動については、行の左の方でのクリックでカーソルが移動した時は行頭、そうでなければ行末と判定するようにした。また、キー操作でのカーソル移動については、「直前にいた位置が行頭・行の中程・行末のどれだったか」と「どのキーが押されたか」の組み合わせを元に、今カーソルがどの位置にあるかを推測するようにした。

英単語等があるせいで予定の文字数より前で折り返しが発生した時や、HTMLでプロポーショナルフォントが使用されている時、画像がある時などについてはもう完全にお手上げです。カーソルの位置をピクセル単位で取れるようなAPIが付いてくれないことには、もうどうにもなりません。

Thunderbirdにルーラーを表示する「ルーラーバー」を作ったよ - Oct 10, 2008

このサイトの方にまだ配布ページ作ってないのでとりあえずMozilla Add-onsに置いてみました。「ルーラ」と書くか「ルーラー」と書くか迷って「ルーラ」にしてしまいました。知ってる土地まで戻る魔法ではありません。→0.2で「ルーラーバー」に名前を変更したのでこのエントリの表記も「ルーラー」に統一しました。

見ての通り、Rulerrrrrのクローンです。公開終了しちゃってる上に特にオープンソースなライセンスが設定されていたわけでもないので、Rulerrrrrの改造ではなく一応フルスクラッチです。以下の点がちょっとだけRulerrrrrよりパワーアップしてます。

• 折り返されたテキストの2行目以降にカーソルがある時は、ルーラー上の強調箇所も折り返し後の位置になります（設定でRulerrrrrと同じ動作にもできます）。
• 改行箇所でテキストノードが分割されるせいでたまにルーラーの強調表示の位置がおかしくなる問題については対処済みです。
• 設定ダイアログから目盛りの表示間隔とかをカスタマイズできます。フォントによってルーラーと文字がずれる場合は、適当に拡大率を調整してください。

空行から左キーを押して一つ前の行の末尾に移動する時に、ルーラー上の強調表示がちゃんと追従してくれないとか、右キーを押して行末→行頭に移動しても強調表示は行末側に残ってしまうとか、Rulerrrrrでも見られた問題がこいつにもあります。そのうちなんとかしたいですね。→0.2.2008101101で改善しました

ていうか誰かすでにクローンを作ってるんじゃないかと思ったら案外誰もやってなかったみたいで驚いた。

Bugzillaで自作自演（FirefoxとThunderbirdのサイレントアンインストール） - Oct 03, 2008

FirefoxもThunderbirdもインストーラに「-ms」を起動オプションで付けるとサイレントインストールできるのに、アンインストーラに同じオプションを指定してもそうならないのは何故なんだぜ？　Netscape 7のアンインストーラ（NSUninst.exe）は「-ms」オプションでサイレントアンインストールできるのに！！！　と思ってBugzillaに書いてみた後で、ソース見てて「アレ？」と思って「-ms」の代わりに「/S」を使ってみたらさっくりサイレントアンインストールできた。うわーかっこわりー！！！

いやでも僕の気持ちも分かって下さいよ。どうしてインストール時は「-ms」なのにアンインストール時は「/S」なんですか？　オプションが違うだけならまだしも、Linuxっぽい「-*」とWindowsっぽい「/*」が混在してるっていったいどういう事なんですか？？　どうしてNetscape 7とはオプションが違うんですか？？？

これは絶対に罠だ……

違うオプションで行けるという発想が全然無かったものだから、Firefox 3 Hacks読みながらビルド環境を2日がかりで作って、アンインストーラだけ個別にビルドできる状態まで持って行って、どうすればサイレントアンインストールだけすっきりと実行できるだろうかとあれやこれややってみたのが、まるっきり無駄になってしまった。あわや無意味なパッチを送りつける寸前でしたよ。ギリギリの所で引き返せて良かったね、と自分で自分を慰めておきます。

つーかこういう勘違いをした理由の一つには、検索しても他にも困ってる人の話しか見つからなくて、「こうすればいいよ」っていう情報に辿り着けなかったからなんですよね。あんまり使う機会のなさそうな機能だけに、情報自体があんまり出てなくて……

もう少しよくソースを見てみたら、Support for the deprecated -ms command line argument.って書いてあった……つまり「-ms」オプションはずっと前から廃止予定になってた古いもので（その割にはFirefox 2.0.0.xでも3.0.xでも使えるんだけど）、今はインストールもアンインストールもサイレントにやるには「/S」を使うのが正解なのか。実際にインストーラに対して「/S」を付けてみたらこっちもちゃんとサイレントインストールされた。うわー二重にはずかしー！！！

旧ドラッグ＆ドロップAPIから新ドラッグ＆ドロップAPIへの移行 - Oct 02, 2008

Fx3.1b1pre tabbrowser全滅で報じられているとおり、Bug 456048 – Use the new D&D API in tabbrowserによって、tabbrowser要素のドラッグ＆ドロップ関係の処理がHTML5で定められた仕様に基づいたものに変更されたようだ。

新APIの使い方についてはGomitaさんが分かりやすい解説を連載で書いてくださっているので、そちらを見てもらうとして。

パッチを見た感じでは、可能な限り最小の変更で新APIに移行していたので、ツリー型タブにも手を入れてみた。変更点を見ると分かるけど、以下のようにしている。

• メソッド名の変更に追従した。
  • onDragStart → _onDragStart （ツリー型タブでは触ってないけど）
  • onDragOver → _onDragOver
  • onDragExit → _onDragLeave
  • canDrop → _setEffectAllowedForDataTransfer
• 各メソッドの引数からaDragSessionが消えたので、Cc['@mozilla.org/widget/dragservice;1'].getService(Ci.nsIDragService).getCurrentSession();でその都度取得するようにした。
• canDropの代わりの_setEffectAllowedForDataTransferは、返り値が真偽値ではなく文字列になっているので、それに合わせて色々変更。
• 受け入れるデータ型の「text/unicode」が何故か「text/plain」に変わったので、他の箇所でも「text/plain」を受け入れるようにした＋他の拡張機能でドラッグを開始する時に「text/plain」もセットするようにした。

ツリー型タブでは、Firefoxのtabbrowser要素の各メソッドを書き換える時に上記の点を動的に判別して、Firefox 3.0.xとFirefox 3.1の両方に対応するようにしている。

基本的に、新APIは旧APIの機能をほとんど包含しているので、旧APIに基づいて作った拡張機能等はほとんど機能を失うことなく新APIに移行できると思う。逆に、新APIではドラッグ元要素に新しいイベントが発行されるようになっているため、それをバリバリに使った新しい機能は旧APIベースで再現するのは大変そうだ。

これに関連してMDCの最初のページだけ訳してみたけど、新しいシステムの上で訳したのは初めてだったので、だいぶ難儀した。翻訳文書新規作成支援ボットは使えないし、リンク先はいちいち手で打ち直さないといけないし、リンク先を変える時に開くプロパティみたいな画面を表示する度にいちいちものすごく待たされるし……

Thunderbirdまじうんこ！ - Oct 01, 2008

こないだからやってるNetscape Communicator 4.xからの移行、現地でのリリース候補版レベルでのテストでまた詰まった。自分とこで作ったテスト環境では問題なかったのに、実際の環境だとnsIMessengerMigratorのUpgradePrefs()で謎の例外発生ですよ。

もういっそのこと処理を全部JavaScriptに移植してみるか？　なんて不毛なことを考えてもみたけど、せめて現地でできる事はやり尽くしておこうと思ってMXRでソースを見ながら目デバッグし始めてみたら、冒頭でいきなりそれっぽい箇所を発見した。移行元の設定でmail.server_typeが未定義だと駄目らしい。よくよく調べてみたら、その環境ではnetscape.cfg内で指定されてる設定がたくさんあって、その値はユーザプロファイルの中のprefs.jsには保存されてないから、Thunderbirdが「全然設定が足りねえぞゴラァ！！」と怒ってた、と。

こんなん、今回うちで作った移行ツールじゃなくても本体の設定インポートでも普通に詰まるんじゃないの？　どうなってんだまったく。

Firefox 2.0.0.17とThnderbird 2.0.0.17のJavaScriptエンジンに極めて深刻な問題があるようです - Sep 30, 2008

仕事で書いてるコードがどーにもうまく動かなくて、ついこないだまで正常に動いてたのにどうして？！と思って色々試していたら、特定の関数をtoString()等で文字列化した時におかしな現象が起こっていた。具体的には、Thunderbird 2.0.0.17のAccountManager.jsで定義されているsaveAccount()を書き換えようとしたら例外が発生して、onSave()を文字列にしてreplace()で改変した物はfor〜inループだった箇所がwhileループになってしまっていた。コードを削っていったらめちゃめちゃ短いコードでも再現したので、Bugzillaに報告しておいた。

regression: Function.toString(), Function.toSource() and uneval() return wrong JavaScript code if the function includes "for ... in" roop

上記のような方法で動的にパッチを当てる手法を僕は多用してるので、仕事で書いたコードもここで公開してる拡張機能のコードも、正直、どのくらい影響を受けるのか見当も付かない。早急に解決されることを祈るのみだ。

ちなみにFirefox 3.0.3ではこの問題は起こらなかった。2.0.0.17で入ったセキュリティ上の修正による後退バグっぽい？

追記。29日時点ですでに修正済みだったようだ。これ、あと1ヶ月間放置ですか……？　ものっそクリティカルなバグだと思うんだけど。

pab.na2をThunderbirdにインポートできない件 - Sep 24, 2008

Netscape Communicator 4.xのメールデータとか設定はインポートできるのにアドレス帳だけインポートできないってどないやねん。

調べてみたら、鍵になるのはnsIAbUpgraderインターフェースを実装したコントラクトIDが@mozilla.org/addressbook/services/4xUpgrader;1のコンポーネントらしいんだけど、これ、Mozillaのソースには含まれてないんだ……オープンソースになってなかったいくつかのNetscape製コンポーネントの一つらしい。これがないせいでThunderbirdはNC4.xのアドレス帳を直接読めないんだって。なんてこった。

どうしてもやりたい場合、考えられるやり方は以下のような感じ。

• NC4.xのエクスポート機能を使う
• Netscape 7のインポート機能を使う
  • Netscape 7をインポートツールとして使う
  • Netscape 7の当該コンポーネントだけをどうにかして呼び出して使う
• 他のインポートツールを使う
• *.na2を直接読むプログラムを書く

というわけで調べてみてた。

まずNC4.xのエクスポート機能を使う方法。多分これが一番手っ取り早い。LDIFかCSV等に書き出して、Thunderbirdのインポートツールでそれを読み込めばいい。ただ、手動でやらなきゃいけないってのがネックで、自動化できないから今回の仕事じゃちょっと使えない。

次に、Netscape 7を使う方法。NS7には上記のコンポーネントが含まれてるから、プロファイルのインポートで普通に*.na2を*.mabに変換できる。ということで拡張機能なりパッチなりを使ってNS7をアドレス帳変換専用ツールに仕立て上げてしまえば諸々の処理を自動化できるんだけど……インストール先のchromeフォルダを見たら、昔半泣きになりながらexUnregisterer.jsなんて自作ライブラリを作ってどうにかこうにか凌いでいたあのRDF地獄があって一気にやる気消失してしまった。最近Firefoxのアドオンを作り始めた人は知らんでしょうけど、昔はオーバーレイいっこあてるのにも物凄い苦労があったんですよ……

じゃあ例のコンポーネントが含まれてるDLLを直接呼んだらどうなんだ？ってことでcompreg.datを手作業で書き換えてあれこれやってみたけど、これもうまくいかなかった。例のコンポーネントが含まれてるっぽいabupgrade.dll以外にもそれが依存してる物があるのか何なのか、コンポーネントを無理矢理登録してみてもちっとも動いてくれなかった。というわけでこれもダメ。

他のツールはないのか！と思って検索してみたらDawnとかいう色んなメーラのアドレス帳の読み書きに対応したツールがあったんだけど、試してみたら日本語の名前や住所が見事に文字化けして全然使えなかった。ていうかそもそも自動処理できないっぽいし。

そんな感じでにっちもさっちもいかなくなったので、ヤケクソでpab.na2（NC4.xのデフォルトの個人用アドレス帳。Personal Address Bookの略でpabらしい……というのはどうでもいい話ですね）のバイナリとにらめっこしながらデータ構造の解析を試みてみた。試行錯誤した結果、全部のフィールドに違う値が入ってる時に関してはなんとか個々のカードの内容を吸い出せるようにはなった（！）んだけど、複数フィールドに同じ内容が入ってたり複数カードのフィールドに同じ内容が入ってたりすると、そこだけ圧縮かかるみたいで全然うまくいかない。どういう順番でどこを読みに行けばいいのかさっぱり分からん……

ちなみに、ここまでの時点でFirefoxのコードを参考にしてnsreg.dat（NC4.xのプロファイル名とプロファイルのありかが保存されているバイナリ）の解析には成功してるので、後はホントに*.na2の中身をどうにかして取り出せさえすればインポートを自動化できるのに！という非常に悔しい状態なのです。ああもうっ。

Firefoxの開発者にはUIの設計という事に対するポリシーが欠けている - Sep 20, 2008

タイトルは半分くらい釣り。

ごく最近入った変更によって、最後のタブを閉じると常にウィンドウ全体が閉じられる、という挙動になったらしい（Firefox 3.1では多分それがデフォルトになる）。この変更はパッチを書いたDão Gottwald氏ではなく開発責任者の一人のMike Connor氏が決めたものらしい。

この件についてMike Conner氏のマネジメント能力の不足を責めてる人もいるようだけれども、僕としては、この人はUIの設計という物にポリシーを持ってないのかなー、という失望にも似た感想を覚えた。多分SearchLoad Optionsに抱いたものと同じ感覚。

最後のタブを閉じた時にウィンドウも閉じるべきかどうかってのは、隠し設定一つで動作を変えれるような些末な問題に落とし込むべき事じゃなくて、ユーザが触れるフロントエンドとしてのFirefoxの設計思想の根幹に関わる事だと僕は思う。ユーザに「Firefoxとはどういうものか」と説明する時の、メンタルモデルの作り方をガラッと変えてしまうものだと思う。

現状のFirefoxは、「Firefoxというアプリケーションがあって、そのアプリケーションは本体はごくシンプルな機能に限られていて、その中に、タブを伴って複数ページの切り替えができるサブフレームが含まれている」というトップダウンの設計になっている。「タブ」より上位に「メニューバーやツールバーやサイドバー」が存在しており、「タブ」より下位には何も従属していない。こういう構造だからGoogle Chromeのようなマルチプロセスにはできない（するにはとても手間がかかるだろう）。ユーザには、「タブとウィンドウは異なるレイヤに存在するもの」という認識が求められる。

Google Chromeは、「タブという小型でシンプルなWebブラウザがあって、それらを便利に操作できるようにするために一つのウィンドウに押し込めている」というボトムアップの設計になっている（ように見える、そういう演出をしている）。だからマルチプロセスで当たり前だし、「タブ」の上には何も（クローズボックスくらいは付いてるけど、それ以外のタイトルバーすら）なくて、ツールバーもロケーションバーも全部「タブ」より下位の存在として位置づけられている、そういう見た目をしている。ユーザには「タブ」と「ウィンドウ」の違いを意識させないようにしている、ように見える。

ちなみにOperaはMDIのアプリケーションで、この両者の中間にあると思う。「タブ」より上位の物もたくさんあるけど、ロケーションバー等は「タブ」に従属しており下位の存在である、という作りになっている。

タブより上にツールバーがあるか、タブより下にツールバーがあるか、っていうのは、単にバーの置き場所を上下に移動させればいいっていう話じゃないんですよ。フラットな「並び順の問題」じゃなく、縦の「主従関係」なんです、これは。

多分だけど、今回入った変更のような動作が許されるのは、「タブより下にツールバーがあるデザイン」のアプリケーションだけだ。タブより上位に何もないんだから、タブが閉じられたら後には何も残らないのが当たり前だ。

Firefoxの場合はそうではない。タブより外側に沢山の物があって、それらは「自分の下位にタブが存在している」ことを前提に動作している。下位の物（タブ）を一つ消したのなら、それより上位にある物は全部そのままでいるのが当たり前だ。にもかかわらず今回の変更で、下位にあるはずのタブによってそれより上位の物全てが破棄されるようになってしまった。そこにみんなは戸惑っているし怒っているんですよ。そういう、自分の中にある無意識のメンタルモデルまで分かった上で発言してる人は、そう多くないと思うけどさあ。

Mike Conner氏は、そこまでちゃんと分かった上で発言してたのかな？　自分が下した決定が、ユーザの心の中にあるメンタルモデルやそれまで動作していたアプリケーションの設計全ての前提を覆す物だって気がついていたのかな？　多分気付いてないよ。「ちょこっと動作を変えるだけ」そう考えてたんだろう。それが僕には、ポリシーがない無節操な行動に見える。

余談。冒頭で「半分は釣り」と書いたのは、これとは違うレイヤでFirefoxの設計にはポリシーがあるという事も知っているから。彼らは何でもかんでも中に取り込むのではなく、本体はシンプルに保ってそれ以外の要求はアドオンで解決する、というポリシーで開発を行っている（ように見える）。そのポリシーを今後も貫いていて欲しい。ただ、それは「Firefoxというプログラム」の設計ポリシーの話であって、「FirefoxというUI」の設計ポリシーじゃない。それとこれとは問題が別。ここまでタラタラと書いたこと、具体的な「FirefoxというUI」の設計に関して何もポリシーがないと、ユーザや開発者を振り回すことになる。そこのところをどうして彼らは分からないんだろう、という嘆きにも似た感情を、開発者主体で動いているオープンソースのプロジェクトというものについて感じることが僕にはたまにある。

追記。「（過去の）FirefoxとGoogle Chromeの動作（UIの設計思想）のどっちが素晴らしいか」ということについては、僕は考えないことにしてる。どっちにも一長一短がある以上、こういうのは刷り込みと慣れの問題でしかないと思うから。Mac OS伝統の「画面上端にメニューバー」とWindowsやGNOMEやKDEの「ウィンドウごとにメニューバー」のどっちが優れてるのか、というのと似たような話です。あくまで、UIとして（上記のような設計思想・メンタルモデルの面で）一貫性が保たれてないのはそれ以前の問題だ、というのがこのエントリの要旨ってことで。

さらに追記。前の動作に戻す隠し設定が欲しいというバグで中野さんが「初めて最後のタブを閉じようとした時に確認するのがいいんじゃないか」という提案をされている。選択肢をユーザにわざわざ見せるのは良くない、ユーザの理解を妨げる事は徹底して隠すべき、という人もいるだろうし、UIと動作と設計の整合性がとれてるなら僕もそれに同意だけど、現状のUIも動作も設計も全部がバラバラでちぐはぐな状況では、選択を求める方がまだナンボかマシだと僕は思う。ので、賛同コメントを付けてみた。まあ、コード書ける奴が正義のこの世界では、グダグダ評論家じみたことを書き連ねたり嫌味なコメントを残したりするより、とっととパッチ書いてIRCで担当者捕まえてねじ込む方が、実効性は高いと思うんですけどね……

またまた追記。くでんさんのコメントを読んだ後で思ったけど、上で書いた「疑い」とはむしろ逆で、Mike Conner氏は「Google Chromeのようなアプリケーションを元々作りたかったし、その信念に基づいて提案しただけ」なのかもしれないなあ。だから今回の変更も氏にとっては「本来そうあるべき姿に戻そうとしているのだから当然のこと」という感じなのかも。だとしても、できれば、行動を起こす前に「そういう理想はさておき、現状はどうなってるのか？」という所に先に目を向けて欲しかったとは思う。

22日追記。結局、「最後のタブを閉じた時にウィンドウを閉じない」隠し設定を付けるという、件のバグの表題通りの解決策についてはチェックインされて、それで解決ということになったようだ。でもって、他の文句は新しいバグ立てて述べなさいという仲裁も入った。Bugzilla的にはごく自然な流れ。にもかかわらず流れ読まずについ最後っ屁コメントを残してまた議論を蒸し返してしまった僕は、マヌケな悪役もいいとこですね。

セカンドサーチに「一定時間後に元の検索エンジンに戻す」機能を付けないワケ - Sep 15, 2008

SearchLoad Optionsがすでにそういう機能を持っているから。以上。

まあそういう「車輪の再発明はもういいよ（しかも再発明するメリットがないし）」という理由以上に、自分の中では「その機能がヘドが出る程嫌いだから」っていう理由の方が大きいんですけどね。

元々セカンドサーチを作るより前にSearchLoad Optionsの存在を知って、「検索実行後に元の検索エンジンに戻す」という機能のことを知って、心の底から呆れた記憶がある。「ハァ？　何その発想。ありえねえ。理念も実装も全然スマートじゃない。『別の検索エンジンで検索しました。でもその後はその検索エンジンに切り替わったままです。普段使いの検索エンジンに戻ってなくて困ります。』オーケー、ユーザの声としてそういうのがあがってくるのは分かる。でもそこでどうして『じゃあ、検索し終わったら普段使いの検索エンジンに戻しましょう。』って発想になるわけ？　そうじゃないだろ。そもそも『一時的に使いたいだけの他の検索エンジンに切り替えて(1)、検索して(2)、検索が終わったら普段使いの検索エンジンに戻す(3)』っていう風にやたらステップが多くてめんどくさい事が問題なわけだろ。その最後の(3)だけ省略できるようにしましたワーイワーイ！って、アホか。もっと頭使えよ。せっかくやるんだったら、その3ステップ全部省略しないと、時間かけて物を作る意味がないだろ。『文字を入力したら検索エンジンの一覧が自動的に出てきて、選択したら即検索される(1)』こうだろJK。その知的怠惰が気にくわない。」という感じである意味怒りに燃えて作ったのが、セカンドサーチなわけです。「これ以上ステップを省略するには脳にプラグ直結する以外無い」ってとこまで突き詰めて考えないと、ダメだと思うんだ、ホントに。

だから、僕がメンテナンスを行っているバージョンにおいては、セカンドサーチにその機能を付ける事はきっとあり得ない。すでに省略され消滅したはずのステップをわざわざ意識しないといけないようにする、なんて選択はよっぽどの事がない限りはしたくない。まあライセンスはMPL/GPL/LGPLなので、フォークしてそういう機能を持ったバージョンを誰かが作る事を止めはしませんけどね。