赤心慶福

appsweets akahuku labs.

cfx to jpm #2

Posted on 2015/09/08 by akahuku

などといいつつ、jpm の動作をいろいろ見ている。

cfx と同様、[cci]jpm xpi[/cci] とすることで xpi を生成することができる。ただし、[cci]–pkgdir[/cci] オプションや [cci]–update-link[/cci] オプションがどういう訳か削除されている。前者は、xpi をアーカイブする際のベースディレクトリを指定する。これがないということになっても、単に [cci]cd && jpm xpi[/cci] などとすればよいのでそれほど問題ではない。しかし後者が問題だ。

[cci]cfx xpi[/cci] においては以下のオプションが有効で:

–update-link: 拡張を自動更新する際の最新の xpi ファイルの場所を指定する。このオプションを指定すると、cfx は update.rdf を生成する
–update-url: 拡張を自動更新する際の更新情報を示す RDF ファイルの場所を指定する。この情報は xpi 内の install.rdf に埋め込まれる

この違いはとてもわかりにくい。前者は [cci]–location-of-latest-xpi[/cci]、後者は [cci]–location-of-update-manifest-rdf[/cci] などと脳内で変換する必要がある。

で。jpm では前述の通り [cci]–update-link[/cci] オプションが削除されている。従って、jpm は update.rdf を一切生成しない。そのため jpm ベースの開発サイクルでは update.rdf を自前で生成しなければならなくなっている。なぜこのような仕様変更が行われたのかはよく分からないが、自前で update.rdf を制御する場面というのは、つまり拡張を AMO 以外の場所で配布する状況ということだ。AMO に載せるのなら気にする必要はない。つまり update.rdf の生成機能が取り除かれているのは野良拡張の配布をやめろという暗黙的な圧力なのかもしれない。

この手の悪意に満ちた嫌がらせはこれだけではない。拡張に自前で署名を施すためのツールとして McCoy というものがあるのだが、これもあからさまに使いにくい。そして、「使いにくいけど将来的には直すので期待してね！」なんつったりしちゃったりしてるのだが、もちろん今現在になっても使いやすくなってはいない。

一方で Mozilla は

インストールを Mozilla の配布チャンネルに限定することは余計な制約であると私たちは考えます

とかなんとか言っている。なーんか、言ってることとやってることが全然違いますね。こんなことばかりやってると、加速度的に信用を失うと思うんですけど。

それはさておき、update.rdf のテンプレートから任意の箇所を package.json の値で置換するような適当な javascript のスクリプトを書いた。javascript で書いたのは、jpm 自体が node.js で動かすスクリプトなのでそれに合わせて。

テンプレートとしてこういうものを用意して



					

						{{version}}

						

							

								{ec8030f7-c20a-464f-9b0e-13a3a9e97384}

								{{engines.firefox.minVersion}}

								{{engines.firefox.maxVersion}}

								https://example.org/example.xpi

package.json とテンプレートを両方読んで、プレースホルダ（{{〜}} の部分）を package.json の該当する値で埋める。package.json に値が存在しなければ、プレースホルダを含む要素自体を空に置き換えるようにした。

とりあえず webliopane fx40fixed を jpm でビルドするようにしてみた。

cfx to jpm

Posted on 2015/09/05 by akahuku

Firefox の拡張を Add on SDK ベースで作る際、cfx というツールを使うことになる。これは python で書かれたスクリプトだ。このツールが、拡張の基本的なディレクトリ構成を作成したり、テストしたり、xpi をビルドするといった開発のサイクルをサポートしてくれる。

しかし、Mozilla 的にはこの cfx は既に deprecated である。この後継は jpm というツールになっている。jpm とは Node.js で動かす javascript のスクリプトだ。たぶん JetPackManager ということなのだろう。じゃあ cfx は何の略なんだろ。CuddleFisheXtension？

