Latest topics 近況報告

落ちる - Dec 10, 2007

とよく言われるんだけど自分の環境＆自分の見てる範囲のWebサイトでは落ちないので原因が分からない、ということが多い。落ちるか落ちないかのギリギリの所をうまく突くようなコードを知らず知らずのうちに書いてしまっているのでしょうか。そんな能力いらなさすぎる。

タブブラウザ拡張3 - Dec 06, 2007

TBEのページのトップを刷新して、古い情報は別のページに移動した。どれだけの人がこのページを今も利用してるのかは微妙な所だけど、Firefox 2向けの情報が注意書きとしてだけ入ってるというのは現状からするとあまりよくないので。

タブからプレースホルダーがゴッソリ消えた件についての憤り - Dec 01, 2007

タブのバインディングやスタイル指定のためのコードの削減のせいで、Firefoxのタブの拡張性は深刻なまでに低下した。ツリー型タブも情報化タブも動かなくなったし、Alice0775氏のスクリプトなども被害を被っているし、他にも被害を受けている拡張機能はあるんじゃないかと思う。

拡張機能がたくさんあるから云々ということを売り文句にしておきながら、このように拡張機能作者をいじめることにしかならないような変更を軽々しく入れてくる連中には、本当に腹が立つ。この詐欺的行為にあまりに腹が立ったので、自分でバグを立ててみた。

バグの報告文に書いたけど、この問題の要点は「拡張するためのあそびが全くなくなってしまった」という一言に尽きる。現行のFirefoxでは、スタイル指定のために用意された匿名要素のボックスや、そもそも今のFirefoxでは使われていないけれども今後実装されるかもしれない何らかの機能のために用意されていた（と僕は思っているけど確証はない）プレースホルダーがあって、それらの中に色々な要素を追加することができた。そのお陰で、タブの中にサムネイルを出したり、タブのロック状態などをアイコンで表示したりということが可能になっていた。ところが前述のバグで提出されたパッチによって、現在Firefoxの標準的な機能で使われている物以外の「あそび」は一掃されてしまった。

今の構造でも、バインディングを使えば要素を追加することはできるけれども、複数のアドオンでそれぞれ別々のバインディングを提供すればそれらは確実に衝突する。例えば、今までは情報化タブとツリー型タブを（それだけでなく、他のいろんなタブ系拡張機能を）好みに応じて組み合わせて使えていたのに、これからは、そのうちどれか一つしか使えなくなる、「組み合わせて使う自由」が失われるということだ。これでは、Firefox 1.5以前の暗黒時代に逆戻りだ。拡張性が高いことにFirefoxの価値を見出している者にとっては、こういう愚行は決して容認できるものではない。

でも英語力に自信がないしBugzillaの流儀にも詳しくないので、invalidとかworksformeとかそういう処理をされて、結局何も変わらないままFirefox 3正式リリースまでこの問題は解決されないまま放置されてしまいそうな気がする。誰か援護射撃してくれると嬉しいんだけれど……

APIを作る時はどんな使われ方をするかちゃんと考えてから作ろうという話 - Nov 30, 2007

ツリー型タブでずっと前から発生条件が分からなくて困ってた「一つもタブが選択されていない状態」になってしまうバグの原因がやっと分かったので、速攻で修正した。

この問題は、以下の条件がすべて揃った時に発生していた。

• タブバーの末尾に、ツリー状になったタブがある
• そのツリーが折り畳まれた状態で、ツリーの最上位の親のタブが選択されている
• そのタブを閉じる操作を行う

この時、内部的にどういう処理が行われていたかというと、以下のような感じだ。

1. removeTabメソッドが呼ばれる
2. removeTabメソッドにてTabCloseイベントが発生
3. TreeStyleTabBrowserのインスタンスがTabCloseイベントを捕捉
4. 1で閉じられようとしているタブがツリーの親で且つ子孫タブが折り畳まれている場合、TreeStyleTabBrowserが子孫タブを先に閉じる
5. TreeStyleTabBrowserのTabCloseイベントに対する処理が完了
6. removeTabメソッドの残りの部分に制御が戻る
7. 閉じようとしているタブが、選択されたタブだった場合、次に選択するべきタブを決定し、そのタブを選択する
8. removeTabメソッドの処理が完了

