2004525 - The "Tree Style Tab" extension can't detect new/focus changed/closed tabs on current Firefox Nightly

Status: VERIFIED FIXED

(WebExtensions :: General, defect, P1)

Description

[rinsuki]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:147.0) Gecko/20100101 Firefox/147.0

Steps to reproduce:

• Install Tree Style Tab, https://addons.mozilla.org/firefox/downloads/file/4602712/tree_style_tab-4.2.7.xpi
• Restart Firefox, by open about:profiles and Press "Restart Normally..."
• After Restart, Open Tree Style Tab sidebar by "View" Menu → Sidebar → Tree Style Tab.
• Try to open/change focus/close tabs.

Actual results:

These actions would not applied to the Tree Style Tab extension:

• Open New Tab
• Close Tab
• Change Focused Tab

(you could force "resync" by close→open sidebar, btw)

but these are still applied to the extension:

• Tab title changed
• Tab loaded

My environment:

• macOS 15.7.2（24G325）
• MacBook Pro (14-inch, 2021, M1 Max)
• Firefox Nightly 147.0a1 (2025-12-05) (aarch64)

Expected results:

If user open/close/change focused tab, it should be applied to the extension.

Comment 1

[rinsuki]

I checked this bug with the mozregression, and it shows
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=37f1c536fdb89cd69039774a87f3ad8a94b95328&tochange=86c4f03a43058ea62f76021ad5a50e6199c34567 .

Comment 2

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Firefox::New Tab Page' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[BugBot [:suhaib / :marco]]

:vhilla, since you are the author of the regressor, bug 543435, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 4

[rinsuki]

I noticed some important things:

• This bug can be reproducible on macOS 15.6.1 (24G90) (Apple Silicon) VM (w/ UTM), but cannot be reproducible on Windows 11 Arm 25H2 VM (w/ Parallels), so this might be macOS (or *nix?) -only bug (didnt tested on Linux or other *nix yet, btw)
• It seems only first window will be affected by this bug. If you have open new window after first one, they would works. also If firefox restores multiple window at launch, only one of them are bugged, others are fine.

Comment 5

[Henri Sivonen (:hsivonen)]

From the regression and reporting timeline, it looks like bug 2003255 didn't affect this either way. Is that right?

Only one window having the bug seems vaguely similar to bug 2003452.

Comment 6

[Henri Sivonen (:hsivonen)]

The extension has lots of code, so it's not obvious where to start looking. Quick observations:

• The extension has a number of DOMContentLoaded listeners.
• The extension does not appear to look at readyState at all.

Comment 7

[Ryan VanderMeulen [:RyanVM]]

Bug 543435 was reverted from Fx147. Updating the flags accordingly.

Comment 8

[vcarciu]

I am able to reproduce the issue using the steps from initial description on macOS Sequoia 15.7.1 , using latest Firefox Nightly .
I will mark the issue as NEW since it is now confirmed.

Comment 9

[Vincent Hilla [:vhilla]]

Might be related to bug 2003514, but Henri already pointed out that the extension doesn't appear to look at readyState. I think DOMContentLoaded for initial about:blank doesn't have good test coverage, nor is it well specified.

If no one else is able to figure out what is failing, I'll keep this on my list and try to take a look after some of the other regressions.

Comment 10

[Rob Wu [:robwu]]

Piro is the author of Tree Style Tabs. Do you consider this to be a browser/Firefox bug, or is it something that TST can/should fix?

Comment 11

[Vincent Hilla [:vhilla]]

I can reproduce it on MacOS too, but not on Linux. I'm unsure if this warrants S2, the extension doesn't appear usable to me on MacOS.