ところでなぜ cfx がダメで、jpm に移行しなければならないかという理由はよく分からない。jpm だと npm ベースなので更新が簡単だとか、activate/deactivate する必要がないとか細々した理由はあるようだけど、しかしそれらは別に技術的に cfx で実現不可能なものとは思えない。技術的な理由じゃないとすると、Mozilla 内の政治的な理由なのかもしれない。

ともあれ基本的には両者とも jetpack の仕組みに準じたツールであるので、移行したとしてもそれほど開発サイクルに変更はない。両者の違いはせいぜい 1 ページに収まる程度のものだ。

しかしながらじゃあすぐ移行しようという気にはなぜかならない。どういうわけか jpm で作った拡張は AMO に載せてもらえないとかいう期間が長かったからかもしれない（長かったというか、今もそうなのだと思う）。この措置は本当に意味が分からないが、企業や団体や組織の行動のうち、外部から見て何の意味があるのかよく分からないものはやはり政治的な理由が根底にあったりするものなので、まあそういうことなんだろう。

ここまでつらつらと書いてきて、なんだか Mozilla という団体がまともなブラウザも作れず、シェアも右肩下がりなくせして、内部の政治闘争だけは一生懸命なろくでもない奴らに思えてきたが、たぶん、きっと、おそらく、そんなことはないのです。

a critical bug

Posted on 2015/08/25 by akahuku

wasavi をリリースしたばかりなのだが、Chrome 上のとある条件下でフリーズするという致命的なバグを直したので今月末辺りにまたリリースするかもしれない。フリーズと言ってもプロセッサのリソースを食いつぶすとかそういう類ではない。

これは 2 つのあまり関係なさそうな事柄が関係している。

まず、wasavi が保持するバッファは、各行の末尾に [cci]\n[/cci] の内容を持つテキストノードを保持している。これは、編集後に textarea に代入するために wasavi のバッファから単一の文字列を得る際、単にバッファの div 要素の textContent プロパティを参照するだけで済むようにするためだ。

次に、wasavi の input モードは div 要素の contentEditable 属性をオンにすることで実現している。

この 2 つの事柄が Chrome 上で絡みあうと不思議なことが起きる。IME を通した仮入力が最終的に空文字になり、かつカーソル行の div 要素の内容も空になった場合（たとえば空行で仮入力を開始したが、結局全部 backspace で消して仮入力を抜けた時…など）、前述の改行要素が Chrome によって勝手に削除されてしまうようなのだ。

wasavi のあらゆる編集機能はこの改行要素が存在することを前提としているので、ないとなるとあらゆるところでエラーが発生して満足に動かなくなる。

weblioPane fixed

Posted on 2015/08/23 by akahuku

Firefox の拡張に weblioPane というのがあって便利に使っていたのだが、最近になって（おそらく Firefox 40 のリリース以降）使用できなくなって困っていた。しかしなかなか新しいバージョンに更新される気配もないので勝手に直してみた。

https://github.com/akahuku/webliopane-fx40fixed

この拡張が参照している weblio の API についてのドキュメントが欲しいのだけど、見つからなかった。

WebExtensions…?

Posted on 2015/08/23 by akahuku

何やら物議をかもしている例の件。自作の拡張にはどういう影響があるのか考えてみる。

Firefox 版の wasavi や赤福プラスは Addon SDK ベースで作っているのだが、SDK の提供するモジュールをそのまま使っているのではない。抽象的なラッパーを挟んでいる。ラッパーが Chrome と Presto Opera と Firefox の差異を吸収して、アプリケーション内にはブラウザ固有のコードはほとんどない。

したがって、仮に WebExension ベースに移行するとしても、変更する必要があるのは Firefox 版のラッパーだけだ。そもそも WebExtensions が Chrome の拡張ベースだし、ラッパーも Chrome の拡張をベースにしたインターフェースにしてあるので、変更によりむしろコード量は少なくなるかもしれない。

一方で、SDK ベースのままにするという選択肢もある。ただ、SDK 自体は廃止は免れるということなのだけれど、それは [cci]require(‘chrome’)[/cci] していないものに限られるという。

