[Bug] Overlay with Tabs Overview: Narrow size breaks presentation

[mdollinger]

Abstract

Steps to reproduce

1. Start Firefox with clean profile.
2. Install TST.
3. Open some Tabs, that have a long text in the <title> attribute
4. Move the ouse over such a Tab.
5. Wait for the overlay to appear

Expected result

The overlay is wide enough to shows all lines without line breaks

Actual result

The overlay seems to have a maximum width (although the screen has way mode space).
Thus the long items have a line break, which spoils the hierarchical structure:

Environment

• Platform (OS): Windows 10
• Version of Firefox: 115.4.0esr (64-Bit)
• Version (or revision) of Tree Style Tab: 3.9.19

[piroor]

It is a restriction of a WebExtensions based addon. We cannot show a popup wider than the sidebar area in regular way (we can open a new browser window and use it as a popup, but it means that the popup has a title bar and window controls - I think we can't accept such a "rich" tooltip!)

Currently TST just sets long long text as a "title" attribute of the element and Firefox shows it as a tooltip. The size of the tooltip is automatically calculated by Firefox and it is uncontrollable by addon.

[irvinm]

@piroor given there is not a bug/enhancement upstream to change this behavior, we should probably just close this as a limitation.

[piroor]

Before closing this I've brain-stormed about another idea to implement that.

Idea 1: rich tooltip based on HTML + CSS positioning. It will be secure and good privacy, but the tooltip will cover over tabs, so it will introduce a serious issue about tab usability.

Idea 2: rich tooltip based on HTML + CSS + transparent iframe embedded into the content area. It will become similar to the behavior of Firefox's native rich tab tooltip with its built-in vertical tabs feature (developed on Nightly). Screenshot:

It will have better appearance and usability, but worse security and privacy - we need to embed something to the contents of the active tab. Such an embedded elements may be used for fingerprinting like: "embedded UI is detected, the user uses TST on Firefox".

Should we try to implement the idea 2?

[irvinm]

Just my opinion on this topic, but I might suggest 2 other things to think about and/or consider.

1. While I agree that "very" long titles doesn't help with the presentation, this situation probably isn't very common and unless you wanted to implement more of a "rich" tooltip anyway, I am not sure it would be worth your while.
2. I had this same concern about group-tab.html and ended up applying some CSS to ensure that each tab only took up 1 line of space when there were multiple columns which made the presentation better for me. Maybe this would be a better short-term solution for the tooltip as well? I would guess showing 80-90% of the title would be sufficient for the user to know which tab it was.

Here is an screenshot of how this ended up looking like for me. I would imagine the tooltip would benefit from this (maybe as an option?) and would be pretty easy to do.

[piroor]

Current tooltip is completely processed by Firefox's tooltip mechanism, and it just shows given text as white-space: pre-wrap, so we need to calculate character width and crop end of titles manually, based on the system font used for Firefox UI. It looks very hard...

[irvinm]

That is unfortunate in terms of an easy solution ... maybe your solution 2 might be an interesting choice then.

[piroor]

Plan 1, operations done by the sidebar and content scripts. Players are:

• The sidebar script (<sidebar>)
• The content script of the active tab (<content>)
• The content script of the iframe (<iframe>)

When we need to show a tab preview:

1. The <sidebar> detects mouseover event on a tab.
2. The <sidebar> sends a message to the <content> of the active tab, like "are you ready to show a preview?"
   1. If no response, the <sidebar> loads a content script <content> into the active tab.
      1. The <content> generates a transparent iframe with about:blank.
      2. <iframe> configured to be loaded to about:blank contents is automatically loaded, and the <iframe> sends a message to the <sidebar> like "now I'm ready!"
      3. The <sidebar> receives the message and gets the sender.frameId information.
      4. The <sidebar> sends the frameId information to the <content> of the active tab, like "hey, your iframe is loaded with the frameId XXX!`
      5. The <content> of the active tab tracks the notified frameId.
   2. The <content> of the active tab responds to the <sidebar>, like "I'm ready with an iframe with the frameId XXX!"
   3. If these operation is not finished until some seconds, the <sidebar> gives up to show the preview.
3. The <sidebar> receives the "I'm ready" response with frameId from the <content> of the active tab.
4. The <sidebar> generates a thumbnail image for the tab A, and sends a message with frameId to the <iframe> in the active tab, like "show a preview with a thumbnail image 'data:image/png,...' at the position (x,y)"
5. The <iframe> with the specified frameId shows the preview.

When we need to hide a tab preview:

1. The <sidebar> detects mouseleave event on a tab.
2. The <sidebar> sends a message to the <content> of the active tab, like "are you ready to show/hide a preview?"
   1. If no response, the <sidebar> gives up to hide the preview. We have nothing to do.
3. The <sidebar> receives the "I'm ready" response with frameId from the <content> of the active tab.
4. The <sidebar> sends a message with frameId to the <iframe> in the active tab, like "hide a preview"
5. The <iframe> with the specified frameId hides the preview.

---

Plan 2, operations proxied by the background script. Players are:

• The background script (<background>)
• The sidebar script (<sidebar>)
• The content script of the active tab (<content>)
• The content script of the iframe (<iframe>)

When we need to show a tab preview:

1. The <sidebar> detects mouseover event on a tab.
2. The <sidebar> sends a message to the <background>, like "show a preview for the tab A at the position (x,y) in the active tab"
3. The <background> sends a message to the <content> of the active tab, like "are you ready to show a preview?"
   1. If no response, the <background> loads a content script <content> into the active tab.
      1. The <content> generates a transparent iframe with about:blank.
      2. <iframe> configured to be loaded to about:blank contents is automatically loaded, and the <iframe> sends a message to the <background> like "now I'm ready!"
      3. The <background> receives the message and gets the sender.frameId information.
      4. The <background> sends the frameId information to the <content> of the active tab, like "hey, your iframe is loaded with the frameId XXX!`
      5. The <content> of the active tab tracks the notified frameId.
   2. The <content> of the active tab responds to the <background>, like "I'm ready with an iframe with the frameId XXX!"
   3. If these operation is not finished until some seconds, the <background> gives up to show the preview.
4. The <background> receives the "I'm ready" response with frameId from the <content> of the active tab.
5. The <background> generates a thumbnail image for the tab A, and sends a message with frameId to the <iframe> in the active tab, like "show a preview with a thumbnail image 'data:image/png,...' at the position (x,y)"
6. The <iframe> with the specified frameId shows the preview.

When we need to hide a tab preview:

1. The <sidebar> detects mouseleave event on a tab.
2. The <sidebar> sends a message to the <background>, like "hide a preview for the tab A in the active tab"
3. The <background> sends a message to the <content> of the active tab, like "are you ready to show/hide a preview?"
   1. If no response, the <background> gives up to hide the preview. We have nothing to do.
4. The <background> receives the "I'm ready" response with frameId from the <content> of the active tab.
5. The <background> sends a message with frameId to the <iframe> in the active tab, like "hide a preview"
6. The <iframe> with the specified frameId hides the preview.

---

I'm not sure for now that a sidebar script can generate a thumbnail image of a tab safely, so the plan 2 is a backup.
I think that both <sidebar> and <background> should not track frameId for each tab. Contents of tabs are dynamically destroyed, so frameId information stored by the <sidebar> or <background> will become obsolete easily.

[github-actions]

This issue has been labeled as "stale" due to no response by the reporter within 1 year (and 7 days after last commented by someone). And it will be closed automatically 14 days later if not responded.

[github-actions]

This issue has been labeled as "stale" due to no response by the reporter within 1 year (and 7 days after last commented by someone). And it will be closed automatically 14 days later if not responded.

[github-actions]

This issue has been labeled as "stale" due to no response by the reporter within 1 year (and 7 days after last commented by someone). And it will be closed automatically 14 days later if not responded.

[mdollinger]

It seems to be expected by the system, that I comment here somehow.
However, I feel you are in a good technical discussion, and I am lookng forward to what solution comes out :)

