Handsontable: Missaligned rows with row headers after zooming

[azyubin]

Hello,

I am attempting to create a custom column that holds actions for each row such as delete action. I am using custom renderers to create a button element and associate an appropriate action. However, after the column is added I noticed that if you change zoom on your browser you row headers and rows themselves become miss aligned. I was wondering if any one know how I can solve this problem.

Here is JSFiddle with sample of the code: http://jsfiddle.net/26gLz0zf/

Thank you.

[AMBudnik]

Thanks for sharing @azyubin. Confirmed with zoom in and out on all major browsers.

[AMBudnik]

still reproducible, v 0.27.0: http://jsfiddle.net/v6oqbda4/

[G #597,forum]

[twitchax]

Looks like rendering while scrolling is also similarly affected: there are artifacts at the edges (especially noticeable when scrolling up).

https://1drv.ms/v/s!AkVm727CuAMs5q1n8UZ2wCazxEaTHw

In my case, the zoom level of the browser is unchanged, but I have a 4K monitor set to 150% scaling (in Windows). Setting to 100% scaling (in Windows) _completely resolves_ the issue.

[dctucker]

This page is linked from here https://forum.handsontable.com/t/scroll-problem-in-chrome-with-zooming/643/10 ...

It's been mentioned that it's a pixels vs ems vs percent issue. I'd like to jump in and try to solve this problem, even if it's a huge rewrite — I'd appreciate any advise on what section of code to begin looking at and tweaking to alter this unusual behavior when zoomed.

[AMBudnik]

Hi @dctucker
The fixed pixel values are all around the entire handsontable.full.js file and it also does not mean that using more responsive values will fix the issue. Please remember that we are working on TD elements.
I'd be more than happy to see a table that stretches without any issues while we zoom in and out but that is a huge project you're planning.

[dctucker]

I've noticed this problem occurs when scrolling on certain zoom ratios. For example, if I zoom to 67%, the error persists, but when loading the page at 50% zoom everything works as it does at 100% zoom. Might this be a problem related to integer division?

Regarding getting a table that stretches without any issues while zooming in and out, Datatables is a good example of this without spreadsheet functionality, which that leads me to believe the problem is solvable in this plugin and not a bug in the browser's rendering engine.

[AMBudnik]

I would like to suggest anything but the issue has been raised a long time ago and we did not test any solutions yet. I really would like to avoid giving false tips.

[dctucker]

Hit me offline then. I'm motivated.

[AMBudnik]

Hi @dctucker

sorry for keeping you waiting for so long. I know that you have a lot of will power to fix the issue and as I have spoken with one of our devs your approach sounds like a good path.
I have been told that we are using parseInt to set up heights via Walkontable and that why after some time we get the misaligned cells.

ps. I'd be more than happy to get a pull request from you.
ps.2. Please delete your email from the last comment. Spammers are everywhere just waiting to harvest some juicy emails ;-)

[dctucker]

No worries. I got around to debugging a little bit today and found that Overlays.onTableScroll() is not getting called when it's supposed to, when Chrome is zoomed to 67%.

[AMBudnik]

I really appreciate your effort to share the results and investigate this issue @dctucker
[inform G# 9301]

[AMBudnik]

The issue is still replicable in v 2.0.0. zoom +175%

[larvanitis]

I consider this a show stopper because it also affects browser scaling (HiDPI etc.) and nowadays more and more people use 4k displays and HiDPI laptops.

After spending some time I was able to fix it (at least here) by doing two things:

1. Set the row height style on the rows (tr) instead of the first cell (th)

Replaced TR.firstChild.style.height with just TR.style.height in these two lines:

https://github.com/handsontable/handsontable/blob/7476f640754c49cd395d2c966a161540802c95b8/src/3rdparty/walkontable/src/tableRenderer.js#L215-L217

Replaced children[i].childNodes[0].style.height with children[i].style.height in this line:

https://github.com/handsontable/handsontable/blob/7476f640754c49cd395d2c966a161540802c95b8/src/3rdparty/walkontable/src/tableRenderer.js#L313

_That last one (L313) didn't affect my use case but I added it for completeness, because from what I could see it does the same thing but in some other case._

2. Get and use the exact row height

Replaced innerHeight(ELEM) with ELEM.getBoundingClientRect().height in these two lines

https://github.com/handsontable/handsontable/blob/7476f640754c49cd395d2c966a161540802c95b8/src/3rdparty/walkontable/src/tableRenderer.js#L269-L271

Note: I have not tested this extensively because I am currently developing my first table using _hot_ and I fixed it before moving forward.

I would love to get some feedback from the developers. Thanks!

[AMBudnik]

Hi @larvanitis
Wouldn't you like to create a pull request? By adding tests we will be able to verify if the proposed solution works better than what we have now. You've done a lot of work with investigating this issue so it would be great to see you among our official contributors.

[yashu321]

Hi @AMBudnik
When I made my handsontable with fit to screen changes (using plugin stretcH:all) ,it was acting weird for different monitors. Working properly for "acer"/"HP" but not for "ViewSonic" monitors. Is there any solution for this issue? Can you provide any suggestion that how it can be made all monitors compatible when all monitors are at default zoom level.

[AMBudnik]

Hi @azyubin
the issue with zoom is also associated with the screen resolution so it may not work for all the monitors. It is really hard to check if we do not own this kind of devices.

[brianxautumn]

I tried the mod from @larvanitis and it is so far working for me, but there are still other scaling artifacts, but at least the rows are aligned.

[brianxautumn]

It also works if you set the height on a div inside the td, like in the case with the row header, but its messy if there is no row header.

[AMBudnik]

I guess that we need to do something here sooner than later, as there are more examples where the table is misaligned or misses borders with 125% zoom.
The scale of this issue can raise with time as newer devices working on Windows set 125% zoom as the default value.

[kyle-msm]

Bumping this thread as it's still an issue (and an annoying one too :stuck_out_tongue:)

http://jsfiddle.net/vpabm0y7/4/

[niketjsh]

Hey i am having an similar issue like if i zoom the browser from 125% to 175% the fixedColumnLeft and unfixed right columns are mismatching, last row is repeating can you please help to fix this issue

[AMBudnik]

@niketjsh we do not have this topic on our Roadmap for July but I'll update you once we get any news on that subject.

[oskrd]

Hi @larvanitis
Wouldn't you like to create a pull request? By adding tests we will be able to verify if the proposed solution works better than what we have now. You've done a lot of work with investigating this issue so it would be great to see you among our official contributors.

Hi, was a PR created related to that suggestion?
I see @larvanitis is now a contributor, perhaps due to another issue.

[AMBudnik]

Hi @oskrd zooming issue hasn't been solved yet. There are no open/pending pull requests/commits related to this subject.

[oskrd]

@AMBudnik I adapted the proposed change to the current code structure in HoT 8.0.0 and it fixed two of my issues.
The thing here is I have no idea how to write a test (e2e) to zooming cases, have you ever wrote something related to guide me?

[larvanitis]

@oskrd Unfortunately, I no longer use HOT and no PR was ever created.

[oskrd]

@larvanitis could you please write me an email? I would like to ask you something.