Home > Latest topics

Latest topics 近況報告

たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。

萌えるふぉくす子さんだば子本制作プロジェクトの動向はもえじら組ブログで。

宣伝1。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能! シス管系女子って何!? - 「シス管系女子」特設サイト

宣伝2。Firefox Hacks Rebooted発売中。本書の1/3を使って、再起動不要なアドオンの作り方のテクニックや非同期処理の効率のいい書き方などを解説しています。既刊のFirefox 3 Hacks拡張機能開発チュートリアルと併せてどうぞ。

Firefox Hacks Rebooted ―Mozillaテクノロジ徹底活用テクニック
浅井 智也 池田 譲治 小山田 昌史 五味渕 大賀 下田 洋志 寺田 真 松澤 太郎
オライリージャパン

Page 1/240: 1 2 3 4 5 6 7 8 9 »

Firefox 57とかWebExtensions移行後のツリー型タブとかがクソとかゴミとか言われているのを見て思う事 - Dec 07, 2017

Firefox 57がリリースされた前後から、アドオンが使えなくなってクソだとか改悪だとかの感想を目にする機会があって、気分が滅入る事が度々ありました。

自分自身は、これは必要な事だったと思っていますし、絶望は1年ほど前に嫌というほどし尽くして、今はもう「で、どうやって乗り越えるか」というフェーズに気持ちがすっかり移ってしまっているため、それらの後ろ向きなコメントには正直な所「えっまだそんなこと言ってるの……」という感想を抱いています。そんな後ろ向きな事を言っていないでもっと生産的な事をしましょうよ、と思わずにはおれません。

しかし同時に、自分自身も他の分野ではエンドユーザーとして後ろ向きな選択をしている場面は多々あり、同意する部分が無いとも言えません。というか今絶望している人達と同じような事をつい1年から2年ほど前には自分も言っていた訳で、それを思い起こす度に、し尽くして乗り越えたはずの絶望が何度も蘇ってきて、「何故自分がこんな理不尽な思いをせねばならん(かった)のだ?」と憤りの感情が頭をもたげてくるのは否めません。

そういう自分の中での混乱を鎮めるために、エンプティ・チェアを2~3個置いて自分の思う所と結論に至るまでの経緯を各立場から辿り直し、考えを整理してみる事にしました。

続きを表示する ...

ツリー型タブのWebExtensionsへの移行のおはなし - Oct 03, 2017

Here is the English version of this article. このエントリはQiitaとのクロスポストです

2017年の8月下旬に思い立って、ツリー型タブのWebExtensions版を作り始め、去る9月26日にバージョン2.0としてリリースしました。
(ツリー型タブのサイドバーパネルを表示した状態のスクリーンショット)

重い腰を上げて取り組む気になれたのは、必須と目していたAPIが一通り実装されてきて、Firefox 57でようやく技術的に作れる目処が立ってきたからでした。 関係者の皆さんの尽力に改めて感謝の意を表明します。

やっている事自体はそう難しい話ではなく、技術的に目新しいトピックは無いのですが、主に歴史的資料としてレガシーなアドオンの移行の一事例の記録を残しておこうと思います。

続きを表示する ...

WebExtensions Migration Story of Tree Style Tab - Oct 03, 2017

このエントリの日本語版はこちらから読めます。

I started to develop WebExtensions-based version of the Tree Style Tab at late August 2017, and released as the version 2.0 at 26th November.
(A screenshot of Firefox Nightly 58 with Tree Style Tab's sidebar panel)

The largest reason why I did it is: many numbers of new WebExteisons APIs I required are landed to Firefox 57. Thank you developers for their great effort.

There is no technical novelty topics, but I wrote this as a historical document: a migration story of a very legacy addon.

続きを表示する ...

Tree structure and tab icons are always lost after restart / 再起動すると必ずツリー構造やタブのアイコンが失われる - Mar 12, 2017

Q

When I start Firefox, tree of tabs and favicons are always lost. Even if I reorganize tree of tabs again, they are flattened after every restart.

Firefoxを起動すると、必ずタブのツリーとタブのアイコンが失われます。ツリーを作り直しても、再起動する度にツリーが失われてすべてのタブが同階層に表示されてしまいます。

A

Please press Ctrl(Command)-Shift-J to open the "Browser Console" - one of developer tools of Firefox. Is any error message like this reported?: NS_ERROR_ILLEGAL_VALUE: Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE)
[nsISerializationHelper.deserializeObject] Utils.jsm:94