この「TabCloseイベント」というのがFirefox 2以降で使えるAPIなんだけれども、問題は7のステップで起こっていた。7のステップで「次に選択するべきタブ」を決定するためのキーとして「現在開いているタブの総数」を使っているのだけれども、その値は1のステップの間に取得しているため、1から7までの間のどこかでタブの数が増減した場合、タブの選択状態が狂ってしまうのである。7のステップで「現在のタブまたはそれよりあとのタブ」が選択される場合、ここでは4のステップでタブの数が減少しているため、「次に選択するタブの番号」が「すでに削除されたタブ」のインデックスを指し示すことになり、selectedTabの値がundefinedとなりNull Pointer Errorが発生してしまう。……というのが事の真相だった。

ツリー型タブの側でselectedTabのセッタを上書きし、もし存在しないタブが選択されそうになった時は強制的に最後のタブを選択するようにしたところ、「一つもタブが選択されていない状態」は発生しなくなった。以下はそのためのコード。

// var b = gBrowser

var getter = b.__lookupGetter__('selectedTab');
var setter = b.__lookupSetter__('selectedTab');
eval('setter = '+setter.toSource().replace(
    '{',
    '{ if (!val) val = this.mTabContainer.lastChild;'
));
b.__defineGetter__('selectedTab', getter);
b.__defineSetter__('selectedTab', setter);

この部分ではなく、removeTabメソッドを上書きするという手もあるんだけど、ここはいろんなアドオンが上書きしたがるためコンフリクトの原因になると思ったので、「標準的な動作と変わってしまう」ことは仕方がないと割り切って、ほとんど誰も触らないであろうselectedTabの方を上書きするようにした。ちなみに、ゲッタとセッタ両方を定義し直しているのは、片方だけを再定義するともう片方が未定義になってしまうから。

表題の件に流れを戻すと、「タブを閉じる」という操作をイベントとして捕捉できるようにしたのなら、そのイベントをトリガーにして他のタブを連動して操作するという機能も当然登場してくるわけで、そういうことを考慮せずに「はいはいイベント発行すりゃいいんだろdispatchEvent っと！」と適当に設計してしまうとこういうトラブルが起こるので、APIを作る時にはもうちょっと慎重になった方がいいよね、という教訓を得たという話なのでした。

アドオンコンテスト追加エントリー - Nov 24, 2007

方針が明らかになったことを受けて、さらにいくつかのアドオンを追加で応募した。以下はその時に書いた紹介文。

Tree Style Tab

This moves the tab bar from top (horizontal) to left (vertical), and shows tabs with indent like a tree. Tabs opened from links are automatically attached to the current tab as children. Additionally, tabs' tree can be also managed by drag and drop manually like a folder tree. Vertical tab bar and collapsable tree will help you to get a quick overview of your browsing and manipulate huge numbers of tabs. Moreover, because this works together with other tab-related extensions (including Tab Mix Plus), you'll get highly optimized experience of tabbed browsing.

Multiple Tab Handler

This helps you to manipulate multiple tabs. By dragging on tabs you can select them, and a popup menu will appear when you release the button. "Close", "reload", "duplicate", "bookmark" and "copy URIs" are available by default, and you can add new features to the menu by addons which use the API (ex. my other works, "Split Browser" and "Tree Style Tab"). Moreover, you can close multiple tabs quickly by dragging their closeboxes, so this feature will be useful in vertical tab bar (with "Vertigo" or "Tree Style Tab".)

Informational Tab

This provides thumbnail and progress meter for each tab. Thumbnail is visual summary of the tab and it is more effectively than tab label. Moreover, you don't have to press any key and any button to see their thumbnails, because they are permanently shown.

XUL/Migemo

In CJK areas, people cannot use incremental search of the find toolbar, because we have to translate roman input to Japanese, Chinese, or Korean terms, like: from "nihongo" to "日本語". And, in Latin areas people cannot find terms with phonetic symbols (ex. "Frédéric") by simple characters (ex. "frederik"). This addon includes dictionaries and translation engines, so you can find those terms without translation and CJK people can use incremental search more effectively. Demo: http://piro.sakura.ne.jp/xul/_video/xulmigemo.html.en

Second Search

This helps you to use multiple engines from the search bar. When you type or drag search terms into the textbox, a list of available search engines is shown automatically. This doesn't change the default engine so you don't have to get peeved at cases like: you search a book by Amazon, and you wish to search another word by Google but you get a search result of Amazon because you forgot to switch the selected engine from Amazon to Google.

