English version of this post is also available.

ScrapBookのブラウザ上のコンテキストメニューについて見直すシリーズ、その２。
今回はフレーム上で右クリックしたときに「ページの取り込み」とともに表示される「フレームの取り込み」メニューについての比較検討である。Firefoxの標準のコンテキストメニューでは、フレームに対する操作はすべて「このフレーム」というメニューのサブメニューとして表示される。したがって、「フレームの取り込み」メニューは「このフレーム」メニューのサブメニューであるべきだと言える。
逆に、現状維持派の言い分としては、「ページの取り込み」と「フレームの取り込み」が並んでいる方が直感的にわかりやすく、二者択一しやすい、あるいは、拡張機能による付加的なメニューはあちこちに分散すべきでない、一箇所にまとめるべきだ、といった見解がだろうか。
また、開発者の言い分としては、確かに代替案の方が理にかなっていると思うが、今頃になって突如メニューの配置を変えるとなると、それに気付かずに「フレームの取り込み」機能が無くなってしまったのかと勘違いされるのが嫌だ、というのが一番大きい。

▲現状 「フレームの取り込み」は「ページの取り込み」と並列関係にある。 ▼代替案 「フレームの取り込み」は「このフレーム」のサブメニューとすべき。

English version of this post is also available.

ScrapBookのブラウザ上のコンテキストメニューについて見直すシリーズ、その１。
まずはもっともポピュラーなメニューである「ページの取り込み」「ページの詳細な取り込み」の位置についてである。現状では、これらのメニューはコンテキストメニューの最下部に表示される。しかし、ScrapBookの「ページの取り込み」機能はFirefoxの「名前を付けてページを保存…」の類似機能であることを考慮すると、これらのメニューは近い位置、少なくともセパレータで区切られた同一のカテゴリ内にあるべきだと言える。
逆に、現状維持派の言い分としては、拡張機能による付加的なメニューは標準で備わるメニューよりも位が低いのでより下の位置にあるべきだ、といった見解だろうか。
ぜひともScrapBookユーザの方々の意見をいただきたいと思います。

	現状 「ページの取り込み」は最下部にある。
	代替案 「ページの取り込み」は「名前を付けてページを保存…」に近い位置であるべき。

先日XULのスピンボタンが実装されたと思いきや、今度は8月17日のトランクビルドにて Bug 345510 – Add <textbox type=”number”> がFixされ、スピンボタン付きの数値入力用テキストボックスが利用可能になった。通常の textbox 要素に type=”number” 属性をセットし、入力可能な最小値（min属性）、最大値（max属性）、増減（increment属性）を指定してやれば、思い通りにスピンボタンが動作してくれる。
また、属性 wraparound=”true” によって最小値と最大値が循環して入力できるようになる。また、属性 decimalplaces=”3″ などとすることで小数点以下何桁まで表示するかを指定可能である。

<textbox type="number" min="80" max="250" increment="10" />

詳しくは: chrome://global/content/bindings/numberbox.xml

何気なくScrapBookのbackupフォルダを覗いてみたところ、なぜか一番新しいバックアップファイルが7月31日に生成されたもので、8月以降およそ2週間まったくバックアップファイルが生成されていなかった。

これは何か怪しいと思い、バックアップ処理を細かく調べたところ、バックアップファイル名の日付が何日前かをチェックする処理において、なぜか本日生成されたばかりのバックアップファイルが200日以上前のものだと判断され、即座に削除の対象にされていた。
ScrapBook では Firefox 起動時に本日付のバックアップファイルが存在するかを確認し、もしなければ本日付のバックアップファイルを生成し、なおかつ古いバックアップファイルの削除処理を行うという仕様になっている。したがって、 Firefox を起動する度に本日付のバックアップファイル生成→本日付のバックアップファイル削除、という処理が8月以降ずっと繰り返されていたというわけだ。

