[Bug] group-tab.html resizing window and overlap issues

[irvinm]

Abstract

On group-tab.html, when having more tabs than a column can handle, the relationship between UL and LI elements sometimes causes the different sections to overlap.

Steps to reproduce

1. Start with a fresh profile
2. Install TST
3. Create many tabs with a few in a tree
4. Resize the window vertically and see overlapping tab information

I suspect this is related to the space at the bottom of the previous column. The most overlap in the 2nd column is when the free space of the previous one is at its largest. I do not believe this is a new bug, but has existed for quite some time.

Expected result

Regardless of the window height, none of the tab lines should be any closer to overlapping.

Actual result

Notice the overlap examples in columns 2 and 3.

2023-07-12_13-12-29.mp4

Environment

• Platform (OS): Windows 10 Pro 2H22
• Version of Firefox: 115.0.2
• Version (or revision) of Tree Style Tab: 3.9.15

[piroor]

Thanks! This looks to be a bug of Firefox itself so I've reported it to bugzilla.mozilla.org.

1843228 - Boxes are unexpectedly overlapped with a combination of CSS flexbox and CSS multi-column layout

[Arthaey]

I'm see a similar overlap in the sidebar for some of my collapsed trees. Is this the same Firefox bug, or something different?

[irvinm]

@Arthaey, you obviously have some CSS at work there. Can you reproduce the overlap without any CSS applied in the sidebar?

[piroor]

1744363 - Firefox print preview and resulting print out are truncating the last few table rows contained in div (the bug I filed was resolved as a duplication of it) is fixed at Firefox 122, thus I close this.

[irvinm]

@piroor I re-tested this with FF122 and it is MUCH better now with the Firefox changes.

However, there does seem to be 1 edge case and I am not sure if it is Firefox related or TST related. Whenever there is a virtual folder inside another folder, the favico for the nested folder does not stay locked to the name. This seems to be the only scenario that doesn't work at this point.

In this example, watch the folder "Sort Me" at the top of the 2nd column. I am just resizing the window to show the changes.

2024-01-23.10-43-11a.mp4

[piroor]

Hmm... I cannot reproduce the problem exact same to yours. But I saw similar odd rendering:

The small black line is the bottom edge of the "globe" icon. I've inspected it with the DOM inspector and I've realized that Firefox renders an icon as two parts.

[piroor]

TST's built-in icons like "folder", "globe" and so on are regularly rendered as "colored box, clipped with SVG mask", to render icons with arbitrary color. Firefox looks to be able to render such a box as sliced parts. On the other hand, favicons of webpages are rendered as an <img> HTML element, and Firefox looks to prevent sliced rendering for such an embedded image.

[irvinm]

Thanks for checking on this. I see what you are saying and I see the same sliced parts as well with the built-in icons. I guess I could add a comment to the original Mozilla bug to see if anything happens. Regardless, things are much better now.

Thanks again.

[irvinm]

I opened a new bug on this ... https://bugzilla.mozilla.org/show_bug.cgi?id=1876348

Below is what they said ... the "break-inside:avoid" sounds interesting. I'll see if I can test that.

---

Thanks for the report! It is good to know bug 1744363 helps.

"TST's built-in icons like "folder", "globe" and so on are regularly rendered as "colored box, clipped with SVG mask", to render icons with arbitrary color. Firefox looks to be able to render such a box as sliced parts. On the other hand, favicons of webpages are rendered as an <img> HTML element, and Firefox looks to prevent sliced rendering for such an embedded image."

Without a testcase showing the issue, it is hard for me to know exactly the problem. However, with the description above and the observation of the video, I guess the built-in icon is a <div>, and Firefox can slice it across the column boundary. For <img> and text, Firefox treats them as monolithic elements, and won't slice it; if they are not fit in current column, it will be pushed to next column.

If you still have access to the testcase, could you try if adding break-inside:avoid [1] to the built-in icon makes any difference? An alternative idea is to add break-inside:avoid to the box that contains the built-in icon and the text.

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/break-inside

[irvinm]

Looks like at a minimum, we can apply some CSS to avoid this situation. I was able to successfully keep the default icon from slicing and the icon and label together all by applying "break-inside:avoid" to the "li". I updated this information in the defect as well. Not sure if they will want to do anything else on their end, but at least there is a workaround.

Applying it to just the icon itself prevented it from slicing, but I was able to get the icon and label to split from each other.

[irvinm]

They have closed the issue on their end which is what I kind of expected given the specific situation.

[piroor]

I've changed to set the break-inside:avoid to the icon itself. ( dc3b45b )
The still-appearing problem (icon and label are shown in different columns) on your environment can be triggered by a difference around font rendering system or the font itself.