[DEV-2515] Scrolling issue after recent Chromium update

Questions
1

Hi,

As of Chromium 151.0.4219 I’m having a scrolling issue in at least one of my grids. (I’m on Handsontable 16.2.0.) Specifically, column headings and fixed columns don’t scroll with the rest of the grid. For a couple of days Edge worked even while Chrome stopped working, but now my Edge has upgraded and now I have the issue in both browsers. Have you gotten similar reports from anyone else?

Thanks,

David

2

One addendum to the above. The first symptom I see is that the grid does not render at all. But if I click on where the grid should be, it appears. From that point I get the scrolling issues.

3

Hi @dhaber , this is fixed in 18.0.0 (PR #12472). Note 17.x does not fix this specific vertical-scrollbar case. It addressed a separate scrollbar-width issue, so please upgrade to 18.0.0.

On responsiveness: Handsontable automatically follows its container’s size (it re-renders on container resize), but it doesn’t fit the viewport by itself.

For a fluid layout give the grid a responsively-sized container with a definite height, and set stretchH: ‘all’ so columns fill the width. If you still see stale sizing after a zoom/layout change, call hot.refreshDimensions().

Hope this helps! Please let me know if you still see any issues after upgrading to v18.

By the way, we have a new 'changes between versions’ section in the docs that makes it easy to see all the changes between any two versions to help with upgrades. Here’s a link for 16.2→18:

4

Hi @joseph.petty. That compare version tool is nice!

Unfortunately our entire organization is stuck on v16 due to this outstanding issue.

Is there anything I can do/call while on v16 to get around this scrolling issue?

Thanks.

5

The fix for that other performance issue is done and on the develop branch. I’m not sure on an ETA for when it will ship in the next release, but I’m checking with the team.

6

That’s very encouraging news, thank you. We don’t like to fall too far behind, as it gets harder and harder to catch-up, so hopefully we’ll see the fix in 18.x.

Looking forward to hearing back from you.

7

@joseph.petty follow-up to this. This Chromium issue is affecting many grids in Production and I doubt it’s just our company. And asking all of your users to do major version upgrades to get on 18.x is asking quite a lot of your user base. Does Handsontable provide no support for earlier versions?

8

That is a fair concern. A browser regression that suddenly affects production grids can be difficult to work around if the only practical fix requires jumping several major Handsontable versions.

If a workaround for v16 is not possible, it would at least be useful to know whether the Chromium-related fix can be backported to an older supported branch, or which older versions are still eligible for fixes of this kind.

9

Hi @dhaber , apologies for the delay in replying. The team has been working reproducing the scroll issue in Chromium 151. They found the same issue in 150 though, so it seems like existing behavior, not a regression. They also confirmed the issue is fixed in v18.

It may be that some other part of your config causes different behavior in 150 vs 151 than in our testing. If we can see where it regressed, it would help the team prioritize a fix on v16.2.0. Could you please provide an example of your table config and css?

10

Hi @joseph.petty. No problem. As I mentioned to @natalia.syryca and @aleksandra_budnik separately, we have managed to work around the problem by adding a ResizeObserver to the affected grids.

As far as giving you our grid config and css is concerned, I would appreciate it if you be more specific as to what you are looking for, as sharing our entire grid config and css is not practical.

Last, if you do come up with a fix for the 16.x branch we are more than willing to test it out for you.

Thanks.

11

We are starting to get more notices of this issue across our product line. Do you have any updates? Has anyone else flagged this issue?

12

Hi :waving_hand: I just wanted to make a note that I was away and just got to my email. @dhaber please reply if possible

13

Hi @aleksandra_budnik. The best I can tell so far is that it is often related to grids that are initially hidden and only shown later (e.g. when a user clicks on a tab).

I would very much appreciate it if someone would please answer my questions above.

Thanks.

14

I also suspect a race condition. On one of my grids just refreshing the page on a grid with no data in it yet (so I just just see the column headings), only about 20% of the time do I see the column headings to the right of the frozen columns.

15

Hi @dhaber

We did not get any similar reports from other Clients or community. However, our QA did a test on it and mentioned that

  1. Overlay/header desync issue reproduced on Chromium 151.0.4219 at default zoom (but also previous Chromium versions).
  2. In 18.0.0 there is no issue
  3. ‘blank until click’ symptom cannot be reproduced neither on Windows nor on Mac Chromium 151 via Browserstack.

I think that we are missing something to get the exact ehavior of what you can see in your application. If the issue is replicable when a grid is initially hidden and then shown it might be related to a mismatch between the calculation of the grid. That is why it is important for us to have a working demo that we can both test. We can also organize a call and check it together if that sounds like an easier next step.

16

Hi Aleksandra,

As I’ve noted before, if the problem is limited to our grids then we will try to get to the bottom of the problem ourselves. If we succeed in doing that, and if we determine that the issue is with Handsontable (which hardly seems likely if we’re the only ones affected), then we will let you know.

Thank you very much,

David

17

Thanks for the update, David.

18

Important update: we have confirmed that the issue is related to the fact we host many of our grids in web components that have handsontable within their shadow dom. A recent change to browsers has caused that to not work reliably.

I will have more information next week about what we’re going to do about it, but thought I’d share that right away. Feel free to do web searches on what’s changed in browsers recently related to hydrating web components.

Thanks.

19

Thank you for the update. I will adjust our internal report with this information.

20

Hi @dhaber

we have one more developer checking this issue, and he reported that

Blank until click doesn’t - I tried several shadow DOM variants (declarative shadow DOM, late element upgrade, hidden host, delayed CSS) and none of them show it.

Could you please share more details about the shadow DOM setup? Maybe the environment has something to do with it.