ラッパーはもちろんこれを使っている。

XMLHttpRequest – SDK が提供するそれは upload プロパティをサポートしていない
FormData – SDK はこれを提供していない
Blob – SDK はこれを提供していない

つまるところ、なぜ [cci]require(‘chrome’)[/cci] を使っているのかといえば、SDK が提供する API が全般的に中途半端だからなのだ。それなのに Cu/Ci の使用を今さら咎められても困るのだが、この辺を何とかしないといけない。

width of character

Posted on 2015/08/21 by akahuku

wasavi のステータス行にはカーソル位置の桁・行位置を表示しているのだけど、その桁位置とはなんぞやというと、これはカーソル位置の内部的な行頭からのオフセットをそのまま指しているわけではない。つまり内部的な桁位置と表示上の桁位置は違う。

まず内部で charWidth という変数があり、これは大元の textarea のフォント関連のスタイリングに基づく、[cci]0[/cci] の文字幅だ。技術的には span 要素に [cci]0[/cci] を入れた際の offsetWidth の値だ。

それを踏まえて表示上の桁位置を算出するには、span 要素に行頭からカーソルの物理位置までの文字列を入れ、その offsetWidth を出し、charWidth で割る。表示しているフォントが固定幅であればこれで特に問題ない。

ところが困ったことに、固定幅フォントでさえ、文字列全体の offsetWidth が charWidth の整数倍にならないことが多々あるのであった。つまりこれは、cssom では offsetWidth の型は long だ。しかし実際には、それは小数で保持されているのが原因なんだと思う。そういうわけで正しい表示上の桁位置が得られない。

うーんどうしよう。

　＊　＊　＊

charWidth を算出する際に、100 個並べた [cci]0[/cci] の offsetWidth を 100 で割るようにした。つまり charWidth の精度を上げた。

wasavi/0.6.559 released

Posted on 2015/08/18 by akahuku

リリースした。

Chrome: https://chrome.google.com/webstore/detail/wasavi/dgogifpkoilgiofhhhodbodcfgomelhe

Opera: https://addons.opera.com/ja/extensions/details/wasavi/

Firefox 版は AMO へのアップを諦めた。その代わり github 上の開発版は署名済みになっているので Firefox41+ でもインストール時に警告されることはない: https://github.com/akahuku/wasavi/raw/master/dist/wasavi.xpi

　＊　＊　＊

wasavi が各ブラウザ上でアップグレードされた時、http://appsweets.net/wasavi/ を開くようになっている。ここで実質的なユーザー数をカウントすることができるので、そうなっている。先頭のテキスト “wasavi は Chrome、Opera、Firefox 用のエクステンションです。” の文句のそれぞれのブラウザ名にカーソルを合わせるとユーザー数を表示する。Opera に関しては Presto Opera と Blink Opera を分けてカウントする。

現在のところ、

Chrome: 1615
Presto Opera: 0
Blink Opera: 57
Firefox: 29

とのこと。Chrome では Web Store での表示が 3500 人とかそんな感じなので、まあ数日でその辺りに達するのだと思う。それにしても偏りがすごい。Opera に関してはブラウザ自体のシェア比からこんなもんなのかなという気はするが、Firefox 版ユーザーが妙に少ない。

Presto Opera でのユーザーが 0 というのはとてもいいことだ。これはもはや Presto Opera を考慮して開発する必要が全くないということだ。

Everything becomes Blink

Posted on 2015/08/17 by akahuku

Microsoft Edge が Chrome と Firefox の両方の拡張をサポートするかもしれない？　という噂について、そんなことができるのかなと訝しんだ記事を以前書いた。

実際のところは、こういうことのようだ。
http://rockridge.hatenablog.com/entry/2015/08/16/234729
https://wiki.mozilla.org/WebExtensions

