Tab Grouping Folders broken

[guigirl42]

Steps to reproduce

• Open Firefox-**NIGHTLY** in a new profile
• Install Sidebery, either Stable (v5.4.0) or Nightly (v5.5.0.1, or recent older)
• Attempt to create a tab group, either of normal/nonpinned tabs, or from a pinned tab

Actual behavior

• Observe that a Group folder is created, but it ignores any name you give it, simply has three dots, & contains no list of the associated grouped tabs
• Observe that this broken folder then fails to auto-delete once its final child tab has been closed

Expected behavior

• In Firefox-Nightly before v149 [or possibly 148 ?], tabs grouping worked correctly
• In ordinary Firefox 147, tabs grouping still works correctly atm

System

ArchLinux KDE Plasma 6.5.x Wayland, Fedora Kinoite KDE Plasma 6.5.x Wayland

Firefox version

Nightly 149 definitely, 148 possibly

Sidebery version

Stable (v5.4.0) , Nightly (v5.4.9 ?, v5.5.0.1)

Logs

Content Script execution in moz-extension document has been deprecated and it has been blocked (Extension ID: {3c078156-979c-498b-8990-85f7987dd929}). group.html
[bg] Tabs.injectGroupPageScript: Cannot inject script, tabId: 38 Error: Missing host permission for the tab chunk-7XYURGQR.js:4:15231
Content Script execution in moz-extension document has been deprecated and it has been blocked (Extension ID: {3c078156-979c-498b-8990-85f7987dd929}). group.html
[bg] Tabs.injectGroupPageScript: Cannot inject init data, reloading tab

[mbnuqw]

The cause is the https://bugzilla.mozilla.org/show_bug.cgi?id=2011234: It doesn't allow the addon to inject scripts in its own pages, which is used by Sidebery to create persistent pages (group-page and placeholder-page (for unsupported urls)). Without it, all these pages will be closed on the next update/disabling of the addon.

Possible workarounds:

• Try to restore group/placeholder pages, if they were closed. This is how they were initially implemented until I found the above mentioned way to create persistent pages. It was super fragile and bug-prone and I'd like to avoid it.
• Say goodbye to persistent group(placeholder)-pages. Use "virtual" tabs in Sidebery sidebar (without native tabs). On click, fold/unfold the branch (like native Firefox groups)
• ...suggest another workaround? (there is still time until v152 is out, when this uh... security enhancement will be enabled in non-nightly versions)

[guigirl42]

Thanks for your fast reply, but i feel extremely sad at the news you've imparted. For both Sidebery & TreeStyleTab(1) AddOns this ability to create on-the-fly tab group pages, with all the functionality their respective equivalents had for those pages, was for me a major feature that elevated both AOs high above all other tab-management modes, in other AOs but also browsers natively like FF, Chromium, Vivaldi.

With the fundamental loss of this capability now, in both these magnificent AOs, from 149+ due to the FF Devs' design decision, i'm going to have to try to formulate a new browsing paradigm [i mean as a user; i have no coding skills nor knowledge at all]. No longer being able to create hierarchical Groups that i can [automatically or manually(2)] name to identify their contents, in a way now makes [this aspect of Sidebery & TST] arguably less useful even than FF's own native tab-grouping mode... the one remaining advantage ofc though being we still can have infinite nesting.

1. I opened my dedicated TST Profile to test if it has also lost this function, once i read your reply. Yes, its Group pages are also broken, but much worse even than for Sidebery, coz now every one of my TST Group tabs is reloading continuously & using large cpu% -- ugh.
2. Oh i was half-wrong -- i can still manually rename each group tab... albeit this will be a bit tedious not having them auto-named when auto-created anymore... so afaict now it's just inconvenient rather than disastrous.

Use "virtual" tabs in Sidebery sidebar (without native tabs).

Please would you explain a bit more what you mean?

[mbnuqw]

extremely sad

