[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.