Screenshot: (The console with the error message.)

Then, the problem may be caused by invalid information stored in your session data. Try following steps to cleanup your session data:

  1. Close the browser console.
  2. Input "about:config" into the location bar and hit the Enter key.
  3. Skip the confirmation message by clicking the button in the page.
  4. Input "devtools.chrome.enabled" into the "Search:" field.
  5. Then you'll see just one entry. Double click it to turn the value to "true", if it is "false".
  6. Open the browser console again by Ctrl(Command)-Shift-J. Then you'll see an input field at the bottom of the console.
  7. Copy this script and paste it into the bottom field of the console:
    var TabStateCache = Components.utils.import('resource:///modules/sessionstore/SessionStore.jsm',{}).TabStateCache;
    Array.forEach(
      gBrowser.browsers,
      (browser)=>
        TabStateCache.update(browser, {
          iconLoadingPrincipal : null
        })
    );
    "OK"
  8. And hit the Enter key in the field. Then you'll see a new message "OK" in the console.
  9. Restart Firefox.

Ctrl(Command)-Shit-Jを押して、Firefoxの開発ツールの1つである「ブラウザコンソール」を開いて下さい。以下のようなエラーメッセージが出力されていませんか?:NS_ERROR_ILLEGAL_VALUE: Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE)
[nsISerializationHelper.deserializeObject] Utils.jsm:94

スクリーンショット:(コンソールに上記のエラーが出ている様子)

もしこのエラーが出ているなら、問題はセッション情報の中に混入してしまった不正なデータが原因で引き起こされている可能性があります。以下の手順でセッション情報をクリーンアップしてみて下さい。

  1. ブラウザコンソールを閉じる。
  2. ロケーションバーに「about:config」と入力し、Enterキーを押す。
  3. 確認のメッセージが表示されるので、ページ内に表示されるボタンをクリックして先に進む。
  4. 「検索:」欄に「devtools.chrome.enabled」と入力する。
  5. 項目が1つだけ見つかるはずなので、値が「false」になっている場合は項目をダブルクリックして値を「true」に変更する。
  6. Ctrl(Command)-Shit-Jを押してブラウザコンソールを開き直す。すると、コンソール株に入力欄が表示されるようになっている。
  7. 以下のスクリプトをコピーして、その入力欄に貼り付ける。
    var TabStateCache = Components.utils.import('resource:///modules/sessionstore/SessionStore.jsm',{}).TabStateCache;
    Array.forEach(
      gBrowser.browsers,
      (browser)=>
        TabStateCache.update(browser, {
          iconLoadingPrincipal : null
        })
    );
    "OK"
  8. そのまま入力欄でEnterキーを押す。コンソールに「OK」というメッセージが出力される。
  9. Firefoxを再起動する。

Mozilla All Hands in London 2016 イベントレポート:技術編 - Jun 20, 2016

現地時刻で2016年6月13日から17日にかけて行われたMozilla All Hands in London、通称MozLondonに参加してきました。 (オープニングセッションの開始前の様子)

最近はこの種のイベントに参加する機会が減ってしまい、「えっ、Mozilla関係で何かやってる人だったの?」みたいになってそうな気がするので、ちょっと記録を残しておこうと思います。

Mozillaの活動に関わっている人はMozillaの雇用スタッフもそうでない人も世界中に散らばっていてコミュニケーションコストが高いので、半年ごとにAll Handsと称して社員と外部の開発者を一箇所に集めて色々話し合っています。 ただ、社員は全社員が招集されるのに対して、自分のような外部の人は活動のアクティブさの度合いなどに応じてボランティア枠で招待される形です。 自分は連絡を頂いた時点ではBugzilla上でそんなにアクティブではなかったのですが、今回はアドオン作者へのヒアリングということでアドオンチームの方から推薦を頂いたようです。 「ボランティア」とはいっても招待なので、交通費・食費・宿泊費は全部Mozilla持ちでした。

続きを表示する ...

Casual cooperation of addons - Aug 23, 2015

This is a reply to the blog entry: Firefox Add-on Changes | Bill McCloskey's Blog

Hello, I'm the author of the listed addon Tree Style Tab.