なるほど。つまり Firefox 側で Blink の拡張のインターフェース互換のフレームワークを構築すると…。しかしそうすると Addon SDK の存在意義が根底から揺らいでしまう気が。それから、Mozilla 自身が XUL を捨てたがっているという話もある。しかし、Firefox 本体や既存の拡張のシステムって相当 XUL と絡み合っているわけで、そちらの存在意義も揺らいでくるような。

もしかしたら、レンダリングエンジンを servo にスイッチするタイミングでそれらも一気にグレートリセットされるのかもしれない。いやー Firefox 向けに拡張を書く人は大変だなー（他人事）。

signing akahukuplus

Posted on 2015/08/17 by akahuku

赤福プラスを Unlisted な拡張として AMO に提出し、署名を付けてもらった。

この際、機械的な validator が走り、ソースが検証される。この検証に引っかかった場合即時署名はされないが、AMO の中の人によるレビューを申請することはできる。一方、検証にすべて通れば即時署名が施される。いずれにしても署名された xpi は AMO の自分のアカウント内に保存されるのでそれをダウンロードして別の場所で公開すればいい。

赤福プラスがこの検証にすべて通ったわけだが、前に書いた通り検証を行う validator は本当にひどい出来なのだった。ひどい出来だし、意味のない設計方針に基づいて作られている。

たとえば validator は eval や、Function や、innerHTML や、insertAdjacentHTML や、引数がリテラルではない createElement があると即時署名を拒否する。そんなわけで
const FUN = ''; var fun = some_decrypt_function(FUN); var f = window[fun]('alert("wow!");');
のような感じでとにかくソースからイケないメソッドやプロパティ名を隠す。すると、validator はころっと騙される。

ああ、嫌なコードだなあ。嫌だし、自動検証に対してしか提出しない場合にのみ許される手法だ。これを preliminary review とかに提出したら必ず「この処理って何やってんの？」と聞かれるし、そして拒否されるだろう。

そもそもこの手のチェックに意味があるんだろうか。eval や innerHTML 自身が悪というわけではないのだ。使い方の問題なのだ。AMO の手で署名を付けてその拡張の生殺与奪権を握っているわけなのだから、イケない拡張がイケない使い方をしているなあと判明した時点でロックダウンすればいいんじゃなかろうか。

Opera から移行して以来、努めて愛そうとしているけれど、残念ながら Mozilla にもその製品にも、本当にがっかりさせられることが多い。

Firefox 42 #2

Posted on 2015/08/15 by akahuku

42.0a2, e10s off

新しいタブを開いてアドレスバーに適当なアドレスなり検索語句を打ち込んでエンターを押してもうんともすんとも言わない時がある
リンクをクリックしてもうんともすんとも言わない時がある

ここまではまあ Developer Edition だからそのうち直るのだと思う。

一方で keysnail の行く末が気になるのだけど:

KeySnail の sign レビュー結果来たけど reject だった。eval 使ってるから、という五年前に聞いたのと同じ理由。このままだと Firefox から KeySnail は ban されたことになって、開発者版以外ではインストールできなくなるな……。あーめんど。

— mooz (@stillpedant) August 12, 2015

eval を使ってるとだいたいレビュー結果は芳しくないものになるのはどこも同じようです。それから、innerHTML や insertAdjacentHTML を使ってもいい顔をされない。でも、プラグインのような機構を備えた拡張を作ろうとしたら、eval を使わざるを得ないわけで一律に reject されても困るよねえ。その場合、「これこれこういうわけで eval を使わざるを得ないので許してくだち！」というメッセージと共に人の手によるレビューを申請することになるんだと思うけど、その辺のフローがよく分からないというかさっぱり分からない。どうも AMO のやりたいことがよく分からない。AMO の言葉は誰にも分かんない。AMO の静かな願いも分かんない。

というか、bugzilla で validator 関連を見てみると現在進行形で署名フローの議論してたりするので、何がどうなるのが正しいのかは AMO の中の人にもまだ分からないのかもしれない。

……なんか、仕事が雑だなあ。