I feel this way too. At first, I thought that this was only about injecting code as a string, which is used by Sidebery to inject current state as JSON for faster initialization of the group page (in that case it'd be easy to create workaround), but it's a general restriction for moz_extension scheme.

It'd be less bitter if there was a strong reason for this API limitation. But as I understand it, it's just "It's a bug that addon can inject code in its own page, let's generalize CSP restrictions" (why not make an exception for addon's own pages? It seems logical, after all) and (my favorite) "Chrome doesn't allow it".

Please would you explain a bit more what you mean?

By virtual tab I meant that this "tab" will exist only in sidebery sidebar, without actual group-page.

For now, the plan is this:

1. Detect broken group-tabs and instead of rendering their actual title ("---") render their configured titles + update tooltip/preview + change copy actions. On click fold/unfold the branch, instead of activating that broken page. Same with the placeholder pages. This is a quick, temporary fix. Broken group pages will still be in the native tab list, but they will be correctly rendered in sidebery sidebar.
2. Prepare working group-page. Open and activate it when user click on the broken group tab in sidebery sidebar but don't render it in sidebery sidebar. Reuse it (just update its content) when user will activate another group page. This way, previous behavior will be partially restored, though it feel too hacky.
3. Handle Sidebery's own tab list and decouple it from the native tab list (it is already planned as an experiment anyway). This will allow to create virtual group tabs and much more (mix tabs and bookmarks in one list, add notes in tab list, etc...). But this is a distant prospect.

Maybe I'll think of something else...

[guigirl42]

I feel this way too

Yes i can absolutely believe this! You have laboured long & hard for many years to create this fabulous project, & afaict you have many ardent fans around the world who adore Sidebery, & admire your cleverness & generosity. It must feel like the rug has been roughly pulled out from under your feet, & i'm sorry for the distress this recent Mozilla decision has created for you. 🤗

By virtual tab I meant that...

Aha, ok, many thanks.

the plan is...

Best wishes for this unexpected new workload. Ofc i will keenly look forward to trying the forthcoming updates. Good luck to you.

[nx5314]

I'm curious as to how many sidebery users also use the native tabs at the same time? Hiding native tabs was the first thing I did when I started using sidebery, so it leads me to wonder how much of an impact less native tab integration would have on most users. Either way, that plan part 3 looks pretty exciting though, even if it's a ways off.

[guigirl42]

I used to always keep the native FF tab-strip hidden, when i began using Sidebery several years ago. However recently i have begun showing them again, which i dislike, but see no alternative, given

• i use the relatively new FF Nightly split-tabs function frequently, & atm there is neither any keyboard shortcuts for it, nor any way to invoke it within Sidebery (no API; Integrate Firefox split view feature #2327)
• i use the relatively new FF Nightly tab-note function, & atm there is neither any keyboard shortcuts for it, nor any way to invoke it within Sidebery

[Rob--W]

Hi, Firefox dev here, involved in the bug report and deprecation. While documentation is being worked on, it is not ready yet.

The point of making it a deprecation warning and enforcing it Nightly-only for a few releases is to allow extensions some time to handle the upcoming changes and allow room for feedback. I understand that a change like this can be distressing, so I will share how we envision extensions to modify their implementation. Feedback is welcome.

As an extension is in full control of the scripts that run in extension documents, the envisioned alternative for executeScript is to embed the script directly in the extension document and/or to use extension messaging.

For example, if you wanted to execute a script like this:

// tabId referring to extension tab
let [result] = await browser.tabs.executeScript(tabId, {
  code: "document.URL",
});

That can be replaced with two parts. One, the trigger:

let result = await browser.tabs.sendMessage(tabId, "mymessage");

and two, the script logic:

// Logic running in your extension document in the tab
browser.runtime.onMessage.addListener((msg, sender) => {
  // Security check against spoofing by content scripts.
  if (sender.origin !== location.origin) return;
  if (msg === "mymessage") {
    // Run original code:
    let result = document.URL;
    return Promise.resolve(result);
  }
});

This is a general solution; any logic running a static code string or file can be modified to run like that.

If your logic is optional and you don't want to run all code at once, it is also possible to dynamically run scripts by appending <script> elements, or even using the standard dynamic import feature.

Note that it is not possible to dynamically execute code (like eval) in this manner. Executing arbitrary code is a security risk. Extensions have powerful privileges and are held to a higher standard than web pages through a strict default CSP. Many use cases involving eval-like capabilities have reasonable alternatives, but for cases where that is not possible we could consider implementing manifest sandbox as an alternative (https://bugzilla.mozilla.org/show_bug.cgi?id=1685123). I will discuss this option with my colleagues next week.

[mbnuqw]

Hey, thanks for detailed answer and sorry if I offended you or anyone in my emotional replies.

The problem is not the inability to run a script on the page or send data via messaging API. When the addon opens its own page with a script, this page will be closed on the next update of addon (or disabling addon). In case of Sidebery's group and placeholder¹ pages user will have their tabs tree destroyed and will lose data (placeholders for unsupported urls).

But, when we open a script-less addon's page (just html + styles) and then inject a script into it, such pages will survive addon updates. Only js context will be destroyed, so we just need to reload the page and inject script again. This way, all user data and tree structure will be preserved.

Previously, Sidebery was using a normal pages (with script) and tried to reopen these pages after they were closed, but this was super fragile and bug-prone, so when the before mentioned behavior of the script-less pages was found (in TST), I happily implemented it too.

This is actually my mistake for relying on such obscure, undocumented behavior. (Hope, this will not be fixed soon, before I prepare a complete workaround).

I already started to implement the first planned fix. When it will be ready and tested I'll upload a new release on AMO. After that, I'll probably won't spend time on the second fix and will jump right to the third one.

Sorry again and thank you for the hard work on addons API. Looking forward to a split-view feature.

Footnotes

1. A page that is used when user tries to open a url that's not allowed to be opened by addons ↩

[guigirl42]

addons API. Looking forward to a split-view feature

AND also tabs-note API, pls... Sidebery should also have access to this, along with the split-view.

[Rob--W]

The problem is not the inability to run a script on the page or send data via messaging API. When the addon opens its own page with a script, this page will be closed on the next update of addon (or disabling addon). In case of Sidebery's group and placeholder[^1] pages user will have their tabs tree destroyed and will lose data (placeholders for unsupported urls).

But, when we open a script-less addon's page (just html + styles) and then inject a script into it, such pages will survive addon updates. Only js context will be destroyed, so we just need to reload the page and inject script again. This way, all user data and tree structure will be preserved.

Previously, Sidebery was using a normal pages (with script) and tried to reopen these pages after they were closed, but this was super fragile and bug-prone, so when the before mentioned behavior of the script-less pages was found (in TST), I happily implemented it too.

This is actually my mistake for relying on such obscure, undocumented behavior. (Hope, this will not be fixed soon, before I prepare a complete workaround).

This is a known issue, tracked at https://bugzilla.mozilla.org/show_bug.cgi?id=1399655 . That behavior is currently not being changed, but we cannot promise that behavior for eternity since it is a bug.

The general way that extensions work around the auto-closing of tabs on update is to register a runtime.onUpdateAvailable event, which suppresses updates until the next browser restart. The downside is that this delays the application of extension updates, and this does not prevent unload/reload if the user manually forces to reload the extension via about:addons.

The not-unloading of the tab happens due to the absence of extension API calls (in the tab and any of its subframes). You can still embed a regular script via <script> that populates your UI as needed, as that won't trigger changes in behavior to the tab unloading behavior. I see that you currently do not load any such script, at https://github.com/mbnuqw/sidebery/blob/888c4fee71e84282ebbfcefbffb33388994b4982/src/page.url/url.html . I guess that you are already aware that running the logic in your extension tab is a feasible (and backwards-compatible) work-around, but if not, FYI.

[Rob--W]

addons API. Looking forward to a split-view feature

AND also tabs-note API, pls... Sidebery should also have access to this, along with the split-view.

There are currently no plans for a tab notes API, you can track progress updates at https://bugzilla.mozilla.org/show_bug.cgi?id=2009309