Home > Latest topics

Latest topics 近況報告



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

Page 9/243: « 5 6 7 8 9 10 11 12 13 »

新しいタブを開く時にタブバーの下の端以外の位置に開きたい(How to open new tab not on the bottom of the tab bar?) - Jun 15, 2010


If I open a new tab they always open on bottom. I have alway many tabs open and I need to scroll always down to see new tab. That's for me not very comfortable. Is possible that new tab open on top?



Now TST doesn't provide such a feature to control new tab position. I think TST should not implement features not related to "tree of tabs", but it should be done by another addon designed for the purpose, for example, Tab Control does it.

現在、ツリー型タブはそのための機能を提供していません。私は、「タブのツリー」とは関係ない機能はツリー型タブには含めず、そういう目的のために開発された他のアドオンで解決するべきと考えています。例えばTab Controlがそういう機能を持っています。

「xpcnativewrappers=no」の廃止 - Jun 09, 2010



XPCNativeWrapper越しでなく生のJavaScriptのオブジェクトにアクセスする方法としては、xpcnativewrappers=no以外にもう1つ、任意のオブジェクトの.wrappedJSObjectというプロパティを見る方法がある。今回投入されたパッチではこの機能までは削除されていないように見えるので、今までxpcnativewrappers=noを使っていた人は、Webページ内のJavaScriptのオブジェクトにアクセスしてた箇所では.wrappedJSObjectを書き加えるようにすれば一応は動くようになるんじゃないかと思う。セキュリティ的には、そもそもラップされてない生のJSObjectに触らなきゃいけないという設計自体を変えた方がいいんだけど。だいたい、XPCNativeWrapperが入ったのってFirefox 1.5がリリースされるよりも前の話だよ。今なおXPCNativeWrapperの存在を前提にしてないコードって、どんだけ古いのさ?

タブのコンテキストメニューが正常に機能しなくなった? (The context menu on tabs doesn't appear anymore?) - May 15, 2010


I'm running your Tree Style Tab extension on the last Firefox, 3.4a. I installed the Menu Editor extension and the context menu on the tabs stopped to appear. Until Firefox 3.6.3 they were working together nicely.

私はツリー型タブを最新版のFirefox(3.7a4)で使っています。Menu Editorをインストールしていると、タブのコンテキストメニューが出なくなってしまいました。Firefox 3.6では両者は正常に機能していたのですが……


Codes of the context menu on tabs are totally restructured on the Firefox 3.7a4. See: Bug 554991 - allow tab context menu to be modified by normal XUL overlays. So, addons including codes about context menu on tabs must be updated.

TST newer than 0.10.2010040201 has been updated for the change, but I couldn't find out a version updated for Firefox 3.7a4 from all versions of the Menu Editor.

If the problem still appear with a new version of the Menu Editor updated for Minefield 3.7a4 and later, please tell me again.

タブのコンテキストメニューの実装は、Firefox 3.7a4で大きく変わりました。Bug 554991 - allow tab context menu to be modified by normal XUL overlays を参照してください。このため、タブのコンテキストメニューを触るアドオンは更新されなくてはなりません。

ツリー型タブのバージョン0.10.2010040201以降はこの変更に対応済みですが、私はMenu Editorの公開済みのバージョン一覧からMinefield 3.7a4に対応したバージョンを見つけることはできませんでした。.

もしMenu EditorのFirefox 3.7a4対応版がリリースされた後でもまだ問題が再現するようであれば、改めてご連絡ください。

一言でいえば、「Firefox 3.7a4の新仕様にきちんと対応してないアドオンと組み合わせて何が起こっても僕の責任じゃないですよ」ってことで。

「タブを閉じる」ボタンの働きの選択肢として「親のタブを閉じずに子孫のタブだけを閉じる」が欲しい(A new option to close only child tabs by "Close Tab" button) - May 14, 2010


My small suggestion is to be able to configure the close button for a parent tab to just close its children. After it is child-less, the second click would close the tab itself. My feeling is that this would make for more fluid experience when you open up a flurry of child tabs to follow up on details and want to continue with the main "story" or "task" on the original parent tab. As it is now you have to right click and select close children, which I find a bit clunky.



Sorry, I have no plan to implement the feature to Tree Style Tab. There are two reasons: 1) overriding of the behavior of "close tab" button is hard to implement. And, 2) I think it is not an instinctive behavior.

1) Now there are some options for "close tab" of parent tabs, but all options are designed to work just after the parent tab was correctly closed. Because, TST listens "TabClose" event which is fired after the tab is completely closed by Firefox itself. We cannot cancel the closing of the parent tab from "TabClose" event.

