[Bug] Firefox 150 日本語版で「新しい空のタブの基本的な取り扱い」のタイトル条件が「新規タブ」に対応していない

[knoajp]

Abstract

設定「新しい空のタブの基本的な取り扱い」にて、タイトルが [新しいタブ|新しいプライベートタブ] またはURLが [about:newtab|about:privatebrowsing] であるタブが開かれた場合、新しい空のタブが開かれたとみなす という項目がありますが、Firefoxの日本語ローカリゼーションが変わったのか、少なくとも Firefox 150 では「新しいタブ」ではなく「新規タブ」と名付けられるため、このままでは適用されず、[新規タブ|新規プライベートタブ] と書き換える必要がありました。

ただしそもそも、開発ツールで確認できるURLは about:newtab ではあるので、本来であればタブの日本語名称に関わらず適用されてしかるべきだとも思います。何か別の問題も起きている可能性もあるかもしれません。

Steps to reproduce

1. Start Firefox with clean profile.（日本語ロケール）
2. Install TST.
3. TSTの設定画面を開き、「新しい空のタブの基本的な取り扱い」の項目で、新しい空のタブを開く位置を変更する。
   • デフォルトの条件文に「タイトルが [新しいタブ|新しいプライベートタブ] …」と書かれている。
4. 新規タブ（Ctrl+T）を開く（タイトルが「新規タブ」になる）。(新しい空のタブを開く位置が意図通りになっていない)

Expected result

URLが about:newtab であるため、新しい空のタブとして正しく認識され、設定通りの扱いが適用される。
(またはタイトル条件が日本語ローカライズに合致するために問題なくうまく行く)

Actual result

タイトルが「新規タブ」であるためデフォルト条件にマッチせず、新しい空のタブとして認識されない。
手動で [新規タブ|新規プライベートタブ] と書き換えない限り適用されない。
URL条件が about:newtab に一致するもかかわらず、やはり適用されない。

Environment

• Platform (OS): macOS Sequoia 15.7.4
• Version of Firefox: 150 （日本語版）
• Version (or revision) of Tree Style Tab: 最新版

[piroor]

「新規タブ」という語句はmacOS用ロケールでのみ使われている用語のようです。
（他のプラットフォーム用のロケールでは今も「新しいタブ」のままとなっています）
Windows版のFirefox 150Beta5では再現しなかったので、macOS版固有の問題である可能性があります。

[knoajp]

なんと、そんなことがあるのですね。
わざわざMacだけ変える理由として「Safariでの呼称に合わせた」というものを思いつきましたが、Safariでは「名称未設定」となるようで、アテは外れました。

URL条件(about:newtab)がなぜか適用されない問題は、Windows版の Firefox 149 でも発生しているようです。
なのでWindowsでもMacでも、日本語環境ではタブのタイトル条件で判定させるしかなく、両プラットフォームに対応させるには [新しいタブ|新規タブ|新しいプライベートタブ|新規プライベートタブ] のように記入しておくことが回避策となりそうです。(ツリー型タブの設定は Firefox Sync で自動で同期されるため、Windows/Macの両方を使っている場合は両方を併記する必要があります)

[piroor]

URL条件(about:newtab)がなぜか適用されない問題は、Windows版の Firefox 149 でも発生しているようです。

妙ですね、自分の環境ではここは特に問題無いみたいなんですが……

設定画面の最後にある開発者向けのオプションでデバッグモードを有効にして、 background/api-tabs-listenerとbackground/handle-new-tabsのログを出力した状態でFirefoxのタブバーやキーボードショートカットから空タブを開いたときのログ（about:debuggingからデバッグツールをTST用に開いて「コンソール」を選択すると見られます）は、自分の環境だと以下のようになっていて、ここでハイライトしている「behave as a tab opened by new tab command」というメッセージが、新たに開かれたタブが「新しいタブ（新規タブ）」コマンドで開かれたものと判定された事を示しています。

そちらの環境ではどうでしょうか？

[knoajp]

すみません、
URL条件(about:newtab)がなぜか適用されない問題は、Windows版の Firefox 149 でも発生しているようです。
の部分を撤回します。確かにそうだった気がしたのですが、改めて試してみたところ、正しく動作しているようです。当初の私の検証に手違いがあったのかもしれません。

また、Mac版でも、特定のプロファイルでしか再現しない様子です。(そのプロファイルと同期したWindows版では再現せず、正常動作します)