Split Browser

This splits the content area of the browser and provides parallel browsing experience. You can compare two or more webpages for translation or other uses (moreover, they can be synchronously scrolled if you want), by simply clicking buttons which appear on edges of the content area. BTW, because this is implemented by XBL, you can split the area infinitely.

今回追加エントリーした連中の方が一応僕にとっては「本命」なんだけど、これも箸にも棒にもかからなかったら泣けるね……

ベータ - Nov 22, 2007

世間的には「ベータ版は機能を確定して細かい不具合のチェックに入った段階の云々」という風な説明がなされるようだけど、昔からずっと見てる限り、Firefoxの（というかMozillaの）それはただのリビジョン番号と変わらない気がする。RC（リリース候補版。問題がなければそのまま名前を変えて正式版になるかもしれないバージョン）と名付けてるくせにそこで平気ででかい変更を入れることも、メンテナンスリリースのはずの2.0.0.Xでセキュリティに関係ないでかい変更を入れてくることも、Mozillaではよくある話で、Mozillaのバージョン管理のいいかげんさは伝統的なものなんじゃないのという気がする。まあ「柔軟性がある」って言えばそれはそれでいいことなのかもしれんけど。

それか、もしかしたらこれは別にMozillaに限った話ではぜんぜんなくて、「ベータとは云々」という言葉の説明の内容自体が今の世の中の「ベータ」の多くの実態と乖離してるだけだ、という話なんでしょうか。

アドオンコンテストの件 - Nov 22, 2007

Mozilla Labsのアドオンコンテストに殴り込みをかけようとして不発に終わった件について、フォーラムに書いた質問に、Personasの作者でもあるクリス氏から回答があった。だいたい以下のような感じ？

• 「Notes」欄の内容は、本格的な審査に入る前の最初のふるい落としに使われる。
• どんな機能があるのか、どんな問題が解消されるのか、どうやって解消するのか、といった説明の端的な要約を書くのが望ましい。
• 詳しい説明がどうしても必要なら、Webページに書いてそのページのURIをNotes欄に書いてもいいけど、Notes欄の要約だけでアドオンの内容がちゃんとわかるようになってた方が、審査員には好印象。

ということでこれを受けて「本命」の作品をエントリーした。

「タブ」というUIの一歩先 - Nov 18, 2007

先日、ツリー型タブのアピール文を英語で書くために人の手を借りながらああでもないこうでもないとやってるうちに思ったことなんだけど。図らずも、大学の卒業制作でやったWeb Mapで実現したかったことの一部を、僕はツリー表示とサムネイルによって手に入れていたようだということに、今頃気がついた。

タブのツリーは、今まで「ページ同士の関係性が分かる」という風に説明をしてきた。でも、実際にもたらされる効果の面から言い換えると、「あるページを基点にした閲覧の足跡をそのまま、興味が移り変わっていく様子＝ツリーの分岐という形で保持し、好きな時点の興味の対象の間を容易に行ったり来たりできるようにする、視覚的な履歴」ということになると思う。

デスクトップ百景のスクリーンショットを見ての通り、僕はタブをたくさん開く方だと思うけど、べつに、多数のページを本当に平行して見ている訳ではない（そんな聖徳太子みたいなことはできない）。実際には、「後でもう一回読み返そう」「後でコメントしよう」「後で日記のネタにしよう」そう思った物を「読みかけ」「保留状態」で置いたままになっているだけだ。

そういう用途だったらブックマークを使えばいいじゃないかと言われるかも知れないけど、僕にとってはそれでは駄目なんだ。ブックマークはフォルダに放り込んでしまったらもう見えなくなる。画面がスッキリしていいんだけど、それはつまり意識の外に行ってしまうということで、「どこに何がある」ってことをちゃんと記憶しておかないとすぐに忘れてしまう。ソーシャルブックマークもそうだし、同様の理由で多分僕にはRead it Laterも使いこなせないと思う。

でもタブは、明示的に閉じない限りは視界の隅に残り続ける。他のことをし終わって一息ついた時、「ああ、そういえばこれがまだ未処理だった」という風に自分から主張してくる。そういう未処理のがスクが溜まって、タブがどんどん増えてくると、タブバーがだんだん狭苦しくなってきて、「ああ、そろそろ片付けなきゃな」って気になってくる。