You mean that we can rebuild Tree Style Tab with the sidebar API. However, I think that you don't find out what is the essence of TST.

I believe that TST's unique value is a natural compatibility for other tab-related addons, and sidebar API based TST loses the value.

If I rebuild TST using such a sidebar API, it can probably provide tree-like GUI in a sandboxed frame, working instead of Firefox's native tabs. But, probably other addons can't cooperate with it, because most addons' authors think about only their addons and Firefox's native tabs. Even if new TST became available based on the sidebar API which can't cooperate with other addons, it's useless. Moreover, then I'll receive more and more requests for the sidebared TST, like: Please add the feature provided by another something major tab-related addon, like "copy tab title"!

On the other hand, current TST changes just the appearance of Firefox's native tabs, so other tab related addons also work with it seamlessly even if they don't know TST. If an addon provide a new menuitem "copy tab title" in the context menu on tabs, it is also available even if TST is installed, because TST's "tree item" is truly Firefox's native tab. I mean that this is TST's natural compatibility for other addons. I think this value is never available with isolated addons based on sandboxed sidebar. Like the UNIX strategy, one addon should not include too much features, because one author only can do a few work. Instead, one addon should cooperate with others casually. I think this is why Firefox is loved by many power users.

The reason, why TST seems unstable and fragile, is that there are too less entry points for addons which work on Firefox's low level layer. Because we never can insert our custom operations to Firefox's features (like dragging of tabs, bookmarking of webpages, etc.), we have to replace it entirely or rewrite internal functions. If more stable entry points become available, TST will be more safe, stable, and compatible with other addons.

Anyway, my conclusion is: I believe that low-level extensibility for addons should be kept, even if new extension APIs become landed. Extensibility based only on isolated APIs will kill addons' casual cooperation.

Thanks.

One addition.

If addons based on new APIs can cooperate with others casually around Firefox's native features like current TST, I passively agree to the decision of killing low level extensibility for legacy addons. Basically Firefox should be more safe and stable for non-power users - I think so. If new APIs truly can build addons which cooperate with others seamlessly with enough rich entry points, then I'll have no reason to negate migration from legacy way to the new way - except that it is a hard work.

Firefoxアドオンのe10s(マルチプロセス)対応の方針について得られた知見 - Nov 13, 2014

Firefoxのマルチプロセス設計への移行がいよいよ目前に迫っている。

Firefoxにおけるマルチプロセス化のための仕組みそのものはElectrolysis、略してe10sと呼ばれており、Firefox 4の頃から既に入っていて、Firefox Hacks Rebootedでも詳しく解説してたんだけど、ブラウザのUIを動かすプロセスとコンテンツ領域のプロセスを分けるというのはFirefoxではかなりの大ごとだった。一時は「こんなん無理!」っつって計画が凍結されてたほどだったと記憶してる。

e10s移行が困難だった理由は、多分、Firefoxというアプリケーションそのものの設計にあったのだと思う。FirefoxというWebブラウザは、「GeckoというHTML・XMLレンダリングエンジンの上で動作するJavaScript製のローカルWebアプリケーション」といった感じの設計になっている。なのでコンテンツ領域内の操作のためのコードとUI部分の操作のためのコードが非常に似通っていて、シームレスに連携しやすかった、否、「連携しやすすぎた」と言える。あまりにシームレスに連携できたせいで、ブラウザのUIに関わるコードとコンテンツ領域内の操作に関わるコードが渾然一体の密結合になってしまい、それが「UI部分とコンテンツ領域内との間はテキストメッセージだけを非同期に通信しあう」というe10sベースの設計への移行を阻んでいた、という事なのではないか……と僕は思っている。

どういう理由があったのかは知らないけど、最近のバージョンのFirefoxではe10sベースの設計への本格的な以降のための準備が着々と進められている。上記のような密結合だった部分が「UI領域専用」「コンテンツ領域専用」「両方で共通」といった感じに分離されてきているし、同期処理前提だった部分が非同期処理前提に改められている。 セッション保存の仕組み(ページ内のテキストボックスへの入力内容を保存する所とか)、リンクのクリック操作のハンドリング、その他多数の部分が大幅に書き直されている。アドオンから見た時のAPI的な互換性は可能な限り残すようにしてあるようで、その努力の様子が非常に興味深い。