よくわからなくなってしまいましたが、少なくとも「新規プロファイルでは再現しない」状況なので、私の固有の問題(しかもタイトル条件で回避できる)としてclosedしてしまうべきかもしれません。そもそもこのissueは「新規タブ」という日本語ラベルの問題が主眼でしたし。

---

以下は参考までに

Mac版の問題のFirefoxプロファイルでは、
[新しいタブ|新規タブ|新しいプライベートタブ|新規プライベートタブ] と [about:newtab|about:privatebrowsing]
の状態だと behave as a tab opened by new tab command のログが出て期待どおりに動作しますが、
[ABC] と [about:newtab|about:privatebrowsing]
の状態だと behave as a tab opened with any URL 新規タブ about:blank のログが出て、設定で指定した動作にはなりません。(Windows版ではURL条件が正しく認識されて正常動作します)

ログを参考に、試しに about:blank も加えて about:newtab|about:privatebrowsing|about:blank にしてみても、やはり効きません。

他のアドオンに問題があるのかと考え、
Mac版の問題のFirefoxプロファイルで、ツリー型タブ以外のアドオンをすべて無効にした状態でも同様に問題が起きました。

ならばTST自身の設定に問題があるのかと考え、
Mac版の問題のFirefoxプロファイルからTSTの設定をエクスポートして、新規プロファイルのFirefoxでインポートしても、問題は再現されませんでした。

となると問題のプロファイル固有の条件は about:config くらいしか思いつかないのですが、about:config 内の何かが影響することがありうるでしょうか…？
(userChrome.css も使っていますが、影響することは考えにくいと思いました)

Mac版の新規プロファイルを用意し、問題が再現するまで環境を問題のプロファイルに近づけることを試みました。
TSTのみをインストールし、TSTの設定をインポートしただけでは前述の通り再現しないので、さらに pref.js もコピーしたところ、再現しました。さらに調査すると、about:config 内の browser.newtabpage.enabled が false だと問題が再現して、デフォルトの true だと正常動作することがわかりました。

これで、新規プロファイルでの再現(クリーン → 問題再現)に成功し、原因を突き止められてめでたしめでたしかと思いきや、元々の問題のプロファイルで問題を解消しようと(問題状態 → 問題解消) browser.newtabpage.enabled を true にしただけでは解決しないこともわかりました。問題のプロファイルの about:config 内で newtab で検索した、あらゆる変更済みの項目をデフォルトにしてみましたが、やはり問題は解消できません。いよいよお手上げです。

結局、わたしの環境では問題のプロファイルで about:newtab の条件を正常動作させる方法は見つからないものの、「タイトル条件で回避できる」ことから、お手上げのままでもいいかという気持ちになっています。

わかりづらい長文失礼いたしました。

[piroor]

確認ありがとうございます！

ログを見た感じでは、behave as a tab opened by new tab commandの分岐に入るための条件はほぼ満たされている様子です。
Tabs.onCreating の所に出ている 1699 がそのタブの識別子なのですが、このコンソールで Tab.get(1699).$TST.isNewTabCommandTab と入力した時、false と出る状態でしょうか？
もし、期待通りの動作を得られなかった後で Tab.get(id).$TST.isNewTabCommandTab を見てみて true になっているようなら、新規タブが開かれた直後のこの瞬間だけ何らかの理由で判定結果が期待通りになっていない、ということになります（isNewTabCommandTab はgetterなので、プロパティアクセスする度に都度判定が行われます）。

開発ツールの「デバッガー」で /background/background.html → Tree Style Tab → background → handle-new-tabs.js と辿り、63行目付近の log('Tabs.onCreating ', dumpTab(tab), tab.openerTabId, info); のところで行番号の上でコンテキストメニューを開いて「ログを追加」を選択し、入力欄に [tab.url, tab.previosuUrl] と入力した状態で、新規タブを開く操作を実施してログを確認してみていただけますか？
もしログに ["about:blank", "about:blank"] と出ているなら、FirefoxかTSTか誰かがそのタブについて「about:blankで開く→その上でさらにもう一度about:blankを読み込む」ということをしていて、それが原因で判定結果が期待と異なっている状況と判断できます。

[piroor]

すみません、browser.newtabpage.enabled が false のときに再現するという所までは確認頂けてたのを読み落としていました。
ただ、WindowsのNightly 151.0a1で試した限りでは、この設定が false でも再現はしないという結果になりました。
まだ他にも何か条件があるのかもしれません。

とりあえず、 02652dd でmacOS版の新規タブの名称も規定の判定対象に加えるようにはしたので、TSTのこの設定を既定のまま使う場合の状況は改善されると思います。