2) If "close tab" button closes the tab and its collapsed children, I think it is instinctive, because it is same to the default behavior of the "close tab" button, except there are collapsed (hidden) children. And if the button closes only the parent tab (keeping children open) it is also same to the Firefox default. "When the close button is clicked, only children are closed and the tab itself is still there" -- the scenario is odd a little for me.

However, you can implement the feature with other scriptable addons (FireGestures, userChrome.js, etc.) with following codes:

var parentTab = gBrowser.selectedTab;
if (TreeStyleTab.hasChildTabs(parentTab)
  // The second argument "true" means "close only children".
  TreeStyleTabService.removeTabSubtree(parentTab, true);

すみませんが、その機能をツリー型タブ本体に取り込むつもりはありません。それには2つの理由があります。1) 「タブを閉じる」ボタンの挙動を乗っ取るのは実装が大変ですし、2) その挙動は直感的とは私には思えません。

1) 現在、親のタブの「タブを閉じる」ボタンをクリックした場合の挙動にはいくつかの選択肢を設けてありますが、そのいずれも、親のタブ自体が閉じられた後に働くことを前提にしています。これはツリー型タブが、タブが完全に閉じられた後でFirefox自身によって発行される「TabClose」イベントを監視することによってこの機能を実現しているためです。「TabClose」イベントからは、タブを閉じる操作自体をキャンセルする事はできません。

2) 「タブを閉じる」ボタンによってそのタブ自身とすべての折り畳まれた子タブが閉じられる場合、そこに折り畳まれた(見えない)子タブがあるという点を除けばFirefoxの標準的な挙動と同じなので、これは私には直感的な挙動に感じられます。また、もしそのタブだけが閉じられて子タブが残るのであれば、これはFirefoxの標準的な挙動と全く同じです。しかしながら、「タブを閉じるボタンをクリックしたら、子タブだけが閉じられて、そのタブは已然として開かれたままとなる」――この挙動は、私には違和感があります。