で、アドオン側での対応をどう進めるかなんだけど、実際にいくつかのアドオンをe10s対応に改修してみて、アドオンの性質によって典型的なパターンがあるようだという事が分かった。

  1. UI領域内だけで処理が完結するアドオンの場合: 特に何もしなくて良い。browsercontentWindowcontentDocumentに一切触れず、コンテンツ領域内からBubblingしてくるイベントも捕捉しないタイプのアドオンは、何も考えなくてもそのままe10sで動く。
  2. UI領域内で発生するイベントをトリガーとして、コンテンツ領域内で何らかの処理を行う(処理の結果は利用しない)アドオンの場合: アドオンの実装を、「UI領域からコンテンツ領域へ、処理スタートの指示のメッセージを送る」「コンテンツ領域で指示のメッセージを受け取って、実際の処理を行う」という2段階に分け、実装の一部をコンテンツ領域側に読み込ませるコードの中に移動する必要がある。 マルチプルタブハンドラの場合、「選択したタブをファイルとして保存する」機能について、ページをファイルとして保存する処理をコンテンツ領域側に移動し、UI領域からのメッセージをトリガーとして実行するためのコードを追加した。
  3. コンテンツ領域内で発生するイベントをトリガーとして、コンテンツ領域内で何らかの処理を行うアドオンの場合: アドオンの実装を、コンテンツ領域側に読み込ませるコードの中に移動して、そこで処理を完結させるようにする必要がある。
  4. コンテンツ領域内で発生するイベントをトリガーとして、UI領域側で何らかの処理を行うアドオンの場合: コンテンツ領域側にコードを読み込ませて、コンテンツ領域内で発生したイベントをUI領域に通知してやる必要がある。 ツリー型タブの場合、タブバーを自動で隠す機能において、コンテンツ領域上でのマウスの移動を検知するために、マウスのボタン操作や移動で発生したイベントをUI領域に通知するコードを追加した。 生のイベントオブジェクトやDOMノードは渡せなくなるので、文字列として渡せる情報だけでもきちんと動くようにする工夫が要る。
  5. UI領域内で発生するイベントをトリガーとして、コンテンツ領域内で何か処理を行い、その結果を受けてさらにUI領域側で何らかの処理を行うアドオンの場合: これが一番厄介なパターン。 例えば今までだったらWebページ中のリンクを収集する操作は同期処理で var linkURIs = Array.map(gBrowser.contentDocument.links, function(aLink) { return aLink.href; }); と書けたけれども、こういう事ができなくなる。 UI領域とコンテンツ領域の境界をまたぐ時に非同期処理を挟まないといけないので、処理を「UI領域からコンテンツ領域へ、リンクを収集する指示のメッセージを送る」「コンテンツ領域で指示のメッセージを受け取って、リンクを収集し、UI領域へ結果を報告するメッセージを送る」「UI領域で報告のメッセージを受け取って、次の処理を行う」という3つの段階に分けなくてはならない。 マルチプルタブハンドラの場合、「選択したタブの情報をクリップボードにコピーする」という機能のために、タブ(で開いているページ)の情報からクリップボードにコピーするための文字列を得る処理をコンテンツ領域側に移動した上で、UI領域からコンテンツ領域へ・コンテンツ領域からUI領域への橋渡しを行うためのコードを追加し、前後の処理をPromiseで繋ぐようにした。

上記の5パターンの最初の方の物ほど実装が容易で、後の方の物ほど実装が面倒になる(その上、メッセージの往復を待たないといけないのでオーバーヘッドも大きくなる)。 特に深い意味もなく後の方のパターンで実装していた機能は、どうにかして前の方のパターンで実装できないか検討した方がいい(Firefox本体の設計変更も、おそらくそういう風に進められたのではないかと思う)。 実際に、情報化タブではWebページのサムネイル画像を取得する処理について、元々はUI領域で「サムネイルが必要だ」となったタイミングでその都度同期処理していたのだけれども、まずサムネイル取得の処理はコンテンツ領域に移し、処理が走るタイミングについて、コンテンツ領域側で発生したイベントをトリガーとしてサムネイル画像をUI領域側にpushで送りつけるように改めた。 これは上のリストで言うと、5番目のパターンから4番目のパターンに設計変更した、ということになる。