ウィンドウ上部に水平に置かれたタブでは、勝手が悪い。たくさんタブを出そうと思ったら、一つ一つのタブが小さくなりすぎて何のタブだったかが分からなくなるし、タイトルが読めるような大きさでタブを表示すると、1画面の中に数個しかタブが表示されなくなる。これでは、自分のしていたことをざっと俯瞰することができない（「タブの一覧を表示」ボタンもあるにはあるけど、「モード」の切り替えを必要とするので、僕には馴染めない）。ある程度の情報を表示できる状態のタブを、10とか20とか表示できるのは、ウィンドウ左右での「縦置きタブ」ならではの利点だ。

単にタブを縦に並べただけでも不十分だ。確かにさっきは「自分のしていたことをざっと俯瞰できないから嫌だ」と書いたけど、でも、していたことの子細が全部一度に見える必要はない。全教科のノートの全ページを並べて見せられるより、それぞれのノートの表紙だけ並べて見せられた方が、余計な情報が少なくて、「ざっと見る」という目的に即しているだろう。そういう意味で、それぞれのツリーを折り畳んで、各ツリーの基点になった「親」のタブだけをざっと眺めることができるツリー型タブは、先ほどのノートの例え話にも似た効果がある。

こういう使い方をするにあたっては、それぞれの「タブ」が含んでいる内容を常時見ることができるようになっていると、なお良い。情報化タブでモードレスに常にサムネイルを見えるようにしているのは、そういうことだ。

最近仕事でRuby on Railsをやらないといけなくなって、MVC（データと、その表現形式と、制御）をきちんと分離するという考え方に今頃になって触れた。確かにプログラムを作る時はそれらは分離した方がうまく行きそうだけど、ユーザの目に見える時にはそれらが一体になっている方が多分いい。レバーを上げ下げすれば「操作できる」と同時に「データ（状態）が変わり」、さらには「今の状態が表現される」、という風に、原始的なUIはMVCが一体になっているからとても分かりやすい。プログラムを作る段階では構成要素ごとにMとVとCに分解しても、その後、それをユーザに見せる時にはもう一度統合するということが必要なんじゃないかと思う。

デスクトップ晒し（in Broadband Watch） - Nov 16, 2007

デスクトップ百景 第四十五景：カスタマイズしなきゃ気がすまない？ 超・自分本位のデスクトップ……ということでBBWatchでデスクトップ晒してます。ハテナオヤ氏とか 碇シンジでおなじみの緒方恵美さんとかのビッグネームが並んでる中にぽつんとただのヲタが紛れ込んでて「だれやねん」という感じですが、石は投げないでください。

なお、LR-Menuのスクリーンショットでフォルダのショートカットがメニューにたくさん表示されていますが、これは、特定のフォルダをルートにしてエクスプローラを起動するようにしたショートカット群です。explorer.exeへのショートカットを作成して explorer.exe /e,/root,"C:\Documents and Settings\username\Application Data\Mozilla\Firefox\Profiles" のようにリンク先を指定するだけで作れます。オプションの詳しい解説はMSのナレッジベースを参照してください。

続きを表示する ...

フォクすけブートキャンプの中の人のインタビュー - Nov 16, 2007

の映像がフォクすけブログにあがってる。

<object width="425" height="355"><param name="movie" value="http://www.youtube.com/v/Kwi84-LAdu0&rel=1"></param><param name="wmode" value="transparent"></param><embed src="http://www.youtube.com/v/Kwi84-LAdu0&rel=1" type="application/x-shockwave-flash" wmode="transparent" width="425" height="355"></embed></object>

userChrome.jsに行った時点で余裕で初心者置いてけぼりな気がします！

まあブートキャンプというタイトルからは、ある意味当然の流れだとは思うんだけど。自動更新や簡単な管理、あるいは相互の組み合わせといった、エンドユーザが気軽に使えるようにするための配慮という贅肉をそぎ落として、必要なものだけが考えられる限りの最もシンプルな形で残る、というコンセプトだからヘビーユーザに大人気なのもよくわかる。alice0775氏のスクリプトとか高機能なものも多くて、似たような機能しか無いくせに色んな物をゴテゴテとくっつけざるを得ない拡張機能を作り続けてる僕涙目wwwwwwwwww という感じだ。