ではなぜ8月以降、バックアップファイルが何日前かを算出する処理がうまくいかなかったのだろうか。OSの設定が狂った、夏時間特有の問題、2つのDateオブジェクトの減算で型変換がうまくいっていない等の原因を考えたが、色々追求した結果、parseInt(“08”) が 0 になることが原因だと判明した。

alert( parseInt("08") );    // 「0」が表示される

今まで parseInt というJavaScript の組み込みグローバル関数は、string 型で表現された整数を、number 型に変換するだけの単純なものだと思っていたが、実は string 型で表現された小数や8進数や16進数や文字列も変換可能である。その際、引数として渡した string 型の値をどのような形式で変換するのかは自動で識別されるため、先頭に0をつけている場合は8進数とみなされ、”08″ が 0 に変換されるのである。また、第二引数に基数 10 を指定することで思い通りに10進数として変換させることが可能である。

alert( parseInt("08", 10) );    // 「8」が表示される

この parseInt(“08”) が原因となるバックアップ処理に関するバグは、8月になると突如発生する時限式バグといえよう。運良く2週間ほどでバグに気づけたことが不幸中の幸いである。このバグを修正したバージョン (1.1.0.2) はすでにリリース済みである。

ところで、ScrapBook を世に公開して間もない、非常に初期のバージョンにて、2004年10月になると突如取り込んだデータが上書きされ続けるという大変恐ろしい時限式バグが発生したが、このときの原因も今回のバグの原因と通ずるものがあり、年・月・日を加算するときに型の自動変換に頼っていたためにバグが引き起こされていた。

var y = 2004;    // number
var m = "09";    // string
var d = 30;    // number
var ymd = y + m + d;
alert(ymd);    // 「20040930」が表示される

9月30日までは、数値 9 を 文字列 “09” にして加算をしていたため、 2004 + “09” は “200409” になってうまくいっていた。

var y = 2004;    // number
var m = 10;    // number
var d = "01";    // string
var ymd = y + m + d;
alert(ymd);    // 「201401」が表示される

しかし、10月1日になると、数値 10 は文字列に変換せずに加算していたため、 2004 + 10 は 2014 になってしまった。

var y = 2004;    // number
var m = 10;    // number
var d = "01";    // string
var ymd = y.toString() + m.toString() + d.toString();
alert(ymd);    // 「20041001」が表示される

数値か文字列かわからないような値同士を加算するときには、必ず toString や parseInt を使って正しい型に変換してから加算をしなければならない。

parseInt のリファレンス：
Core JavaScript 1.5 Reference:Global Functions:parseInt – MDC

一般的に、ローカライズ可能な文字列の定義は、以下のように2通りの使い分けが必要となる。

(1) XULファイル内で使用する文字列
DTD ファイル内に実体参照として定義し、XULファイル から DOCTYPE 宣言によって呼び出す。

(2) JavaScript内で使用する文字列
properties ファイル内に定義し、XULファイル から stringbundle 要素によって呼び出す。その例を以下に示す。

sample.xul

<stringbundle id="sampleString" src="../locale/sample.properties" />

sample.properties

sample.hello=こんにちは

sample.js

var sampleString = document.getElementById("sampleString");
alert(sampleString.getString("sample.hello"));

しかし、時にはわざわざ DTD ファイルとは別に properties ファイルを作るのが面倒なケースもある。そのような時、DTD ファイル内で文字列を定義し、XUL ファイル内に直接 JavaScript を書き込んでその中で実体参照を用いるというテクニックがある。この場合、JavaScript を CDATA セクション内に記述すると実体参照が行われないので注意する必要がある。

sample.xul

<!DOCTYPE window SYSTEM "../locale/sample.dtd">
...
<script type="application/x-javascript">
    var gSampleString = {
        hello : "&sample.hello;"
    };
</script>

sample.dtd

<!ENTITY sample.hello "こんにちは">

sample.js

alert(gSampleString.hello);

designModeとは多くのWebブラウザに搭載される簡易HTML編集機能であり、おもにブログ投稿やWebメール作成のためのリッチテキストエディタとして使用される。