それでもどうしても5番目のパターンで実装しないといけないケースというのはあって、前後の処理とどうやって繋ぐか(同期処理だった物をどう非同期化するか)というのが問題になる。 自分の場合は、こういう時はPromiseを使うのがいいと思ってる(以前ならJSDeferredを使ってたんだけど、Mozilla Add-onsのレビューが通らないため、最近になってPromise.jsmのES6 Promise互換APIを使うようになった)。 ツリー型タブでも、コンテンツ領域内にプラグイン(Flashなど)で描画されている領域があるかどうかを調べるための処理で、このパターンが残っている。 Promiseを使うコードはUI領域側のブリッジにまとめてあり、こんな感じになってる。

sendAsyncCommand : function CB_sendAsyncCommand(aCommandType, aCommandParams)
{
    var manager = this.mTab.linkedBrowser.messageManager;
    manager.sendAsyncMessage(this.MESSAGE_TYPE, {
        command : aCommandType,
        params  : aCommandParams || {}
    });
},
checkPluginAreaExistence : function CB_checkPluginAreaExistence()
{
    return new Promise((function(aResolve, aReject) {
        var id = Date.now() + '-' + Math.floor(Math.random() * 65000);
        this.sendAsyncCommand(this.COMMAND_REQUEST_PLUGIN_AREA_EXISTENCE, {
            id : id
        });
        return this.checkPluginAreaExistenceResolvers[id] = aResolve;
    }).bind(this));
},
handleMessage : function CB_handleMessage(aMessage)
{
    // dump(JSON.stringify(aMessage.json)+'\n');
    switch (aMessage.json.command)
    {
        ...
        case this.COMMAND_REPORT_PLUGIN_AREA_EXISTENCE:
            var id = aMessage.json.id;
            if (id in this.checkPluginAreaExistenceResolvers) {
                let resolver = this.checkPluginAreaExistenceResolvers[id];
                delete this.checkPluginAreaExistenceResolvers[id];
                resolver(aMessage.json.existence);
            }
            return;
    }
},
  • checkPluginAreaExistenceメソッドは、その実行を示すユニークなidを伴ってコンテンツ領域に指示のメッセージを送ると同時に、新たに生成したPromiseのリゾルバ関数を、idと対応付けて保持する。メソッドの戻り値はPromiseとする。
  • コンテンツ領域側では、指示のメッセージを受け取って処理を行い、結果のメッセージをid付きでUI領域に送り返す。
  • 送り返されてきたメッセージをUI領域側で捕捉したら、idに基づいて、保持していたリゾルバ関数の中から対応する物を見付け、送り返されてきたメッセージに含まれていた情報を渡す形で実行する。

という風にする事で、checkPluginAreaExistenceメソッドをthenableなメソッドとして他の処理の中に無理なく組み込める(次のコールバックには、コンテンツ領域側での処理で得られた結果が渡る)ようになってる。 UI領域→コンテンツ領域→UI領域 と境界を2回以上またぐ処理を実装する時は、多少の差異はあれどだいたいこんな感じになるんじゃないだろうか。

必要かどうかで言うと、このパターンでPromiseは必須ではなくて、Promiseのリゾルバ関数を保持・実行する代わりに、単にcheckPluginAreaExistenceメソッドでコールバック関数を受け取って、それを保持・実行するようにしてもいいんだけど。 非同期の処理同士を何度も書き連ねる時のコールバック地獄は見たくない(今はそういう連携をする必要がないとしても、今後いつ必要になるとも限らない)ので、僕は自分で書く非同期処理は、インターフェースとしては基本的にPromiseを使う方向で統一するように考えてる。

Tree Style Tab prevents Firefox from hiding title bar / ツリー型タブをインストールするとタイトルバーを非表示にできなくなる? - May 06, 2014

Q

On Firefox 29 and later, I cannot hide the title bar anymore if Tree Style Tab addon is installed. Is this a bug? How can I hide the title bar?

Firefox 29以降のバージョンでTree Style Tabを使うとタイトルバーを非表示にできません。これはバグではないのですか? どうすればタイトルバーを非表示にできますか?

A

Install Tree Style Tab 0.14.2014050601 (or later) and another addon Tabs on Bottom 0.5 (or later) together. If both addons are installed, the title bar becomes hidden.

