handsontable disappears on firefox after upgrading to version 93

[JuanjoArmellino]

hello, I have a problem with HT, it worked fine in firefox until version 92, starting version 93 the table goes white on scroll or window resize.. im not sure if its a firefox problem or something they changed is causing this.
i have to admit it only happens on a very rare case of having a table inside a bootstrap card with the card resizing automaticly to the windows size.. but it happens every time.
works fine on chrome

Steps to reproduce

load the sample file and scroll the table with the mouse or maximize / restore / resize the window

Demo

https://jsfiddle.net/p4u7mt0f/

Your environment

• Handsontable version: HT 7.4, HT10 or HT12
• Browser name and version: firefox after version 93
• Operating system: windows 10 21h2

[AMBudnik]

Thank you for sharing the report @JuanjoArmellino

I'm already on FF 100. But you are right. Chrome opens the demo and it works well, while Firefox does not show the table. I tested the CSS settings and by commenting our the overflow I got the table working on Firefox.

We'll investigate it further and check what are the connections to #2806

[AMBudnik]

Minified demo: https://jsfiddle.net/6r7kvdwj/10/ (still contains a lot of DIVs with flex settings)
I've added comments on what changes the behavior between Firefox and Chrome in the comments
Tested with Handsontable v12.1.2 on Chrome 103 / macOS Monterey

[wszymanski]

I've done investigation by myself to determine why the problem occurs. I've found that node created as clone sometimes has height set as 0. The first call to alignOverlaysWithTrimmingContainer method is done from Table element's constructor and it's calculated properly, while the second one (called from draw method) isn't calculated properly on FF.

handsontable/handsontable/src/3rdparty/walkontable/src/table.js

Lines 108 to 110 in a203385

	if (this.isMaster) {
	this.alignOverlaysWithTrimmingContainer(); // todo wow, It calls method from child class (MasterTable).
	}

handsontable/handsontable/src/3rdparty/walkontable/src/table.js

Lines 308 to 309 in a203385

	if (this.isMaster) {
	this.alignOverlaysWithTrimmingContainer(); // todo It calls method from child class (MasterTable).

handsontable/handsontable/src/3rdparty/walkontable/src/table/master.js

Lines 67 to 73 in 0fbd127

	if (cloneHeight === 0) {
	height = 0;
	}
	}
	height = Math.min(height, scrollHeight);
	holderStyle.height = trimmingHeight === 'auto' ? 'auto' : `${height}px`;

Deep clone of DOM element (see below; currently a flag is set to false) for purpose of calculation fixes the problem, but it isn't definitely a solution.

handsontable/handsontable/src/3rdparty/walkontable/src/table/master.js

Lines 49 to 50 in 0fbd127

	if (trimmingElementParent && overflow.includes(trimmingOverflow)) {
	const cloneNode = trimmingElement.cloneNode(false);

The problem is happening even though Firefox and Chrome draw flex elements (without Handsontable; parent divs have their widths and height) properly. At first, I thought, that there may be some problems related to flex as changing flex-direction fixed the problem on FF. I also found that not setting height option for Handsontable, but setting width to 100% value also broke the table (both Chrome and FF, the same part of code is handled). However, after a research, I conclude that it may be strictly related to the overflow property as @AMBudnik suggested in the above comment. I can see that #3432 issue shown similar case, although it seems that the other issue is related also to Chrome. What's more I tried to understand complex user's example and its compliance with CSS principles. Even if it has some redundant stuff, the table should insert itself to a container and be rendered properly.

I experimented a little bit with changing a way how height for master element is calculated (I'm not sure whether trimming container is chosen properly), but I need a moment more time for finding the best solution.

PS. I confirm that the problem occurs after upgrading from FF 92 to FF 93. I've tired to find hint, which will show, what may be problematic (what change has an influence on the issue), but without success.

[aninde]

The original demo works with the upcoming Handsontable version 12.2 https://jsfiddle.net/aninde/g527ehv9/1/ on Firefox 93 via Browserstack on Firefox 93 / macOS and Windows 11.

[warpech]

The problem is fixed in PR #9545. We agreed on the today's planning meeting that the PR is missing a test. One or two tests will be added by @wszymanski.

[aninde]

I opened a new issue to create a test #10061.