[piroor]

I've implemented the simulated tab preview. It requires <all_urls> permission because the tab preview on the contents area is implemented with an iframe embedded to the active tab contents. And there is one more restriction: the tab preview will appear in the sidebar if the active tab shows any privileged contents. Demo:
https://github.com/user-attachments/assets/f648130a-1f73-45e7-984f-04b0c410fe25

It is disabled by default and you need to activate manually from the "Appearance" section in the options page of TST.

[irvinm]

@piroor is your plan (long term) to "replace" the existing functionality with this or make this a new option? The reason I ask is that there is definitely some usefulness of being able to hover over a collapsed tree and seeing the text listing of all of the tabs under that tree.

While the new hover and rich view of that tab is great, some people may miss out on the other functionality. Obviously, you can get the same information if those tabs are children of a group-tab, but if not, there is no easy way to inspect the children quickly. Just something to consider.

I use group-tabs a lot, so I don't normally leave the tooltip turned on, but others might. (Or maybe support both with one as the default for hover and the other with something like shift+hover?)

[piroor]

Your concern is reasonable. Now we just stand at the starting point, and we need to think about how to combine the tree information view with the in-content tab preview as the next step - for example, simple embedding of the tree into the panel instead of the preview image for a collapsed tree.

[piroor]

After more development, the in-content tab preview panel now can show custom tooltip contents with better appearance. It's not exclusive anymore.
https://github.com/user-attachments/assets/29115ff6-d436-463b-83d5-144311075f1f