This is not a bug but a designed behavior of TST, because that affects ability hiding the title bar: "is the tab bar on top of the window or not?" Old Firefox (Firefox 28 or older) had the "Tabs on Bottom" mode, and the navigation toolbar worked like the title bar - draggable to move the window itself. Because TST moves the tab bar away from the top of the window, TST always chose the mode automatically, for the usability. However, the "Tabs on Bottom" mode has been removed on Firefox 29. If TST moves the tab bar away, you cannot move the window by dragging of the navigation toolbar anymore. To avoid such an inconvenience, now TST forces to Firefox to show its title bar.

On the other hand, Tabs on Bottom addon re-introduce the "tabs on bottom" mode to Firefox 29 and later. Because it is not a "tree" feature, and there may be some people who just want to use "tabs on bottom" mode without "tree" features, I decided to keep it as an independent addon. See also another FAQ.

ツリー型タブ 0.14.2014050601(またはそれ以降)と、別のアドオンであるTabs on Bottom 0.5(またはそれ以降)をインストールしてください。両方のアドオンが同時に有効になっていれば、タブバーが非表示になります。

これはバグではなくツリー型タブの設計上意図された挙動です。何故なら、タイトルバーを隠せるかどうかは、タブバーがウィンドウの最上部にあるかどうかに依存するからです。Firefox 28またはそれ以前の古いFirefoxには「タブを下部に表示」というモードがあり、そのモードではナビゲーションツールバーがタイトルバーのように働くようになっていました(例えば、ドラッグするとウィンドウ自体を移動できるなど)。ツリー型タブはタブバーをウィンドウの最上部から取り除いてしまうので、利便性のために、自動的に「タブを下部に表示」モードを有効にするようになっていました。しかしながら、Firefox 29ではそのモード自体が削除されてしまったため、単にタブバーをウィンドウの最上部から取り除いてしまうと、ナビゲーションツールバーのドラッグ操作ではウィンドウを移動できなくなってしまいました。このような不便を回避するために、現在、TSTはFirefoxに対して常にタイトルバーを表示するように強制する設計となっています。

他方で、Tabs on BottomアドオンはFirefox 29以降のバージョンに対し再び「タブを下部に表示」機能を提供します。その機能は「ツリー」と全く関係がなく、また、単にその機能だけを使いたい(ツリー機能は必要ない)という人がいるであろうという事から、その機能はTSTに統合せずに別のアドオンとしてリリースしています。別のFAQも参照してください。

Double-click on the empty area of the tab bar doesn't open a new tab anymore! / タブバーの余白をダブルクリックしても新しいタブが開かれなくなった - May 06, 2014

Q

On Firefox 29 (and later), I cannot open a new tab by double-click on the empty area of the tab bar, with Tree Style Tab. Is this a bug?

ツリー型タブを使っているとき、Firefox 29以降のバージョンではタブバー上の余白をダブルクリックしても新しいタブを開けません。これはバグではないですか?

A

No, it's not a bug of Tree Style Tab. In old Firefox (Firefox 28 or older), double-click on the empty area of the tab bar opened a new tab actually, but it was a feature of Firefox itself. The action was available only when you choose "Tabs on Bottom" mode, and Tree Style Tab always chose the mode automatically. In the "Tabs on Top" mode, your actions on the empty area of the tab bar worked as on the title bar - for example, it maximized the window itself on Windows. Because the "Tabs on Bottom" mode has been removed on Firefox 29, now double-click on the empty area always works as on the title bar.

Because it is not a feature related to "tree of tabs", I won't include it to TST in the future. Certainly TST already has some features not related to "tree of tabs", but there is a criterion for those exceptions: is the feature provided by Firefox itself, and does TST break it? Then, now Firefox 29 itself doesn't open a new tab by double-click on the tab bar, so TST also never do it. Sorry, but I have to draw a line somewhere.

Instead, you should use another addon who provides the feature: double-click on the empty area on the tab bar to open a new tab, for Firefox 29 and later. For example, my another addon Tabs on Bottom.