javascript:void(document.designMode='on')

ScrapBookで保存したページを閲覧時、このようなブックマークレットを用いてデザインモードを有効にすると、ScrapBookの編集機能ではどうしても不可能だった編集ができるようになる。たとえば、ある文章の一部を改変したり、段落を一つ増やして自分のコメントを文中に挿入したり、ブロック要素の幅を変えたり、他のページからコピーした画像や文章の断片をそのままページ中に貼り付けたりできるようになる。
こういった編集をしたいというユーザからの要望に対しては、designModeのブックマークレットを薦めてきたが、いっそのことScrapBookのステータスバーアイコンのメニューなどからdesignModeのオン／オフができるようにしたら面白いかもと思った。しかしdesignModeで色々試しているうちに、色々とおかしな現象が多発したので、Bugzillaを調べてみたところかなりバグがあるようである。
Bug 287707 – After page had designmode on, there are still several issues
Bug 304994 – iframe with designMode=on breaks when you navigate to another loaded page and then back
特にBug 287707で報告されているように、次のページへ遷移しても何も表示されないというバグが致命的なので、designMode切り替えメニューの搭載は当面先送りにした。

4月に行われた Mozilla Party にて、ファイルを解凍したりするためのXPCOMである nsIZipReader はあるけど、逆にファイルを圧縮して書庫を作るためのXPCOM（つまり nsIZipWriter）が今のところ無く、将来的にこれが toolkit の一部として Firefox 本体に実装されたら、拡張機能でできることが広がって大変喜ばしいのであるが…という話をしたところ、Darin Fisher 氏からサマーなんたらにて発表？されるという情報をいただいた。

これについて調べたところ、 Mozilla Wiki に Google Summer of Code ついてのページがあり “Create a scriptable jar writer or zip writer” としてアイデアがエントリされているのを発見した。
Community:SummerOfCode06 – MozillaWiki

Summer of Code とはどうやら学生参加型のオープンソース開発プログラムのようである。この Wiki のページを見ると他にも色々と面白そうなアイデアが書いてある。

7月21日のトランクビルドにて Bug 155053 – Make the spinbuttons a real widget がFixされ、XULのスピンボタンが実装された。使い方はいたって簡単。 spinbuttons 要素に onup, ondown イベントハンドラを設定することで、△ボタンや▽ボタンの動作を設定できる。

<textbox value="0" />
<spinbuttons onup="this.previousSibling.value++;"
             ondown="this.previousSibling.value--;" />

また、 increaseDisabled, decreaseDisabled プロパティをセットすることで△ボタンや▽ボタンを無効にすることができる。
詳しくは: chrome://global/content/bindings/spinbuttons.xml

7月13日のトランクビルドにて Bug 201499 – Tree widgets should support editable content within hierarchical data structures (inline edit) がFixされ、ツリーセルのインライン編集が可能になった。 xul:tree 要素の editable 属性を true にしてツリーセルをダブルクリックすると、テキストボックスが出現してツリーセルの文字列を編集できる。 InternetExplorer のお気に入りを「名前を変更」したときの動作に近い。
ただし現時点で最新の Minefield のナイトリービルドで試したところ、ダブルクリックしてテキストボックスが一瞬現れた後またすぐに元に戻ってしまう。本来の動作としては、テキストボックスが現れた後、その中の文字列が選択状態になるはずだが、選択状態にする処理によって編集状態が終了してしまうようだ。動作を確認するためには chrome://global/content/bindings/tree.xml を一部修正する必要があった。また、他にも編集中にツリーのカラム幅を変えてもテキストボックスの幅は変わらなかったり、いくつか問題があるようだ。

1. タブの閉じるボタン
   無くても我慢できるけど、あったらあったで便利そうではある。けど、タブがひとつしか無い時に閉じるボタンが表示されなくなるのは困る。何も見ていないときは空白タブにしておきたいので。
   