ロケーションバーからAlt-Enterでタブを開けない?(ALT-Enter in the location bar doesn't open new tab?) - May 14, 2010


In plain Firefox, ALT-Enter in the address bar opens a new tab. This doesn't happen with Tree Style Tab activated.



I think it is a designed behavior of TST. TST includes a feature to open new tabs from the location bar without the ALT key, and the effect of the ALT key is inverted by the feature (Enter => new tab, ALT-Enter => current tab).

To get back Firefox's default behavior (Enter => current tab, ALT-Enter => new tab), go to TST's configuration dialog => "New Tabs" => "Location Bar".

If you don't want any loading into the current tab from the location bar (Enter => new tab, ALT-Enter => new tab), then, go to about:config and turn "extensions.treestyletab.urlbar.invertDefaultBehavior" to "false".



もし常に新しいタブを開くようにしたい(Enter→新しいタブ、Alt-Enter→新しいタブ)場合は、about:configを開いて extensions.treestyletab.urlbar.invertDefaultBehavior を false に設定して下さい。

Windows 7のAeroPeek(タスクバーのプレビュー)にアドオンから手を出してみる - May 13, 2010

Windows 7では、特定のアプリケーションのウィンドウが複数開かれている状態でタスクバー上のボタンをポイントすると、各ウィンドウのプレビューが一覧表示されるようになっている。これはAero Peekという機能だ。Firefox 3.6以降ではこのAero Peekのためのコードが入ってて、about:configでbrowser.taskbar.previews.enableをtrueに変更して機能を有効にすると、ウィンドウごとではなくタブごとのプレビューが表示されるようになる。Trunkではデフォルトで有効になってるので、次のメジャーリリースでもそうなるんだろう。


FirefoxでウィンドウごとではなくタブごとのプレビューをAero Peekに表示させるためのコードのうち、アドオンから簡単に触れるのはWindowsPreviewPerTab.jsmにあるコードだ。以下のようにするとプレビューのマネージャにアクセスすることができる。

alert(AeroPeek); // "[object Object]"



AeroPeek.windows.some(function(aTabWindow) {
  if (aTabWindow.win == window) {
    // 現在のウィンドウに対する操作
    return true;
  return false;


aTabWindow.previews.forEach(function(aPreview) {
  var tab = aPreview.controller.wrappedJSObject.tab;
  // タブに応じた操作

プレビューのオブジェクトはvisibleという真偽値のプロパティを持っていて、これの値がtrueだとAero Peekのプレビューが表示され、falseだと非表示になる。ツリー型タブの場合、タブが折り畳まれているかどうかによってこの値を上書きするようにしている。

var tab = aPreview.controller.wrappedJSObject.tab;
aPreview.visible = !TreeStyleTabService.isCollapsed(tab);

初期状態では、visibleの値はbrowser.taskbar.previews.enableの値と同じになっている。アドオンでvisibletrueにするとユーザがAero Peekを設定で無効化してても問答無用でプレビューが表示されてしまうので、誤ってtrueにしてしまわないように気をつけないといけない。僕はうっかりこれをやってしまった。





AeroPeek.windows.some(function(aTabWindow) {
  if (aTabWindow.win == window) {
    aTabWindow.previews.forEach(function(aPreview) {
      var tab = aPreview.controller.wrappedJSObject.tab;
      aPreview.visible = !TreeStyleTabService.isCollapsed(tab);
    return true;
  return false;



タブバーの縦置き・横置きをタブの数に応じて自動で切り替えたい(A new option to switch the position of the tab bar by the number of tabs.) - May 06, 2010


I have a feature request for Tree Style Tab.

I'd like to use horizontal tabs when I have 5 or less tabs open and then have Firefox automatically switch to vertical tabs when I have 6 or more tabs open. These numbers could obviously be variables in the settings, and the feature could just be toggled from the settings as well.




I have no plan to implement the feature to Tree Style Tab itself, however, you can do it by a tiny script using TST's APIs like:

(function() {
  var onTabModified = function() {
    var newPosition;
    if (gBrowser.tabContainer.childNodes.length > MAX_HORIZONTAL_TABS)
      newPosition = 'left';
      newPosition = 'top';
    if (TreeStyleTabService.currentTabbarPosition != newPosition)
      TreeStyleTabService.currentTabbarPosition = newPosition;
    .addEventListener('TabOpen', onTabModified, false);
    .addEventListener('TabClose', onTabModified, false);
  window.addEventListener('unload', function() {
    window.removeEventListener('unload', arguments.callee, false);
      .removeEventListener('TabOpen', onTabModified, false);
      .removeEventListener('TabClose', onTabModified, false);
  }, false);

For example, you can use this script for the userChrome.js. Steps to do it:

  1. Install userChrome.js from the official website.
  2. After installation, copy the codes above and paste to the file "userChrome.js" in your profile folder. (ex. C:\Users\username\AppData\Roaming\Mozila\Firefox\Profiles\***.default\chrome\userChrome.js )



  1. userChrome.jsをオフィシャルサイトからインストールする。
  2. インストールが完了したら、前述のコードをコピーして、プロファイルフォルダ内にある「userChrome.js」というファイルに貼り付ける。(例: C:\Users\username\AppData\Roaming\Mozila\Firefox\Profiles\***.default\chrome\userChrome.js )

Why I'm using eval() instead of others? - Apr 06, 2010



Surely I wrongly believed that the policy is flexible for cases, because Tree Style Tab was in the "recommended" list actually. When the policy was changed (to be applied completely for any addons), it had to be removed from the list quickly. This is not a cynicism, I'm really worrying that double standard will make developers confused.

In fact I had not reviewed addons as an editor yet, so this is nonsensically thing, but if I still can talk about this, I didn't mean to accept any addons include eval()s without reviewing. When there are alternative safer way, I thought that recommend him to rewrite his codes. I just told about cases which are not alternated by other ways.

Anyway, I agree to the decision that you've removed me from the group. I had no actual achievement as an editor (there is zero review! I'm very sorry.), instead, I'm all mouth. That's that. I'll still use AMO as an addon author, to put old XPI files, and I possibly move existing versions in the AMO to the beta channel. I think that AMO is really really great work. Editors also.



Can I explain again the reason why I'm using eval() to override existing functions instead of other ways? Of course I use custom DOM events or other safe way when they are available. Following topic is about cases which don't fire custom events. In other words, I explain why I don't like replacing of existing functions by "originalFunction.apply(this, arguments)".

In old days I developed an all-in-one style addon named "Tabbrowser Extensions (TBE)" for Firefox 1.5 and older versions. It was one of major addons about tabbed browsing enhancements, until Tab Mix Plus appeared. In the addon, I aggressively replaced many internal functions of Firefox itself, like:

var origFunc = gBrowser.moveTabTo;
gBrowser.moveTabTo = function() {
  var result = origFunc.apply(this, arguments);
  // some post-process for the moved tab
  return result;

Yes, it is one of ways recommended in the entry http://adblockplus.org/blog/five-wrong-reasons-to-use-eval-in-an-extension for injecting some operations before/after the original function.

However, then I frequently suffered from compatibility problems with other addons around tabs, because they used eval() to inject their tiny codes to existing (Fireflx's original) functions, like:

eval("gBrowser.moveTabTo = "+gBrowser.moveTabTo.replace(
  "tab = ",
  "doSomething(); $&"

As you know, replacing of functions break addons which inject codes by eval() like above. So I had to choose how to solve this problem, from two ways: 1) import and merge the function of the addon conflict with TBE, 2) use eval() instead of replacing of functions. There was no other choice. To make another addon compatible to mine, it had to be re-written without eval(), but it can't be done in some cases, because the feature surely required injected codes to existing functions. I couldn't make mine compatible to the addon without eval(). I disliked eval(), then I chose "1". In the result, TBE became very very fat addon and I couldn't continue to develop it by me alone anymore. I abandoned it.

I can't force users to forbid using addons which depend on eval(). On the other side, I cannot merge too many features to my own addon because fat and huge project will annoy me. From both reasons "make my addon compatible with the addon" and "keep my addon simple (without extra features)", now I'm using eval()s to inject just minimal codes.

Safety margin about compatibility to other tab-related addons is one of core values of Tree Style Tab and other my addons developed after TBE. When I get reports of compatibility problems with other addons, I try to make mine compatible to others if at all possible (and, of course, for compatibility some my addons provide APIs for others.) If there were only "clean" ways (DOM events, Object.prototype.watch(), etc.) TST were far from satisfactory for tab addicts. Because I'm also using many other tab-related addons (not developed by me), if it doesn't work others, I also won't use TST. Just for making my addons compatible to existing and future addons, I chose eval().

If there were many other custom events for bookmark commands, new tab commands, etc., I won't use eval()s. XBL, CSS hacks also. However, margins for extending UIs (unused boxes etc.) are getting removed from Firefox, because "they eat the RAM, they make the startup process slowly". Only to adding extra elements to tabs, I had to use custom XBL at risk of compatibility problems with third party's themes.

Firefox is getting hard to be extended for me (and my addons). My addon was listed to "recommended", and people say "update it for latest Firefox". There is no way to provide features of my addon without dangerous way. That is my situation.

今evalを理由に審査を蹴られるのであっても、その代替となるより安全な手段が提供されるのであれば、迷わずそっちに乗り換えたいとは思ってる。問題は、独自のXBLを提供するなどの「危ない」事をしなければやりたい事を実現できないような、拡張機能から触れる伸び代の部分がどんどんなくなってるという事だ。それどころか、起動速度が落ちるからという理由でFUELがばっさり切られたように、今ある必要な物すらどんどん切られていっている。W3Cですら、テーブルレイアウトを必要とする人達のニーズにある程度答えられるような、position: absoluteのような仕組みを仕様に取り入れていたというのに。そういう現実を抜きにして、この話は語れないと思う。

あと先方から補足があったけど、曰く、AMO Editorsグループから外した直接の理由は確かに「ポリシーに同意していないから」だけれども、活動してないエディタを外す事自体はよくあることだそうで、ポリシー云々のことが無くてもレビュー実績0の自分はいずれ外されてただろうとのことです。

Why I don't roll Tree Style Tab back to the version which have the option "hide new tab button"? - Mar 31, 2010

I got some requests to add an option "hide new tab button" again.

Excuse me, but I say "no". There are two reasons.

First, by adding too many options, users consider Tree Style Tab as an all-in-one/versatile addon, and novice users who don't understand what is the purpose of TST will also install it. I don't hope that future. Actually, I received some requests like "please add an option to disable tree features, I want only a vertical tab bar." -- I just ignored it.

Yes, currently TST has some features not related to tree, but they are anguished decisions. When I find out other addons which provide those futures, I'll readily remove them from TST itself, and make TST work with those addons together. (Actually I removed "open selected links in tabs" and some features.) I hope that only users who want to use "tree of tabs" install TST.

By the way, in old days I developed an all-in-one style addon "Tabbrowser Extensions" which was well-known before the Tab Mix Plus became major. It had very various options about tabs, it had huge codes, I received too many requests, and I gave up to continue to develop it. I don't want to repeat stupid thing like that.

Second, hiding the "new tab" button is a choice of an user who use another addon to do it. TST is designed to work with visible"new tab" button, and not designed to work without the button. If you decide to hide the button at your own risk, you also have to care the result, especially when you hide the button by customizing of userChrome.css.

Nonetheless, If you hide the button by an option of an existing addon, then I should add some hack to TST for compatibility with the addon, because I said "and make TST work with those addons together." Which addon do you use, Tab Mix Plus? TMP Lite CE? Tab Utilities? If you tell me which is installed, then I can write hack for the addon promptly.



Page 9/243: « 5 6 7 8 9 10 11 12 13 »

Powered by blosxom 2.0 + starter kit