たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能!
タブバーがtabbrowser要素の中から取り出されて1つのツールバーになったということで、タブ関係の挙動を変える系のアドオンが死屍累々なんじゃないかと不謹慎にもwktkしてるわけですけれども。特に影響が大きくて話としても「あーそりゃそうなるわな」ってのが分かりやすいのは、やはりタブバーの表示位置の変更機能ですよね。
今までは、Firefoxのメインウィンドウの中身は簡単に言えばこんな要素構造になってた。
<toolbox>
<toolbar/>
</toolbox>
<tabbrowser>
<tabbox orient="vertical">
<tabs orient="horizontal">
<tab/>
<tab/>
</tabs>
<tabpanels>
<browser/>
<browser/>
</tabpanels>
</tabbox>
</tabbrowser>
XULのレイアウトは主にMozillaの関係者からCSS3に提案中のflexible box layoutに基づいてるんだけど、
-moz-box-orient: horizontal
(XUL要素の属性指定だとorient="horizontal"
)だとボックスの中身が横に並ぶ。-moz-box-orient: vertical
(XUL要素の属性指定だとorient="vertical"
)だとボックスの中身が縦に並ぶ。ordinal
の値)の順にボックスが並べ替えられて表示される。これだけの事を組み合わせれば、タブバーの位置を上下左右好きな位置に移動できた。
という具合。
ところが、bug 347930のパッチで要素構造が以下のようにガラッと変わった。
<toolbox>
<toolbar/>
<toolbar id="TabsToolbar">
<tabs orient="horizontal">
<tab/>
<tab/>
</tabs>
</toolbar>
</toolbox>
<tabbrowser>
<tabbox orient="vertical">
<tabpanels>
<browser/>
<browser/>
</tabpanels>
</tabbox>
</tabbrowser>
こうなると、単純にボックスの並び順やら並べる方向やらを変えただけではタブバーの位置を動かせない。
ドン詰まりですね。
alice0775さんの調べによると、タブバーの位置を変える機能を持ってる他のアドオンでは、tabsを一旦DOMツリーから取り外して別の位置に挿入し直すという方法で、タブバーの表示位置変更を実現しているらしい。
しかしこのやり方だと、tabsがDOMツリーから取り外されるより前に他のアドオンが行った初期化処理の効果がリセットされてしまう場合がある。リンク先のエントリでいくつか挙げられてる懸念がそれ。
本当だったらFirefox本体の方でなんとか面倒を見て欲しい(タブバーの位置変更を行う機能を持たせて、位置が変わる前と後でイベントを発行するようにするとか)所なんだけど、責任者の人達をIRCで英語で説得する自信は全く無いチキンでTOEICスコアめためたで英語音痴な僕は、アドオン側でなんとかする方法を考えないといけない。しかし、最も単純なやり方(DOMツリーの改変)だと他のアドオンとの競合という点で弊害が大きすぎる。
そういうわけで、ちょっと考えてみました。DOMツリーをいじらずにタブバーの位置を変える方法を。
ヒントになったのは、XUL/Migemoの「タブバーの下に検索バーを移動する」機能や、Unified Sidebarの「サイドバーを縦型タブバーの下半分に表示する」機能の実装方法。
これらのアドオンでは「検索バーやサイドバーを表示したい位置にmarginやpaddingでスペースを設けて、検索バーやサイドバーをCSS2のポジショニングでその位置に重ねる」という方法で、DOMツリーを改変することなく要素の表示位置だけを変更している。また、ウィンドウの大きさなどが変わった時には、resizeイベントを捕捉して表示位置や要素の表示サイズを自動調整するようにしている。
ツリー型タブのMinefield 3.7a4pre対応でも、基本的にはそれと同じ方法を使う事にした。ただ、タブバーの幅をリサイズできるようにするsplitterを、ポジショニングで表示位置を変えられた状態向けにゼロから作りなおすのは面倒だったので、tabboxの中にダミーのhbox要素を挿入して、splitterは普通にXULのsplitterを使い続ける事にした。
<toolbox>
<toolbar/>
<toolbar id="TabsToolbar">
<tabs orient="horizontal">
<tab/>
<tab/>
</tabs>
</toolbar>
</toolbox>
<tabbrowser>
<tabbox orient="vertical">
<hbox/>
<splitter/>
<tabpanels>
<browser/>
<browser/>
</tabpanels>
</tabbox>
</tabbrowser>
このようにした上で、
とする事で、ぱっと見は今までと同じような挙動を実現しつつ、タブ周りのDOMツリーは一切破壊しないという実装になった。
ツリー型タブのやり方とTab Mix Plus等のやり方のどっちがいいかは、一概には言えない。どちらにもメリットとデメリットがある。
ただ僕は、ツリー型タブで採用したやり方の方が「他のアドオンが全く動かなくなってしまうような衝突の仕方はしなくて、仮に衝突しても最小限の労力でなんとか回避できる可能性が高い」と信じている。
現在Firefox本体の側には、3.6以前のバージョンのFirefox向けに書かれたアドオンについて、Minefield 3.7a4pre以降でもそのまま動くようにするためのパッチも取り込まれている。ちょっとアドオンの作り方に気をつけさえすれば、タブをダブルクリックした時の挙動を変えるとか、リンクから開いたタブの位置を制御するとかいった単機能のアドオンは、ほとんど何も手を加えずにMinefield 3.7a4pre以降に対応できるようになってる。
しかしながら、Tab Mix Plusが現在採用している(らしい)DOMノードを切り貼りするやり方では、「ほっといても他のアドオンがちゃんと動いてくれる」ようにはなりにくい。「DOMノードの切り貼りでタブバーの位置が変更された事」を検知して何らかの特別な初期化処理を行うようなコード、を他のアドオンの側に加えてもらわないと互換性を保てない。僕は、僕のアドオンと競合しないで使えるようにするために、他のアドオンの作者がわざわざ気を使ってくれるとは思えない。僕が作ってる物が、そこまで他のアドオン作者から特別視してもらえる存在だとは、思えない。
なので、僕がアドオンを作る時はなるべく、他のアドオンの側に変更が必要になるような作りにはしないでおこうと思ってる。どうしてもそうなる時は、APIを提供してAPI経由でスッキリと連携できるようにしようと思ってる。そういう謙虚というか悲観的な姿勢が、「ユーザがどんなアドオンと組み合わせて使うかは全く分からない」アドオンを作る上では必要なんじゃないかと思ってる。
SCRAPBLOG : JavaScript 製 XPCOM で配列構造・列挙構造のデータをメソッドの戻り値にする
独自に開発したXPCOMコンポーネントに対して配列を渡したり、あるいは戻り値を配列で受け取ったり、ということをやる方法はいくつかある。上記エントリではコメント欄も含めると4つの方法が紹介されていて、そのうちコメント欄にある2つはJavaScriptの配列をそのまま受け渡せるという点で有用だ。特にnsIVariantインターフェースを使うやり方は、戻り値に使う時に余計な引数を定義しなくていいので、実際にそのXPCOMコンポーネントをJavaScriptから使う時にとても使い勝手がいい。
ということでXUL/Migemoでは積極的にnsIVariantを使ってたんだけど、これがMinefield(検証したバージョンは3.7a4pre)で動かなくなってた。
結論から言うと、これはnsIVariantインターフェースのIIDが6c9eb060-8c6a-11d5-90f3-0010a4e73d9aから81e4c2de-acac-4ad6-901a-b5fb1b851a0dに変更されたせいで起こっている問題で、nsIDOMRangeのIIDが変更された時に起こった問題と同様の物だ。
変更が入ったのは昨年9月で、HTML5の新しい仕様に対応するための作業の一環として、何らかの必要があってインターフェースに機能を加えると同時にIIDも変わったらしい。nsIVariantはFROZENなインターフェースじゃないから、nsIDOMRangeの時のようにIIDが元に戻されることは多分あり得ない。よって、考えられる対策は以下のいずれかということになる 。
JavaScriptコードモジュールにするデメリットは、Thunderbird 2で利用できなくなってしまう点と、APIが変わってしまう点。バイナリを分けるデメリットは、リリースの時の作業がめんどくさくなる(XPIファイルが2つになるので)という点。どっちを選んでも大変なのは変わらない……
APIが変わってしまうことは避けたかったので、結局、後者の方で対処することにした。
前から使ってるXPI生成用シェルスクリプトに起動オプションでサフィックスを指定できるようにして、
こんなショボいスクリプトを作って、前出のスクリプトと一緒に
call xpidl.bat xulrunner-sdk-1.9.2
bash makexpi.sh -n xulmigemo -v 0 -s "1.9.2"
call xpidl.bat xulrunner-sdk-central
bash makexpi.sh -n xulmigemo -v 0 -s "central"
てな感じで実行するようにして(make.bat / make.sh)、MozillaのFTPサイトからXULRunner SDKのファイル一式を入手して、
という感じにファイルを配置するようにした。
XPIを作りたい時にはXULRunner SDKが必要になってしまうけど、スクリプトいっこ走らせれば xulmigemo-mozilla-1.9.2.xpi と xulmigemo-mozilla-central.xpi という風に複数のXPIを出力できるようになったので、リリースにかかる手間は少しは軽減された……のかな……
追記。Gomitaさんのコメントを見て、IDLファイルからincludeの行を消して試してみたら、それでちゃんとコンパイルできた。なんでだ……!!!
えーと。ずっと勘違いしてたんだけど、#include "nsISupports.idl"
みたいな行は、interface xmIXMigemoFileAccess : nsISupports
てな感じでインターフェース定義の継承元に別のインターフェースを使う場合にだけ必要で、戻り値や引数に使う分には単に interface nsIVariant;
とだけ書いておけばいいみたいですね……そうすると、コンパイル時には余計なIIDが含まれなくなって、Firefox 3.6まででも3.7以降でも問題なく使えるXPTファイルが作られるみたい。
まとめ。
interface インターフェース名;
と書く。interface インターフェース名;
だけ書く。そんなわけで、xmIXMigemo.idlの頭の所はずいぶんスッキリしました。
#include "nsISupports.idl"
#include "nsIObserver.idl"
interface nsIObserver;
interface nsIFile;
interface nsIVariant;
interface nsIDOMWindow;
interface nsIDOMDocument;
interface nsIDOMRange;
interface nsIDOMElement;
interface nsIDOMNode;
/* Utilities: You can use them for your language without additional implementation. */
[scriptable, uuid(4aca3120-ae38-11de-8a39-0800200c9a66)]
interface xmIXMigemoFileAccess : nsISupports
{
(以下略)
「Split Browser」という名前で公開してたアドオンについて、「名前かぶってるから変えてんか(大意)」というメールが来た。2004年からある「SplitBrowser」という名前のWebKitベースのブラウザの作者の人だった。
こっちの奴は2007年が最初のリリースなので、どう考えてもこっちが悪いですよね……ということで名前を変える事にした。edvakfさんが呟いた「SplitFox」という名前がナイスだと思ったんだけど、検索してみたところそういうハンドルで活動してる人がいたので、これも駄目かーと思ってちょっとひねって「Fox Splitter」にした。
リポジトリ上のファイルは全部修正したけど、リリースはしてないので、今インストールすると表示は「Split Browser」のままです。名前が変わるのは次のバージョンからという事で、今はまだWebページだけの変更。
I was wondering if there is any way to have it open inside All-in-One Sidebar. If so could you please tell me how to do it?
ツリー型タブの縦型タブバーをAll-in-One Sidebarの中で表示する方法があるなら、教えてもらえませんか?
Unfortunately, there is no way. Tree Style Tab's vertical tab bar is not a "sidebar panel", so, it cannot be showin in the AIOS sidebar.
There is another addon "Tab Tree" which provide a sidebar panel of tree of tabs.
It is abandoned by the author, however, it is very similar to your requirement. He published it as a public domain software, so, if you can, you'll take over the project without any warranty.
By the way, I think that Unified Sidebar possibly help you.
残念ながら、方法はありません。ツリー型タブが提供する縦長のタブバーはサイドバー用のパネルではないので、All-in-One Sidebarの中に表示する事はできません。
他のアドオンで、タブのツリーのサイドバーパネルを提供する「Tab Tree」という物があります。
作者はこのアドオンをもう更新しないという事を公言していますが、これはあなたの求めているものによく似ています。彼はこのアドオンを、著作権を主張しないパブリックドメインソフトウェアとしているようなので、もしやる気があるなら、あなたはこのアドオンの開発を(許可を求めずとも)引き継ぐ事ができます。
あと、ひょっとしたらUnified Sidebarもあなたの役に立つかもしれません。
僕はXHTMLのルビ(小さな字で読み仮名をふったりするアレ)を使いたくてXHTML 1.1を選択してるんですが、過去にXHTML2で検討されてたl要素(パラグラフより細かい単位の「行」を示すための物)やiframeやなんかをどうしても埋め込みたくなって、しかしそのせいでバリデータでエラーが出てしまうのも嫌だったので、見よう見まねで頑張って独自の文書型宣言を書いてみたんですよ。いつやったのか忘れたけど、結構前に。
<?xml version="1.0" encoding="Shift_JIS"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd" [
<!ENTITY % XLINK.xmlns.attrib "xmlns:xhtml2 CDATA #FIXED 'http://www.w3.org/2002/06/xhtml2'">
<!ENTITY % Inline.extra "| xhtml2:l | iframe">
<!ELEMENT xhtml2:l (#PCDATA|br|span|em|strong|dfn|code|samp|kbd|var|cite|abbr|acronym|q|sub|sup|bdo|a|img|map|object|input|select|textarea|label|button|ruby|ins|del|script|noscript|xhtml2:l)*>
<!ATTLIST xhtml2:l
id ID #IMPLIED
class CDATA #IMPLIED
style CDATA #IMPLIED
title CDATA #IMPLIED>
<!ELEMENT iframe (#PCDATA|br|span|em|strong|dfn|code|samp|kbd|var|cite|abbr|acronym|q|sub|sup|bdo|a|img|map|object|input|select|textarea|label|button|ruby|ins|del|script|noscript|xhtml2:l)*>
<!ATTLIST iframe
id ID #IMPLIED
class CDATA #IMPLIED
style CDATA #IMPLIED
title CDATA #IMPLIED
longdesc CDATA #IMPLIED
src CDATA #IMPLIED
frameborder ( 1 | 0 ) '1'
marginwidth CDATA #IMPLIED
marginheight CDATA #IMPLIED
scrolling ( yes | no | auto ) 'auto'
height CDATA #IMPLIED
width CDATA #IMPLIED
>
]>
CGIを使ってIEにはこの文書型宣言を出さないようにしてますが、FirefoxとかChromeとかでトップページあたりを開いてソースを見れば、こういうのが頭にくっついてるのが分かると思います。
で、バリデータ的にはこれでvalidになったのでめでたしめでたしだったんですが、GeckoのDTDパーサ部分にバグがあるらしくて、この文書型宣言を正しく解釈してくれないんですよね。最後の]>
ではなくその前の>
の部分で文書型宣言が終わったものと見なされてしまうせいで、Firefoxでこのサイトのページを開くと、ページの頭に謎の]>
という文字列がくっついてしまう状態になってたのです。表示が崩れるのが嫌だったので、この]>
がテキストノードとしてページの頭に存在してる時は動的に削除するようなJavaScriptを書いて、長らくごまかしてました。
そしたら先日、W3CのHTML5のルビに関する議論の中で紹介されてたXHTMLルビサポートのページを見たという方(Leif Halvard Silliさん)がメールを下さいまして、以下のようなハックを使えばページの頭に謎の]>
が出てくる事を防げるよ、と教えてくれたんです。
<?xml version="1.0" encoding="Shift_JIS"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd" [
<!ENTITY % XLINK.xmlns.attrib "xmlns:xhtml2 CDATA #FIXED 'http://www.w3.org/2002/06/xhtml2'">
<!ENTITY % Inline.extra "| xhtml2:l | iframe">
<!ELEMENT xhtml2:l (#PCDATA|br|span|em|strong|dfn|code|samp|kbd|var|cite|abbr|acronym|q|sub|sup|bdo|a|img|map|object|input|select|textarea|label|button|ruby|ins|del|script|noscript|xhtml2:l)*>
<!ATTLIST xhtml2:l
id ID #IMPLIED
class CDATA #IMPLIED
style CDATA #IMPLIED
title CDATA #IMPLIED>
<!ELEMENT iframe (#PCDATA|br|span|em|strong|dfn|code|samp|kbd|var|cite|abbr|acronym|q|sub|sup|bdo|a|img|map|object|input|select|textarea|label|button|ruby|ins|del|script|noscript|xhtml2:l)*>
<!ATTLIST iframe
id ID #IMPLIED
class CDATA #IMPLIED
style CDATA #IMPLIED
title CDATA #IMPLIED
longdesc CDATA #IMPLIED
src CDATA #IMPLIED
frameborder ( 1 | 0 ) '1'
marginwidth CDATA #IMPLIED
marginheight CDATA #IMPLIED
scrolling ( yes | no | auto ) 'auto'
height CDATA #IMPLIED
width CDATA #IMPLIED
>
<?parser-hack ><!-- ?>
]>
<!--><?!-->
強調箇所がそのハック。処理命令(PHPのコード片を埋め込んだりするのに使うのと同じ奴)の記法でコメントとして解釈できる文字列を埋め込んで、問題の部分を無視させるという物のようです。バリデータに通しても、これでもvalidです。素晴らしいです。
同じような事をやってる酔狂な人がもしいたら役立てて欲しいと思ったので、氏に許可を得てエントリにさせて頂きました。Thanks a lot, Leif!
何故これがvalidなのかも考えてみよう。
<?parser-hack ><!-- ?>
><!--
という内容」を含んだ処理命令として解釈される。[
から]
までの間に登場しうる内容として処理命令も含まれている。そして、上記の箇所は一つの完結した処理命令である。よって、文書型宣言中に登場しても何ら問題ない。<!--><?!-->
><?!
という内容」を含んだコメントと解釈される。という具合で文法的には何も問題ないので、W3Cのバリデータはこれをvalidと判断する。きちんとXMLパーサを実装しているブラウザ上でも同様です。
一方、Geckoの解釈はどうか。これは「ソースを表示」での色分けを見るとよく分かる。
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd" [
Geckoはまず、この部分だけで完結した文書型宣言と認識する。「[
」で終わりと判断したのではなくて、その次の <!ENTITY
が来た時点で「あ、もう文書型宣言は終わってたのね」と見なしてるようだ。
<!ENTITY ~>
<!ELEMENT ~>
<!ATTLIST ~>
この辺はすべて、それぞれ別々の宣言として解釈されている。という事で、
]>
何もハックをしない場合はこの部分だけが取り残されてしまって、Gecko的にはこれが「XML的には不正だけどSGML的にはアリ」なテキストノードとして扱われて、ゴミとして表示されてしまうわけだ。
では、ハック有りの場合はどうなるか。
<?parser-hack ><!-- ?>
]>
<!--><?!-->
Geckoはこれを3つのノードとして解釈している。
<?parser-hack >
まずGeckoは、これを1つの処理命令と判断する。XMLの仕様では ?>
が来るまで処理命令の終わりにはならないんだけど、Geckoのパーサは >
で処理命令が終わったものと見なしてしまう。
<!-- ?>
]>
<!-->
これは当然1つのコメントになる。
<?!-->
最後、これも <?
から >
までで1つの処理命令と見なされる。
という事で、ハック有りの時はどの文字もテキストノードとして取り残されずに済むので、画面上は何もゴミが表示されずに済む。
こんなのよく考えるなー、と、読み解いてみて改めて感心しました。
撃たれると痛い「すべて彼女のために」 - 2010-03-01 - ゾンビ、カンフー、ロックンロールのレビューを見て気になったので、すべて彼女のためにを見てきた。東京だと有楽町、神奈川だと横浜、関西だと大阪で上映してるようです。って3館だけかい! これから増えるのかな? 毎週水曜の安くなる日でも夜の回は結構空いてました。
見終わった後、圧倒されて言葉が出てこなくなる。そんな映画でした。
会社で使ってるWindows Vistaがどういうわけか、ハイバネーションからの復帰にやたら時間がかかるわ復帰後ほっとくとブルースクリーンになるわで死にかけだったので、一縷の望みを託してWindows 7にアップグレードしてみることにした。(もしなんかのファイルが破損してるなら、そのファイルが使われなくなってくれないかなあ?と思ったので。)
これでまだ落ちるようだったら無駄なことに時間を使ってしまったということになるのでとても悲しいです。
ドラえもんの4次元ポケットについて真面目に考えてみた。
4次元ポケットの中には、外見から想像される容積より遙かに多くの物を格納することができる。また、内部空間はスペアポケットとの間で共有されているため、スペアポケットから入ってドラえもんのポケットから出てくるということもできる。(実際に、行方不明・回収不能になったドラえもんを発見するためにこの方法を使ったエピソードもある。)
4次元という物を正しく理解すると、どのようにすればこういった仕組みを実現できるのかが見えてくる。
4次元を理解するには、2次元と3次元を対比した場合を考えるのが手っ取り早い。
話を我々が暮らす3次元を基準にして考えてみよう。
こうして考えてみると、どこでもドアや道路光線や通り抜けフープ、ビッグライトやスモールライトやガリバートンネルも、おそらく同じ基礎技術に基づいて開発されているのだろうと考えることができる。
同じような理屈で、移動する物や大きさを変える物、形を変える物の「原理」を色々と説明することができる。ひょっとしたらタケコプターすらも、同じ基礎技術を使っているのかもしれない。ドラえもんが開発された22世紀というのは、このような4次元を扱う技術が高度に発達した時代なのかもしれない。
この考えの中で一番問題になるのは、「空間を折り曲げる」という所ではないかと思う。
ところで4次元ポケットは、ドラえもんに限らず誰でも任意の道具を取り出すことができる。また、ドラえもん自身ですら、混乱している時には望みの道具を一発で見つけることができない。この事から、4次元ポケットは利用者の思考を何らかの方法で読み取ってそれに対応する内容物を返す、汎用的な物体格納・運搬デバイスなのだと考えられる。
ケータイ世代の女性が企画:男の知らない“きれい”とは――4000枚以上の写真から完成したカシオ端末の「美撮り」 - ITmedia +D モバイル
リンク先の記事にある写真を2つのタブで開いて何度かタブを切り替えてみると、違いがよく分かる。「美撮り」の方は肌をソフトに・目を若干大きめに加工してあった。リアルタイムに自動で行うちょっとしたフォトレタッチだけど、よく考えてみれば今の携帯端末はそれなりの性能のPCみたいなもんなんだから、ソフトウェアさえ載っければこういう事は造作もないんでしょうね。そういえば懐かしい記事で、美人フィルタなんてのもありましたね。
こういうので撮った写真を「偽物だ」と言うのは容易いけど、こういうリアルタイム自動フォトレタッチがあるといいなあと自分も思いますよ。
自分の携帯のカメラとかで彼女の事を撮っても、後で見返してみると、ちょっとションボリする写りで残念になる事がある。肉眼で見てその時感じた「この瞬間の画が欲しい」と思った映像と比べて、蛍光灯の光が青白かったり顔に影が落ちて薄暗くなってたり。一眼レフのカメラを借りて撮った写真は、それに比べるとまだ「思った通り」に近い写真になってたと思う。でもそれでも、肉眼で見た時の通りというわけではない。
人の目というのは、眼球を通して網膜に映った光を視神経で脳に伝えてそこで改めて映像として再構築する物らしいけど、思うに、その過程で周囲の様子とか音とか匂いとか思い入れとかいろんなものが反映されて、物理的な形状とは違う人それぞれの見え方になる物なのではないだろうか。だから、3次元の物理的な形状をレンズを通して2次元に写し取っただけの写真を見た時に、他の情報が欠けているために「あれ、なんでこんなにショボく見えるんだろう……」ってなってしまうんじゃないだろうか。動画の方がまだマシに見えるのは、情報の欠落が写真に比べればまだ少ないからじゃないだろうか。水彩画や油絵なんかの絵が時に写真よりも美しく見えるのは、僕ら凡人が実物を見ても感じることのできない美しさを、画家が敏感に感じ取ってキャンバスに描き付けるからだったりするんじゃないだろうか。
いや、単に、僕のカメラの扱いがなってないだけというのも多分にあるとは思いますけどね。カメラの使い方を心得てる人達なら、同じカメラでもきっと、僕が撮った写真よりずっといい写真を撮れるはず。
ともかくフォトレタッチというのは、写真というメディアの特性や、あるいは撮影者の腕のヘボさによっていくつかの情報が欠落してしまった結果の画像に対して、欠落していた情報を加味した補正を加えて、自分の目でその人や風景を直接見た時に感じていた物に近い情景を再現する作業なのだと僕は思う。「偽物の像を造る」作業ではなく、「自分の記憶に焼き付いた唯一無二の『本物』を復元する、再現する」作業なのだと思う。CGを駆使した映画というのも、偽物を作ってるんじゃなくて、監督の頭の中に思い浮かべられた映像を再現してるんだと思う。(絵を描くという作業だってそもそも、思い浮かべたイメージを画面上に正確にトレースする作業なんですよね。だから、完成図を細部まで思い浮かべる想像力と、それを正確に描写する力とが重要になる。グラデーションがどうとかのテクニックは、思い浮かべた物を画像として再現するための道具でしかない。)
写真を撮るのが下手糞な僕でも、彼女を見て「かわいいなあ」と思った時の感動をそのままフレームに収められたら嬉しいだろうなあと、僕は思うんですよ。そのために何十万円もするカメラやレンズや撮影環境を整えなくとも、いつでも持ち歩けるサイズの携帯電話の組み込みのプログラムで補えるのなら、それはそれで手軽に使えて嬉しい便利な道具だと思うのです。
This is an translated version of my another entry, evalが危険でそれ以外の方法が安全だと思ってる人へ . This is an objection for the entry: Five wrong reasons to use eval() in an extension written by Wladimir Palant.
Recently I updated Source Viewer Tab and Tree Style Tab. However, when I uploaded the latest version to AMO, both files were retained in the sandbox, never made public by AMO editors. They said with one mouth: "Your add-on uses the 'eval' function unnecessarily, which is something we normally don't accept. There are many reasons *not* to use 'eval', and also simple alternatives to using it. You can read more about it here: http://adblockplus.org/blog/five-wrong-reasons-to-use-eval-in-an-extension"
I know the point of their blames very well, because I read and translated the entry to Japanese for my understanding. When I got a rejection about another addon, I got just same comment.
Now I have an objection about indiscriminate rejections by "too many eval()
s" like this.
First of all, there is no "wrong" use of eval in any JavaScript codes (not only my addons). All of evals are "right" if it does its own work correctly.
For example, by the HTML specification, <em> is defined as "means emphasizing", "cannot appear in <title>", and so on. If you write <em> against the definitions, your HTML will be "invalid".
How about eval? 15.1.2.1 eval (x)
in the ECMAScript specification describes about the function. It just says: runs the specified string as a script. There is no cautionary statement about the purpose of using eval.
There is no "wrong" use, it is just "dangerous" use. There are many usecases: some is high-risk, some is low-risk. But, they all evals are "right" use if it works as required by the spec. So, I think that it is a suitable subject for the entry: "Five dangerous use of eval()
in an extension".
Risks of eval have to be managed, in other words, risk-managed evals are useful tool to extend Firefox. For end users, I think some eval should be allowed if it is safe enough in the case. "Eval? No, no, it is evil function! Don't use it anyway!" - I think that is slapdash work.
When you get 5-minute recipes via HTTP, do you untrust it anyway? Because it is insecure protocol, you cannot trust any information without SSL? Note, VeriSign certifies that the website you are accessing via HTTPS is surely hosted by the author, but he doesn't certify that the author is not evil. If you cannot trust any people via internet, you have to live offline - it's a internet phobia. In many cases you maybe trust them anyway if it is low-risk.
In the entry, he negates any eval without considering about its risk if it is out of the "valid uses". I think it is just a eval phobia.
I agree to blame some cases of 5 cases in the entry. The 1st (parsing JSON), the 2nd (accessing to properties dynamically), and the 4th (running event handlers of HTML or XUL elements) - those three cases must be blamed because they possibly run untrusted scripts from the Web as privileged. This is just same to caution about SQL injections for web apps.
I totally agree this topic. I also think any developer must be careful to make eval isolated from the Web. If my addons are rejected because they have this security issue, I totally back the judgment up.
So, how about my cases?
Both addons, Source Viewer Tab and Tree Style Tab, use eval only for injecting codes to functions in Firefox (and other addons). They never get codes from the Web. If editors decided to reject those addons by the reason, like "This is dangerous because it includes eval! Eval can run codes from the Web!", then it means: they reviewed addons without reading codes, and just checks warnings by the "not perfect" validator.
If so, I cannot agree to the decision. We shouldn't overestimate the power of the validator on the AMO system, because it can detect only a few patterns which are defined as "dangerous". It doesn't parse the JavaScript, it only reports the matching result about simple regular expressions, it cannot detect dangerous codes from obfuscated programs.
You have to judge case by case whether the eval is danger or not. Same about XBL hacks, CSS hacks, replacing of functions, and others. "Yes, this doesn't use eval. I accept it." "Oh, this uses eval. This is wrong. I reject it." Such a rash judgment possibly jeopardize people who download addons from AMO. I believe that we should review sources by our eyes to detect dangerous code cleverly obfuscated, even if it take time.
All of evals in Source Viewer Tab and Tree Style Tab are used to inject codes to functions of Firefox, it is the 5th case described in the entry. In the entry, he blames this use because:
And, he said that we should use "less dangerous" ways like:
func.apply(this, arguments)
.Object.watch()
.In other words, in the entry he said that "those ways are safer than eval".
I think it is an unfair suggestion. If you talk about risk of those cases, you should think other risks too, which are not listed in the entry. We also would like to avoid eval if at all possible. However, in our cases eval is the way really better than others.
Methods to extend Firefox can be sorted as:
Object.watch()
or other ways.One addon can use multiple ways above, but we can call it "safe" addon if it uses only "stable APIs". Otherwise they are possibly unstable. Any addon using unstable ways possibly breaks Firefox and other addons. Themes also.
He said that the "less dangerous" way is safer than eval. But, actually it possibly isn't. For example, I tried to watch the toggling of the Sidebar in Firefox 3.6, by document.getElementById("sidebar-box").watch("hidden", ...)
. Then it breaks the original behavior of XUL element - the Sidebar was never toggled. (So I had to use an event listener for the "DOMAttrModified" generic event.)
Another case, if you wrap the original function by a new function, any other addon which aimed to inject codes to the original function will never work. Hmm, "Because it is evil. Evil addons using eval must die!" Don't say that. It is the fact, you didn't take care about people who use addons with eval.
By the way, there are features which cannot be implemented without injecting codes into existing functions. Dorando told about those addons in the comments to the entry. The conclusion of the entry is "don't do it, you should not do it". However, if you cannot explain how dangerous eval is than others, it is just a tautology: "you should not do it, because it is wrong use of eval." and "it is wrong use of eval, because you should not do it."
On this point, both methods (eval and the "less dangerous" way) have same risk. He said that eval will never work if the definition of the function changed. However, the "less dangerous" way will collapse too if the original function is renamed. It is just a bias that functions will be never renamed in security updates. There is no "rule" like this.
Moreover, if you wrapped two functions A and B, expecting they work as "A-mod => B-mod", the hack will break down if only one mate changed by security fix. We cannot imagine how terrible thing caused is. Not only updating of Firefox, but conflicting to other addons too.
Anyway, we addon developers must catch up changes in any update of Firefox. It is the common issue for any addon which uses unstable ways to extend Firefox. I think blaming like "how terrible eval is than wrapping original functions" is nonsense. More importantly, I believe that we should talk about providing failovers for unexpected matters.
To put it bluntly, any addon is just a "dynamic patch". If you use Linux, you possibly download patches from ML or other places, apply it to the source, and build binaries. It is not uncommon sight. And, it is also important note in those cases: Don't apply the patch to any revision different from the base of it. Using addons on unverified versions of Firefox is just same to that.
If we use eval hack, only "codes should be replaced" and "codes should be injected" will appear in the source.
Generally reading source codes like this is certainly hard, because we have to refer the codes of the function which is being overwritten. Instead, there are less codes and sources become compact. If it is very simple like replacing from "width" to "height", it will be human readable enough. So know-how to keep maintainability and compatibility is important for this hack.
Even if you choose the way to wrap original functions, only fragmentary codes will appear in the source too. "Pre-operations", "post-operations", "wrapping functions", "watching functions for property changes", and others. Moreover, if you cannot get the result of operations by the original function as its returned value, eventually you have to know well how the function work.
In this case, if you want to implement a feature which require injection of some codes into the logic of an existing function, you need to copy the complete codes of the original function into your addon (of course you have to modify it.) Then, too many codes are possibly duplicated, so:
This is common to the topic about maintainability. AMO editors finally have to review addons with reading of their sources. If there are tricky codes or too many/long lines, then the cost of reading source codes increases. On this point, both eval hacks and wrapping hacks are similarly tricky.
Although if updates of addons are always rejected by the reason: "there is any eval", then, it becomes a new common practice: writing codes without eval anyway, with tricky hacks, even if they become hard to read. Otherwise the update won't be accepted. It is also a tautology: "we should not use eval, because they never accept codes including eval." and "they don't accept eval hacks because we should not use it."
As I described, I think evals in Source Viewer Tab and Tree Style Tab are not unnecessarily. In other words I believe that those evals are the best way to implement the feature with keeping compatibility. I think those evals are not absolutely dangerous than the "less dangerous" ways described in the entry, and I also think there are no alternative ways to do it.
How many people who says "eval is dangerous than others" actually read and reading the source codes of Mozilla products? Trying to extend Firefox even if there is no stable API? Catching up updates of Firefox constantly? Trying to solve compatibility problems with other addons? I'm feeling blue.
Only XPCOM components are really stable APIs, which are marked "FROZEN" in their IDL files. Otherwise they are absolutely unstable. There are only a few "FROZEN" APIs, preferences I/O, W3C DOM, etc. JavaScript functions in the browser window are very unstable. Even the FUEL - which was the component advertised as providing stable APIs independent from Firefox versions - is possibly removed from the next major release of Firefox. Yes, this is the Mozilla. I think it is just a kidding: "eval is dangerous, wrapping original functions by new functions with the name same to originals is safer than it."
In conclusion, I think it is unjust treatment that addons are retained in the sandbox because "they have evals".
To reject spams, you have to answer a quiz to comment to this entry. "今の日本の首相の名字(ひらがなで回答)" means: the family name of the current prime minister of Japan, in "hiragana". You'll see the answer from wikipedia (Japanese version of the page).