2. タブオーバーフロー
   タブがあふれたときに表示されるボタンの大きさは適当だけど、その中の三角形が小さすぎて存在感が薄い。無いよりはましだけど決して使いやすいとはいえない機能。もっとましなユーザーインターフェースはありそうだと色々考えてみるものの、いいアイデアは浮かばない。
   
3. 閉じたタブを元に戻す
   Undo Close Tabは今まで All-in-one Gestures に頼っていたが、本体に備わったのはうれしい。ただ、タブを右クリックしての操作はあまり使わないだろう。結局マウスジェスチャーに頼ることになりそうだ。
   
4. メニューバーの履歴メニュー
   メニュー直下の「戻る」「進む」「ホーム」は間違いなく使わない。履歴10個表示も要らない。でも、新たに追加された「最近閉じたタブ」のリストはかなり重宝しそう。どうせなら「閉じたタブを元に戻す」をここに配置して欲しかった。
   
5. RSS フィードの整形表示
   ありがたい機能。Sageは更新チェックだけやって、整形表示は Firefox に任せる、という使い方ができたらいいな。
   
6. 検索プラグインの管理
   これはあって当然の機能だろう。欲を言えばセパレータの追加や、個々のエンジンを一時的に無効にする機能があればよかった。
   
7. アドオンマネージャ
   拡張マネージャはよく使うけどテーママネージャはめったに使わないので、統合してもあまりうれしくない。自動でABC順に並ぶのは潔くて良い。選択している項目にはボタンが表示されるわけだが、項目を選択するといちいち縦幅が変化する動きがあまり好きでない。あと Firefox 1.5 でもそうだったが、項目クリック時の反応の鈍さも気になる。もう少し動作が軽くならないかな。
   
8. フィッシング対策機能
   お世話になることは無いと思うけど、万が一に備えて有効にしておいた方がよさそうな機能。「ローカルに保存されているリスト」というのはウィルス定義ファイルみたいに定期的にアップデートされたりするの？
   
9. クラッシュ時のセッション復元
   突然のクラッシュに泣かされることは少なからずあったので、これはありがたい。逆に、任意のタイミングでセッション保存や復元もできたらうれしい。
   
10. インラインスペルチェック
    英語圏のユーザには重宝するかもしれないけど、今のところあまり必要性を感じない。 Firefox と打ち込んだだけでいちいち指摘されるし。デフォルトで無効、使いたいときだけ右クリックから有効にするようにしたい。
    
11. Web検索ボックス
    検索エンジンの選択を右側のボタンから行うのは慣れないし、なんでわざわざIE7のマネして改悪するのだろう。と思いきや、今後のバージョンでは左側に戻されるようだ。そうなると、虫眼鏡ボタンはもはや邪魔なだけと思われる。userChrome.css で入力履歴のドロップダウン表示を可能にしている場合はなおさら邪魔だ。
    あと、今までは横幅狭すぎと思ってたら、今度は横幅広すぎになった。
    
12. Web検索ボックスでのGoogleサジェスト
    一見面白い機能なんだけど、実際のところ、↓キーを押して候補から選択する手間を考えるとキーワードを入力しきってしまった方が確実だし速いに違いない。いちいちインターネット接続されるのもうっとうしいし。
    
13. 検索プラグインのフォーマット変更
    今までのへんてこなSRCファイル＋PNGアイコンの組み合わせからXML単独となり、すっきりした。POSTメソッドにも対応したもよう。旧形式との互換性はどうなんだろう？
    
14. ブックマークのマイクロサマリ
    わかりづらい機能だし、こんなの誰が望んでいるんだろうと思っていたが、いつのまにか消滅した？
    
15. JavaScript 1.7 のサポート
    色々変わったなかでも let は特に重要そう。あと、var [foo,bar] = “hoge<>huga”.split(“<>“); みたいなことができるのも良い。
    
16. Client-side session, persistent storage
    面白そうだけどすぐには効果的な使い方はわからない。
    
17. 新しいインストーラ
    どうでもいい。