I reproduced the issue of @abowsher, didn’t be allowed to reply to the same thread.
I set 3 fixed columns and the alignment issue is triggered by width changes in the other columns (https://jsfiddle.net/oskrd/w9bdtuog/7/)
Also if you scroll all the way down, you will see as if the fixed columns were part of a different table and they’re over the other columns, I can see an overlap there.
Any help to find a workaround will be appreciated.
Hi @OskrD
It seems to works well on my device (macOS Catalina 10.15.3 on Chrome 83).
Can you share your screen recording?
Did you try resizing the width of a column in the non-frozen columns? That seems to trigger the behavior. But we’ll try to get you more info.
Is there any event that gets triggered when a row gets resized that we could use to repaint the table or something?
Oh, no I haven’t. I guess that you see this
If so the issue is gone when you add an offset for the columns https://jsfiddle.net/9mnwxvs4/
You mean the viewportColumnRenderingOffset? If I go to your jsfiddle, and reduce the width of column I by dragging the column boundary, the non-frozen columns are resized, but the frozen ones are not.
We need the whole thing to look like a single table to our users, with all the rows having the same height.
Thanks for your help trying to sort this out.
Isn’t that a desired behavior?
Maybe I’m not communicating well enough. Here I’ve resized column I (not ‘one’ but ‘eye’ to be clear) and made it smaller. Now the row sizes for the frozen columns have not resized, so the user can’t tell what row they are on horizontally. Does this help explain better?
The problem still happens when you change the width of the columns (other than A, B, and C) in your jsfiddle.
The expected behaviour is to prevent a row from becoming misaligned.
I can see what you mean.
When I resize fixed columns or something close (let’s say D) it works well, but when I resized S my workaround did not work. It starts to work when you set autoRowSize to false https://jsfiddle.net/of0cqu6t/
Does it work for you as well?
Thanks for you help, It works if you do not scroll much, but still get this result sometimes if scroll down and up.
And when it keeps the alignment, there is a slight difference when you scroll down also.
We really need some help on this. Customers are noticing the problem.
Hi @abowsher
I’m sorry I haven’t answered for so long.
If I good understand this is your demo - https://jsfiddle.net/of0cqu6t/
Unfortunately, I can’t reproduce your issue as you can see below:
What kind of OS and browser do you use?
Correct, that’s the minimal demo. I see in your screenshot you didn’t change the width of any column, that’s what triggers the error.
I’ve tested in:
Google Chrome & Microsoft Edge 84, and Mozilla Firefox 78 @ Windows 10.
Also tested on Debian 10 Chromium and Firefox.
I see it now.
Honestly, without a scroll, the issue appears. Changing the column width is enough to reproduce your issue.
If you set autoRowSize option to specific amount the issue disappears.
Here is an updated demo - https://jsfiddle.net/nma9tgr6/
Thanks for your help in trying options.
With your updated fiddle I still get the misaligned issue. If it works for you, I resized A, B, and C to get the text in two lines, and X column to wrap the text into five lines.
I don’t post another image because it looks the same as the last time I did.
Yes, you right.
But if you change one of the fixed columns to wrap the text into x lines (where x is number for wrapping the text in the unfixed column) everything is displayed correctly.
Sadly that is not a valid restriction for our real app because the three fixed columns have either an icon or one single word, the variable data is in the non-frozen side.
Here a jsfiddle with a closer config to our table and with the additions we’ve discussed in this thread.
Hi @OskrD I was ooo and I see that there’s a continuation of this thread with @piotr.nowak
The use of icons and determined cell content length may have an impact on the final result. That is why I was wondering if you’d be willing to share the bug reproduction on a screen sharing session with me?
Thanks for your follow-up. @piotr.nowak showed me a couple of bugs reported back in 2016 with the problems we described here (3215, 5627 in GH).
On my last jsfiddle I tried to show a closer implementation of our app, since I got some controlled-ish environment there, but I cannot be able to get the same ‘corrected behaviour’ in that demo.
The major problem appears when I zoom out under 80% or zoom in to 150% or above. (This is also in a recent GH issue, 7149).
If you think I can help with the bug reproduction sharing my findings with you I’d love to do it in order to hopefully get some fix soon.