(In reply to Rob Wu [:robwu] from comment #10)

Piro is the author of Tree Style Tabs. Do you consider this to be a browser/Firefox bug, or is it something that TST can/should fix?

That is hard to stay without knowing the reason. I tend towards browser bug, just because it's likely that bug 543435 broke something. But a single-platform issue that impacts non-about:blank tabs in the window is surprising.

It would be helpful if Piro can help narrow down the issue or share some ideas where we could look.

Comment 12

[YUKI "Piro" Hiroshi]

I've investigated a little what happens. Things I've confirmed:

• This happens only on macOS.
• This happens with these steps:
  1. Start Nightly with a clean profile.
  2. Go to about:preferences and configure Nightly to restore previous session on the startup. (Now you have two tabs in the window: the initial tab and the about:preferences tab.)
  3. Press Command-N to open a new blank browser window. (Now you have two browser windows.)
  4. Type "Tree Style Tab" into the address bar and hit the Enter key, to search it on the Web.
  5. Go to the addon page and install TST.
  6. Press Command-T to open a new blank tab. (Now you have two tabs in the window: TST addon page and a blank tab.)
  7. Exit Nightly.
  8. Start Nightly. Now you have two browser windows with opened sidebars.
  9. Exit Nightly.
  10. Start Nightly. Now you have two browser windows, one has opened sidebar but another has closed sidebar. (The problem happens.)
  11. Type "Second Search" (or something another addon which requires "tabs" permission) into the address bar and hit the Enter key, to search it on the Web.
  12. Go to the addon page and install Second Search.
  13. Go to about:debugging.
  14. Open the inspector of the Second Search.
  15. Go to the "Console" tab.
  16. Run browser.tabs.onHighlighted.addListener(console.log).
  17. Try to switch tabs on both windows. You'll see notified events only around events on the second window.
• As described above, the problem affects to other addons. When this happens, Firefox does not notify events around the first window to browser.tabs.onXXX listeners of any addons not only TST.
• I've tried a small testcase instead of TST but the problem does not happen. TST's initialization process calls large number of APIs, so some of them may trigger the problem.

Anyway there looks to be a bug of Firefox itself because the problem affects to other addons also. The WebExtensions system need to isolate each addon and the problem must be enclosed only to TST.

Comment 13

[YUKI "Piro" Hiroshi]

This problem looks intermittent. I've tried to figure out concrete steps to reproduce, and I've confirmed that sometimes reproduced, sometimes not with following steps:

1. Start Nightly with clean profile.
2. Install TST.
3. Prepare two browser windows:
   • Window 1 (with opened sidebar)
     • Tab 1-1: about:preferences
     • Tab 1-2: about:profiles (active)
   • Window 2 (with opened sidebar)
     • Tab 2-1: about:newtab
     • Tab 2-2: about:debugging (active)
4. Press the button "Restart normally" in about:profiles to restart Nightly.
5. Confirm that both windows have opened sidebar.
   • If both windows have opened sidebar (you failed to reproduce the problem), confirm that the sidebar of the window is correctly updated with tab switchings.
   • If a window has closed sidebar (you successfully reproduced the problem), open the TST sidebar and confirm that the sidebar of the window is never updated with tab switchings.
6. Repeat 4-5 multiple times.

Comment 14

[YUKI "Piro" Hiroshi]

I've tried to investigate more with the browser toolbox.
On this situation, for example, TabMultiSelect DOM event is actually fired in the initial browser window, but TabTracker's handleEvent is not called for the event.
https://searchfox.org/firefox-main/rev/d0cad31feab6676471f18793c8feff24b2434ab0/browser/components/extensions/parent/ext-browser.js#588
This looks to mean that windowTracker.addListener("TabMultiSelect", this); has failed to process the initial window.
https://searchfox.org/firefox-main/rev/d0cad31feab6676471f18793c8feff24b2434ab0/browser/components/extensions/parent/ext-browser.js#344
https://searchfox.org/firefox-main/rev/d0cad31feab6676471f18793c8feff24b2434ab0/toolkit/components/extensions/parent/ext-tabs-base.js#1808-1811
Is there any possibility that window tracker's browserWindows() failed to list the initial window?

Comment 15

[Henri Sivonen (:hsivonen)]

Piro, thank you for debugging this!

Rob, considering the three most recent comments above, can you identify which part of docshell events/notifications and extensions host code has an intermittent disconnect?

Comment 16

[YUKI "Piro" Hiroshi]

After more investigation I've realized that sometimes Firefox fails to list initial windows here.
https://searchfox.org/firefox-main/rev/f1f744222035cb8d47f4ae732a33612cd6055693/toolkit/components/extensions/parent/ext-tabs-base.js#1663
https://searchfox.org/firefox-main/rev/f1f744222035cb8d47f4ae732a33612cd6055693/toolkit/components/extensions/parent/ext-tabs-base.js#1529
On success cases, the initial browser window is detected as "document.readyState == loading" so returned as a incompletely loaded browser window.
On failure cases, the initial browser window is detected as "document.readyState == complete" and "document.documentElement == null", as the result the window is detected as non-browser window and skipped.
It looks very odd that "complete" ready state with null documentElement. Why it happens?

Comment 17

[Henri Sivonen (:hsivonen)]

(In reply to YUKI "Piro" Hiroshi from comment #16)

After more investigation I've realized that sometimes Firefox fails to list initial windows here.
https://searchfox.org/firefox-main/rev/f1f744222035cb8d47f4ae732a33612cd6055693/toolkit/components/extensions/parent/ext-tabs-base.js#1663
https://searchfox.org/firefox-main/rev/f1f744222035cb8d47f4ae732a33612cd6055693/toolkit/components/extensions/parent/ext-tabs-base.js#1529
On success cases, the initial browser window is detected as "document.readyState == loading" so returned as a incompletely loaded browser window.
On failure cases, the initial browser window is detected as "document.readyState == complete" and "document.documentElement == null", as the result the window is detected as non-browser window and skipped.

The initial about:blank is weird in that it has readyState == "complete" before its load event. But also, by the time the document is observable, it's too late to attach a load event handler.

It looks very odd that "complete" ready state with null documentElement. Why it happens?

That is indeed very odd even for the initial about:blank.

Comment 18

[Henri Sivonen (:hsivonen)]

(In reply to Henri Sivonen (:hsivonen) from comment #17)

It looks very odd that "complete" ready state with null documentElement. Why it happens?

That is indeed very odd even for the initial about:blank.

I see yield window. Could it be the case that readyState == "complete" is observed for the initial about:blank and then at the yield point, the non-about:blank document has had its Document object created and the null documentElement is observed with that distinct document?

Comment 19

[Vincent Hilla [:vhilla]]

From testing, it seems to me that checking for isUncommittedInitialDocument here fixes the bug. Conceptually, it makes sense to add such a check in both places.

But we should come up with a test case and maybe look for other places where readyState checks need to be amended.

Comment 20

[Rob Wu [:robwu]]

There are multiple places in extension code that try to classify a window by type. It is possible to encounter a race condition where an in-progress window is encountered that is still pending initialization. Previously we could detect them by falling back to the "load" event if uninitialized (detected by document.readyState being not-"complete"); now we also need to account for about:blank whose initial state is "complete".

I'll look into a unit test. One question that I have, is it guaranteed for the "load" listener to persist and be triggered eventually after the document is committed?

I know that in some cases the listener is blown away, but that should not be relevant to browser windows (https://phabricator.services.mozilla.com/D267864).

Comment 21

[Rob Wu [:robwu]]

Attachment: Bug 2004525 - Fix WindowTracker to recognize initial about:blank

With the changes from bug 543435, document.readyState of initial
about:blank is no longer "uninitialized", but "complete". This change
broke the logic of WindowTracker, because it started to treat
uninitialized windows as completed browser windows, and fails to detect
them as browser windows.

To fix this, add an isUncommittedInitialDocument check where needed,
and fix various callers that made the wrong assumptions.

Comment 22

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/80265519b756
https://hg.mozilla.org/integration/autoland/rev/dfc6681d9892
Fix WindowTracker to recognize initial about:blank r=zombie

Comment 23

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/dfc6681d9892

Comment 24

[vcarciu]

Verified as fixed in Firefox 148.0a1 using macOS 15.7.1.