いいえ、それはツリー型タブのバグではありません。古いバージョン(Firefox 28以前)のFirefoxでは確かにタブバーの余白をダブルクリックすると新しいタブが開かれましたが、それは「タブを下部に表示」モードの時だけ使える、Firefox自体の機能です。ツリー型タブは単に、「タブを下部に表示」モードを常時有効にしていただけです。元々、「タブを上部に表示」モードでは、タブバーの余白での操作はタイトルバー上での操作と同等に扱われていました(例えば、ダブルクリックでウィンドウを最大化するなど)。「タブを下部に表示」モードがFirefox 29で削除されてしまったため、タブバーの余白でのダブルクリックは常にタイトルバー上での操作と見なされます。

この機能は「タブのツリー」というコンセプトに直接は関係しないため、今後もツリー型タブにこの機能を含めるつもりはありません。ツリー型タブはFirefox本体に元々備わっている機能をなるべく阻害しないことを目標にしており、そのために実際にツリーと関係無い機能を入れている部分もありますが、この機能については現在はFirefox本体にそもそも含まれていないので、そのような特別な対応をする予定も残念ですがありません。

なので、どうしても必要な場合は、代わりに、タブバーの余白のダブルクリックで新しいタブを開く機能を提供している別のアドオン(例えばTabs on Bottom)を併用してください。

4年越しで溜飲を下げた話 - May 02, 2014

Mozilla Corporationの人から、「なんでツリー型タブはFull Reviewを受けてないんだい? about:addonsからの検索にヒットしないから、ユーザがインストールするのに面倒だよ。You申請しちゃいなよ!(意訳)」的なメールを頂いた。ありがたいことだ。

Mozillaのアドオンポータルサイトである所のMozilla Add-onsでは、アドオンを登録するにあたってPreliminary Review(事前審査)とFull Review(完全審査)という2段階の審査がある。登録したアドオンはまずPreliminary Reviewでセキュリティ面などの大雑把な審査を必ず受けて、通過できなければそのアドオンはAMOへの掲載すらかなわない。ここで問題なしとなれば晴れて「実験的アドオン」としてサイトに掲載されるようになるけど、Firefoxのアドオンマネージャからの検索にはヒットせず、おすすめアドオンとしてもノミネートされないので、これではまだ単に「載っただけ」。そこで一定の支持を得たら、次の段階としてFull Reviewを申請して品質面その他を審査してもらえる。Full Reviewを無事通過すれば、Firefoxのアドオンマネージャからの検索にヒットするようになったり、おすすめとして紹介して貰えたりするようになる。定番アドオンと言われるような物は、代替はこのFull Reviewを通過した状態になってる。

前から見てる人は把握してるかもしれないけど、僕が作ってるアドオンのうちいくつかは、Preliminary Reviewのみ通過していて実験的アドオンのままになっている。新しく作って登録した物は当然なんだけど、それだけでなく、過去にはFull Reviewを通っていた物が、ある時を境に審査にパスしなくなってそれっきりになっている物もある。ツリー型タブもその1つだ。

何故かというと、簡単に言えば、最初のFull Reviewの頃には審査が甘かったから通過できていたのが、その後の審査基準見直しで通らなくなったということ。ただ、僕としてはこの時の裁定にはあまり納得がいってなくて、evalが危険でそれ以外の方法が安全だと思ってる人へ英訳)というエントリでタラタラ不満をぶちまけたりもしてた。

そういう経緯があったから、大人げないオッサンとしては「いやーFull Reviewしたいのは山々なんですけどねーeval()使ってるから駄目っておたくんとこの人達が言うもんですからねー」と嫌味全開で返したくもなったんだけど、そこは我慢して、審査基準に合わないと言われたからFull Reviewしてないんですよ、審査基準が変わったなら再申請するのはやぶさかでないけどそうでないなら多分通過しないと思いますよ、でもまあ確かにeval()使ってるとレビューしにくいだろうししょうがないっすね、と、そんな感じで返信するに留め……られるほどにはやっぱり大人になりきれておらず、嫌みったらしく上記のエントリ(英語の方)のURIを貼り付けてメール送信してしまいました。ああ、なんとも底の浅い人間である事よ……

でもまあ、その時のレビュワーの人とは無関係であるにせよ、公式サイドの人から「Full Reviewに値する」という評価を貰えた事には「やってやったぜ」という胸のすく思いで、4年越しで溜飲を下げたのでした。

Page 1/240: 1 2 3 4 5 6 7 8 9 »

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のつぶやき

オススメ

Mozilla Firefox ブラウザ無料ダウンロード