[Bug] group-tab.html & --column-width inconsistencies

[irvinm]

Abstract

Since #2607 (comment), this has generally worked well and group-tab.html pages with only 1 column was displayed with full width while multi-column were set to the value specified via --column-width. (No issues once multi-column kicks in)

However, in recent weeks\months, I am seeing group-tab.html examples with only one column that are being clipped to the --column-width value while they don't need to be.

Relevant CSS Used:

:root.group-tab { --column-width: 30em; }

Example 1 - Working Fine

Example 2 - Not Working

Example 3 - Not Working

Example 4 - Working Fine

Steps to reproduce

I'm still working on a more basic reproducible scenario, but wanted to see if you had any early thoughts.

Expected result

• Single column list should use the the full width
• Multi column list should use width specified by --column-width if it exists

Actual result

• Single column is sometimes being clipped to --column-width
• Multi column is working fine

Environment

• Platform (OS): Windows 11 23H2
• Version of Firefox: v128
• Version (or revision) of Tree Style Tab: 4.0.20

[piroor]

Is the user style sheet is applied on the failure case? Could you see the right pane in the DOM inspector?

On my case the style rule is applied to the root html element as this screenshot. If your style sheet is not applied on the failure case, something error may block the initialization process of the group tab page. Otherwise Firefox's CSS rendering system may cancels the value your specified by some reason.

[irvinm]

@piroor the failure is that the --column-width: 30em; IS being applied when it should not.

It looks to me that the Javascript around this should leave out the column-width: style when it is determined to be a single column, but then applies the column-width: calc(var(--column-width, 20em)); to restrict the column width to either --column-width if user defined or 20em by default if multi-column. In both working and non-working examples, it looks like --column-width is properly defined.

Not working - Single column being trimmed

Working - Single column not being trimmed

[piroor]

I've realized that I missed labels are cropped in your screenshots. Long labels are not cropped and shown fully with line-breaks by default. These differences may affect to this problem. Do you use more other style rules?

[irvinm]

My CSS is related ... (Sigh, I am sorry about that).

I removed everything and it worked. I then added back all group-tab and some other items until I was able to reproduce. I then started removing items until it went away and was left with this.

:root.group-tab { --column-width: 30em; }

:root.group-tab li {
	overflow: clip;
	width: unset;
}

#tabs span.link span.label {
	white-space: nowrap;
	overflow: clip;
	width: 100%;
	text-overflow: ellipsis;
}

I had forgot that I had wanted each URL on the group-tabs page to be single line in nature (felt that was sufficient to understanding the destination) which involved changing some items around white-space and overflow.

Without the "li" CSS, the multi-column URLs don't get clipped properly to stay within the column. Without the span.label items, individual line items on the group-tab page aren't restricted to 1 line.

However, with both I see that single column pages sometimes work, but sometimes don't. (Per previous screenshots)

In either case, this isn't a TST problem and hence closing. I will investigate further on my end. If anything jumps out at you, I would appreciate any feedback.

[irvinm]

Using just the CSS from above and inspecting group-tab examples of working and not working, I think I see why this CSS behaves differently.

In cases that are working, the UL does not have a "column-width" style applied to it. Any LI items under it that are clipped should just be clipped to the parent UL which is not restricted.

In cases that are failing, the UL has ... style="column-width: calc(var(--column-width, 20em)); ... which means LI items under that will be clipped to the size of the UL which in this case is the 30em.

Since TST is applying that style, is it possible that TST isn't applying the style properly? Maybe I could try to step thru the code that applies the column-width: calc(var(--column-width, 20em));.

[irvinm]

Ok, I have a reproducible scenario:

• Install Firefox 128.0.2 (Windows)
• Install TST 4.0.20
• Insert the following CSS into TST

:root.group-tab { --column-width: 30em; } 

:root.group-tab li {
	overflow: clip;
  	white-space: nowrap;
	width: unset;
}

#tabs span.link span.label {
	white-space: nowrap;
  	overflow: clip;
  	width: unset;
}

• Create a group tab
• Open new child tab and open: https://www.tomshardware.com/pc-components/hdds/toshiba-x300-pro-20tb-12tb-hdd-review/2
• See that the column is being truncated to 30em. (Remove the --column-width CSS and it will truncate to 20em)
• 
• Open a different group tab
• Open new child tab and open: https://www.tomshardware.com/reviews/gpu-hierarchy,4388-2.html
• See that the column is not being truncated.
• 

In both cases, it is the desired result that single-column rendering should not have the column-width applied. I am not sure why in this case one of the tabs works and the other does not. I am guessing there is something about the metadata and\or metadata length.

I did start stepping thru the code and see that everything is being handled and applied here in the code blocks below. I will continue to investigate when I have time.

treestyletab/webextensions/resources/group-tab.js

Lines 503 to 509 in aeb6cad

	function reflow() {
	const container = document.getElementById('tabs');
	columnizeTree(container.firstChild, {
	columnWidth: 'var(--column-width, 20em)',
	containerRect: container.getBoundingClientRect()
	});
	}

treestyletab/webextensions/resources/group-tab.js

Lines 585 to 615 in aeb6cad

	function columnizeTree(aTree, options) {
	options = options || {};
	options.columnWidth = options.columnWidth || 'var(--column-width, 20em)';
	const style = aTree.style;
	style.columnWidth = style.MozColumnWidth = `calc(${options.columnWidth})`;
	const computedStyle = window.getComputedStyle(aTree, null);
	aTree.columnWidth = Number((computedStyle.MozColumnWidth || computedStyle.columnWidth).replace(/px/, ''));
	style.columnGap = style.MozColumnGap = '1em';
	style.columnFill = style.MozColumnFill = 'auto';
	style.columnCount = style.MozColumnCount = 'auto';
	const containerRect = options.containerRect || aTree.parentNode.getBoundingClientRect();
	const maxWidth = containerRect.width;
	if (aTree.columnWidth * 2 <= maxWidth ||
	options.calculateCount) {
	const treeContentsRange = document.createRange();
	treeContentsRange.selectNodeContents(aTree);
	const overflow = treeContentsRange.getBoundingClientRect().width > window.innerWidth;
	treeContentsRange.detach();
	const blankSpace = overflow ? 2 : 1;
	style.height = style.maxHeight =
	`calc(${containerRect.height}px - ${blankSpace}em)`;
	if (getActualColumnCount(aTree) <= 1)
	style.columnWidth = style.MozColumnWidth = '';
	}
	else {
	style.height = style.maxHeight = '';
	}
	}

[irvinm]

Another example site: https://wallpaperswide.com/

Group tab that includes this site (clipped rows)

Group tab by simply moving the tab outside (proper rows)

[irvinm]

Last example: https://github.com/kamranahmedse/developer-roadmap (clips when in, fine when out)

It looks to me that it is related to the length of the "title" ... in each of these cases, these tabs had the longest "title" value.

[irvinm]

Another data point ... when the "reflow()" is kicked off, the title is presently properly (obviously before the --column-width CSS is applied) and the width of the client area is sufficient to be able to display the entire title.

Start of reflow

After reflow is complete

[piroor]

I've introduced a change 63b55b4 which changes the method to determine to show the tree in multiple columns or single column. TST shows the tree in multiple columns only when its actual height is larger than the container. It should work whether items are cropped or line-broken.

[irvinm]

I tried the latest dev build and everything seems to be working as expected now. Thank you so much!